I'm trying to track down a bug. I'm not sure if the bug is in the server setup at my ISP or in Mozilla: I'm getting an "invalid certificate" alert error. You can reproduce this error by first going to: https://i.tdconline.dk/tdco/gfx/local/sso/knap_q.gif then go to: https://bestilling.certifikat.tdc.dk/csp/authenticode/README The error is seen in Mozilla 1.7a (20040218) and all later build but NOT in Mozilla 1.6 (20040113)
No error in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040210 Firefox/0.8 but error in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040224 Firefox/0.8.0+
could bug http://bugzilla.mozilla.org/show_bug.cgi?id=230996 have caused this? and is it a bug with mozilla or with the site?
========== First server certificat chain ========== 1a. issuer= /C=DK/O=TDC/OU=TDC SSL Server CA serial=3E2C2432 subject= /C=DK/O=TDC/CN=bestilling.certifikat.tdc.dk MD5 Fingerprint=E0:8E:BC:B4:EA:08:ED:35:E7:B5:B7:EA:52:AC:1A:85 2a. issuer= /C=DK/O=TDC Internet/OU=TDC Internet Root CA serial=3C19DC3B subject= /C=DK/O=TDC/OU=TDC SSL Server CA MD5 Fingerprint=B4:4E:64:89:5A:CF:6E:ED:AF:39:E8:DE:7D:F2:D9:1B 3a. issuer= /C=BE/O=GlobalSign nv-sa/OU=Partners CA/CN=GlobalSign Partners CA serial=010000000000E5F21181EE subject= /C=DK/O=TDC Internet/OU=TDC Internet Root CA MD5 Fingerprint=D3:63:6B:B6:9D:23:0C:9E:C2:B0:4E:C3:38:46:3E:66 4a. issuer= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA serial=020000000000D678B9D1AF subject= /C=BE/O=GlobalSign nv-sa/OU=Partners CA/CN=GlobalSign Partners CA MD5 Fingerprint=3C:75:CD:4C:BD:A9:D0:8A:79:4F:50:16:37:84:F4:2B 5a. issuer= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA serial=020000000000D678B79405 subject= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA MD5 Fingerprint=AB:BF:EA:E3:6B:29:A6:CC:A6:78:35:99:EF:AD:2B:80 ========== Second server certificat chain ========== 1b. issuer= /C=DK/O=TDC/OU=TDC SSL Server CA serial=3E2C2184 subject= /C=DK/ST=Denmark/L=Copenhagen/O=TDC Internet A/S/OU=PEUT/CN=i.tdconline.dk MD5 Fingerprint=E7:D3:51:C1:CD:16:06:22:6F:B4:C8:48:6F:14:0E:03 2b. issuer= /C=DK/O=TDC Internet/OU=TDC Internet Root CA serial=3C19DC3B subject= /C=DK/O=TDC/OU=TDC SSL Server CA MD5 Fingerprint=B4:4E:64:89:5A:CF:6E:ED:AF:39:E8:DE:7D:F2:D9:1B 3b. issuer= /C=BE/O=GlobalSign nv-sa/OU=Partners CA/CN=GlobalSign Partners CA serial=010000000000E5F21181EE subject= /C=DK/O=TDC Internet/OU=TDC Internet Root CA MD5 Fingerprint=59:14:E2:0E:77:D9:34:5E:32:B3:C5:62:F6:B8:E9:B8 4b. issuer= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA serial=020000000000D678B9D1AF subject= /C=BE/O=GlobalSign nv-sa/OU=Partners CA/CN=GlobalSign Partners CA MD5 Fingerprint=3C:75:CD:4C:BD:A9:D0:8A:79:4F:50:16:37:84:F4:2B 5b. issuer= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA serial=020000000000D678B79405 subject= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA MD5 Fingerprint=AB:BF:EA:E3:6B:29:A6:CC:A6:78:35:99:EF:AD:2B:80
The culprit is the third certificate in the chain (3a, 3b). It apparently is exactly the same certificate on the two servers (same name, serial, validity, extensions), but somehow the fingerprint doesn't match. OK, after some binary testing, I found the source of the difference. The byte at offset 647 is different between the two certificates. For tdonline, it's : 01, and for bestbilling : 00. dumpasn1 reports : - tdonline case : <03 82 01 01 01 38 76 F1 0B 02 CA 6F 1B 2E 2F D9 0B B1 36 8F E8 AC BA AA> 643 257: BIT STRING 1 unused bits - bestbilling case : <03 82 01 01 00 38 76 F1 0B 02 CA 6F 1B 2E 2F D9 0B B1 36 8F E8 AC BA AA> 643 257: BIT STRING The difference is of no obvious consequence, because this is the unsigned part of the certificate. Modification in this part, as long as the leave the certificate as valid DER encoding, do not compromise it's validity. Why did this occur ? It maybe be that the cert as found on tdonline is the original cert, and it has a very minor invalidity. The der encoding used to store the cert signature value is 1 bit too long. Somehow before been installed on the besbilling server, the cert got rewritten by some tool (maybe just intended to convert it from binary to ascii form), that decoded the DER encoding, and then recorded the cert from the decoded form, correcting the error. The cert, while containing the same logical data, was no more exactly identical. Or it maybe the reverse, the original cert was the fully correct one, and some tool later very slightly corrupted it. Or maybe it's just a random corruption (gamma ray modified the memory :-)), but the fast it happened just in a way to have a very hard to detect consequence is surprising. But after all, it juts one bit that changed state, so that might be it too. The final conclusion might be that maybe it's not such a great idea to calculate fingerprint on the whole certificate instead of only on the signed data. With this method, two certs might have different fingerprint when their authentified content is the same. Fingerprint comparaison fails where signature verification doesn't which definitively can have some rather unexpected consequences.
This is a dup of bug 204835. Mozilla is right in demanding that there exist at most one cert with a given issuer and serial number. *** This bug has been marked as a duplicate of 204835 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Nelson, This is not a dupe of 204835. I believe in that bug, the padding value change occurred on a part of the data that was signed (key usage extension), which makes both the certificate and their signatures different. In this case, the padding change happens in the unsigned part. The signed parts of the certs are still the same. NSS still needs to enforce that there is only one cert with the issuer and SN, so somebody is doing something wrong and corrupting the bit value as Jean-Marc pointed. Since one of the certs does not conform to DER spec, NSS could go one step further by enforcing the correct padding value and know exactly which one is the incorrectly-encoded cert, and throw an invalid DER decoding error on that cert, instead of a duplicate certificate error (wouldn't error stacks be nice, though, so we could report both). See bug 235627 for the request for stricter DER decoding.
It appears that there is a trusted CA who has issued (and perhaps continues to issue) certs with non-zero values in unused bits. It also appears that some users choose to "edit" their certs to attempt to "correct" this, and in so doing, create problems for themselves. In all cases that I've seen so far, including this one, there was no actual problem with the cert that contained the non-zero unused bits. The user who "fixed" his cert by editing it only caused him self problems. I would not want to make that situation worse by beginning to reject certs that have worked just fine for years, only because we now care about unused bits! When comparing two certs to see if they are identical, it is appropriate to also compare the signatures themselves. Two certs with identical issuers and serial numbers, but different signatures, are different certs, violating the rule about unique certs. And, IMO, that includes the "unused bits".
Could it be the opposite - that the trusted CA is issuing properly DER-encoded certs (with padding values of 0), but the applications using those certs are actually modifying them after they are fetched ? I believe it makes sense to impose stricter compliance to the certificate encoding since the X.690 standard clearly states the encoding rules. See the quote in bug 235627 . It's true that some certificates may have worked for years and no longer will as a result, and it would be good to have some data on just how many, but nevertheless, these new failures would be caused by both incorrect encoding software or certificate corruption at the application level, and the current leniency of NSS (and possibly other clients) WRT ASN.1 DER standard. Perhaps we could define a new error code (SEC_ERROR_DER_INVALID_PADDING) that could be caught by Mozilla, so that we know what's going on the next time this happens and we have an answer for the CA or server operator that has this invalid type of certificate.
In answer to comment 8, in the case of http://bugzilla.mozilla.org/show_bug.cgi?id=204835#c17 the real trusted CA cert has a non-zero unused bit. The "corrected" version of that cert has an invalid signature, because one bit was changed to meet the spec you quoted. See also http://bugzilla.mozilla.org/show_bug.cgi?id=204835#c22 Admittedly, the cert is this bug has the unused bits in a different place in the cert, but IINM, it's the same CA issuing the certs.
Further investigation reveals that the two certs differ, *not* in the content of the unused bits at the end of the signature, but rather in the *LENGTH* of the signatures. More precisely, they differ in the number of unused bits. One signature claims to be a 2047 bit signature. The other claims to be a 2048-bit signature. NSS should find one of those signatures to be invalid; that is, the RSA public key operation should determine the signature value to be incorrect. If it does not, that should be the subject of another bug.
Nelson, You are right that it is the count of padding bits that is the difference here, and not the padding bit value. As you correctly pointed out in a different bug, an RSA signature value should have a length that is a power of two. That may not be true of all current and future signature algorithms, however. After much googling, I found this : http://www.imc.org/ietf-pkix/old-archive-98/msg01153.html It seems there is a distinction between a "bit string" type and a "namedbitlist". Bit strings can have values containing trailing zeroes without the need to "remove" these bits. But namedbitlist must have trailing zeroes removed. Wild guesses here before I go to bed : - digital signatures use regular bitstring (so that it matches the key algorithm, even if most significant bit values are set to zero); but key usage uses namedbitlist. This is what makes this bug different from 204035 . - The check for the value of removed bits to be zero that I proposed would probably be harmless in both cases, and would not trigger the error, since the problem is the wrong number of bits was encoded, not the wrong value of bits. - Indeed a cert with a 2047 bits RSA signature should probably be rejected by NSS ... That test might not belong in the DER decoder, though, but in cert code.
> Indeed a cert with a 2047 bits RSA signature should probably be rejected by > NSS ... That test might not belong in the DER decoder, though, but in cert code. Don't fight wind mills. Too many CA won't get the slight nuance between bit string and namedbitlist and will try to be correct by removing the unused bit.
I've got the ISP to install a new SSL cert so you cant reproduce this bug anymore with the steps described.
With regard to comment 12: > Too many CA won't get the slight nuance between bit string and namedbitlist > and will try to be correct by removing the unused bit. Well, so far, this is the first and only CA that's run into this issue, and we're not even certain that the CA made the mistake. IMO, it is more likely that a web site administrator decided to "correct" the CA's cert.
Created attachment 142811 [details] zip file contains all certs from both cert chains For posterity, this zip file contains all the certs from both cert chains. By comparing the two cert files whose names end in 003, you can see the difference relevant to this bug.
You need to log in before you can comment on or make changes to this bug.