HTTP::Server returns generic OpenSSL error when presented with an expired client certificate

When an HTTP::Server is configured with a TLS context that enables peer verification and requires a client certificate, presenting an expired client certificate causes the TLS handshake to abort. The server raises an OpenSSL::SSL::Error, but the exception does not expose a distinct reason code or message that clearly indicates certificate expiry versus other verification failures (e.g., unknown CA, hostname mismatch). Developers need a reliable way to detect this specific condition to enforce least‑privilege handling of credentials without parsing error strings.

Assuming Crystal 1.12+ linked against OpenSSL 1.1.1 or later, and using the default VERIFY_PEER | VERIFY_FAIL_IF_NO_PEER_CERT mode, what information is available in the rescued OpenSSL::SSL::Error to differentiate an expired certificate?

• Which OpenSSL verify result codes map to expiry and are they surfaced through the Crystal binding?
• Can the error message be inspected safely for expiry indicators without relying on brittle string matching?
• Is there a configuration option or callback that would allow the server to raise a custom exception type for expired client certificates?