1418150 - Comodo: Certificação Digital, SSL Blindado PRO EV, Certificate signature algorithm does not match TBS signature algorithm

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Compliance, task)

Description

[chris]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

The following non-compliant certificate was discovered during an audit of the CCADB.

https://crt.sh/?id=12730101&opt=cablint

Comment 1

[Ryan Sleevi]

Gerv: I suggest considering this whole swath of bugs as WONTFIX. As the Signature algorithm encoding necesssarily is not covered by the Signature itself, anyone can mutate it without invalidating the Signature. As such, mismatches cannot categorically he attributed to the CA.

Comment 2

[Rob Stradling]

Ryan is correct that Certificate.signatureAlgorithm is not covered by the Signature itself.  However, TBSCertificate.signature _is_ covered by the Signature, and it's a mismatch between that field and the actual Signature that Chris has correctly identified.

WHAT WENT WRONG?
We constructed the TBSCertificate for this intermediate CA certificate (https://crt.sh/?id=12730101) on August 19th 2013.  We made the mistake of setting TBSCertificate.signature to sha384WithRSAEncryption, whereas it should have been set to sha1WithRSAEncryption.  We signed the TBSCertificate (using sha1WithRSAEncryption) on the same day.

WHY WASN'T THIS MISTAKE SPOTTED IMMEDIATELY?
To defend against making this sort of mistake, our procedure is to first sign the TBSCertificate with a dummy private key, and then to manually review the resulting "test profile" using the "openssl x509" command-line tool.  Only after confirming that all of the fields look correct do we proceed to signing the TBSCertificate with the real issuing CA's private key.

Unfortunately, there was a bug in OpenSSL at that time.  "openssl x509" displayed "sha1WithRSAEncryption" for both the Certificate.signatureAlgorithm field and the TBSCertificate.signature field, which hid the mistake from the eyes that performed the manual review.

WHEN WAS THIS MISTAKE SPOTTED?
Leaf certificates were issued from this intermediate and used successfully for over a year.  It wasn't until September 2014 that we discovered that some lesser-used platforms were rejecting this intermediate certificate, and upon investigating this problem we discovered the signature algorithm mismatch.  The managed CA partner did not ask us to reissue this intermediate.  We assumed human error during the August 19th 2013 manual review rather than pointing the finger at OpenSSL.

FIXING OPENSSL
Some time later I eventually spotted that there was a bug in OpenSSL.  I contributed a fix, which was committed on January 22nd 2015 and just made it into OpenSSL 1.0.2 (by a matter of hours!):
https://git.openssl.org/?p=openssl.git;a=commit;h=004efdbb41f731d36bf12d251909aaa08704a756

REVOCATION?
We have observed that some clients don't complain about signature algorithm mismatches of this sort.  We have also observed that some CAs have run into problems when revoking one of several peer intermediates.  Therefore, we do not plan to revoke https://crt.sh/?id=12730101.

Comment 3

[Gervase Markham [:gerv]]

That seems like a pretty clear and reasonable explanation, and the patch is classic :-)

Gerv