ribbybibby / ssl_exporter

Exports Prometheus metrics for TLS certificates
Apache License 2.0
525 stars 99 forks source link

Check OCSP status for every certificates in the chain #63

Open johanfleury opened 3 years ago

johanfleury commented 3 years ago

Hi

GlobalSign is currently revoking some of their intermediate CA certificates and I found out that ssl_exporter still considers a certificate issued by one of these intermediate CA to be valid.

To be fair, OpenSSL and GNU TLS both consider such cert as valid too:

$ certtool --verify --infile example.com/fullchain.pem
Loaded system trust (129 CAs available)
        Subject: CN=GlobalSign RSA DV SSL CA 2018,O=GlobalSign nv-sa,C=BE
        Issuer: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
        Checked against: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
        Signature algorithm: RSA-SHA256
        Output: Verified. The certificate is trusted.

        Subject: CN=example.com
        Issuer: CN=GlobalSign RSA DV SSL CA 2018,O=GlobalSign nv-sa,C=BE
        Checked against: CN=GlobalSign RSA DV SSL CA 2018,O=GlobalSign nv-sa,C=BE
        Signature algorithm: RSA-SHA256
        Output: Verified. The certificate is trusted.

Chain verification output: Verified. The certificate is trusted.

$ openssl verify -CAfile <(cat example.com/intermediate.pem example.com/root.pem) example.com/fullchain.pem
example.com/fullchain.pem: OK

However, some clients fails to validate this certificate and an OCSP request for the intermediate CA certificate shows that it is actually revoked:

$ openssl x509 -in example.com/intermediate.pem -noout -ocsp_uri
http://ocsp2.globalsign.com/rootr3
$ openssl ocsp -issuer example.com/root.pem -cert example.com/intermediate.pem -url http://ocsp2.globalsign.com/rootr3
Response verify OK
example.com/intermediate.pem: revoked
        This Update: Jan 25 20:38:32 2021 GMT
        Next Update: Jan 29 20:38:32 2021 GMT
        Reason: cessationOfOperation
        Revocation Time: Jan 20 00:00:00 2021 GMT

Do you think it would be possible to implement OCSP verification on every certificate in the chain returned by the TLS server?

ribbybibby commented 3 years ago

The ssl_exporter currently relies on the verification performed by the crypto/x509 and crypto/tls packages. Seems to me like they're beginning to work on it upstream:

So my inclination is to wait to see what happens there.

johanfleury commented 3 years ago

Thanks for the heads up. In the mean time I created a branch with a PoC that fits my needs.

This introduce a new metric called ssl_revocation_status that is computed for each leaf or intermediate certificates in VerifiedChains by requesting OCSP status or (as a fallback) by checking the CRL status:

$ curl 'http://127.0.0.1:9219/probe?module=https&target=https://arcaik.net'
[SNIPPED]
# HELP ssl_revocation_status OCSP or CRL revocation status for the certificate (0=Good 1=Revoked 2=Unknown)
# TYPE ssl_revocation_status gauge
ssl_revocation_status{chain_no="0",cn="R3",dnsnames="",emails="",ips="",issuer_cn="DST Root CA X3",ou="",serial_no="85078157426496920958827089468591623647"} 0
ssl_revocation_status{chain_no="0",cn="arcaik.net",dnsnames=",arcaik.net,",emails="",ips="",issuer_cn="R3",ou="",serial_no="414026126493887045299805532731746967018627"} 0
[SNIPPED]

Let me know if you would accept a PR with such a change. I know it could be cleaned up bit and collectRevocationMetrics could be merged with collectVerifiedChainMetrics, but I wanted to keep it separated while this stays a fork.

johanfleury commented 2 years ago

I’ve opened a PR (#81) with the code we’re using in production for a while at my job.

I’d be honest, this is far from useful on a daily basis (tho It might still help preventing some issues in the future if a CA revokes one of it’s intermediate certificate like GlobalSign did), so I’d understand if don’t want to add this feature into ssl_exporter.