Closed Bug 235529 Opened 20 years ago Closed 20 years ago

Mozilla 1.7 complains about "invalid certificate" Mozilla 1.6 doesn't

Categories

(Core Graveyard :: Security: UI, defect)

Product:
Core Graveyard
Component:
Security: UI
Version:
Other Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 204835

People

(Reporter: bugzilla, Assigned: KaiE)

Details

Attachments

(1 file)

zip file contains all certs from both cert chains
9.44 KB, application/zip
Details 
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
Closed: 20 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.
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.
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: