Verification error on certificates without a CRL Distribution Point

[alexzorin]

Hi Rob,

https://crt.sh/?id=3753169066 produces:

    crypto/rsa: verification error [http://crl.identrust.com/DSTROOTCAX3CRL.crl]

This EE certificate itself does not have a CRL DP. That URL comes from (one of) the issuer certificates.

Could you comment on what is happening here?

- Is crt.sh accidentally picking up the CRL from the issuer certificate and trying to verify the EE cert against that?

- Is crt.sh trying to verify the entire chain and encountering the error when checking whether an issuer is revoked?

As far as I can vaguely remember, this wasn't happening before the Go rewrite.

Thanks!

Alex

[r...@sectigo.com]

Hi Alex.

> - Is crt.sh accidentally picking up the CRL from the issuer certificate and trying to verify the EE cert against that?

In the CCADB record for https://crt.sh/?id=3479778542, Identrust have entered "http://crl.identrust.com/DSTROOTCAX3CRL.crl" into the "Full CRL Issued By This CA" field.  Although "This CA" is intended to mean the Subject of the certificate (i.e., R3), Identrust have apparently misinterpreted it to mean the Issuer of the certificate (i.e., DST Root CA X3).

crt.sh uses the "Full CRL Issued By This CA" field as an additional source of CRL Distribution Point URLs.  Since the data is supplied by the CA responsible for disclosing the certificate, crt.sh assumes that it's authoritative and correct!

> - Is crt.sh trying to verify the entire chain and encountering the error when checking whether an issuer is revoked?

No.  Having accepted the incorrectly specified CDP URL, crt.sh is trying to (1) access that URL, (2) parse it as a CRL, and (3) verify its signature using the CA's public key.  There's no chain validation going on.  Steps 1 and 2 succeed, but step 3 understandably fails.

If I manually remove the incorrect record from the crt.sh DB's "crl" table right now, it'll be automatically recreated the next time crt.sh pulls the CCADB data (which happens every 10 minutes).  So we'll need to wait for Identrust to fix the CCADB record first.  I've just reported this issue to Identrust via an email to the primary "CA Email Alias" listed in their "CA Owner" CCADB record.

[r...@sectigo.com]

Identrust have fixed that CCADB record, and I've just deleted the "crl" record.