Re: Invalid certificate alert
John Gardiner Myers wrote: This has been filed as bug 235585. Currently, PSM is determining what to fingerprint itself, it isn't calling into NSS. I'd appreciate if you could provide details of what was changed and when in the bug, so I can decide whether to fix it or not. Several points about this proposal. 1. Fingerprints are only used for people to verify that they have the same cert, e.g. over the phone, and this is needed only when importing new roots, or otherwise previously untrusted certs. To that end, it is vital that NSS, PSM, OpenSSL and others compute fingerprints in the same way, as they now do. The agreed algorithm is to compute the hash over the entire cert, stem to stern. If PSM changes it unilaterally, it will no longer be possible for OpenSSL users to compare results with mozilla users. 2. fingerprints are irrelevant to Henrik's issue. NSS doesn't use fingerprints internally when comparing two certs to see if they are or are not equal, so the fingerprint algoirthm is completely irrelevant to that issue. 3. When comparing two certs to see if they are identical, it is necessary to compare (a) the signed data, and (b) the signature itself. 4. For two signatures to be equal, they must have the same length (in bits), and all the bits within that specified length must be the same. If the two signatures are of equal length, and both have an equal number of unused bits, and the unused bits differ, then I could be persuaded that those signaures are nonetheless identical. BUT THAT IS NOT THE SITUATION HERE. In this case, it is not the actual unused bits that differ, but rather it is the NUMBER OF UNUSED BITS that differ. One cert claims to have a 2048 bit signaure (no unused bits). The other claims to have a 2047 bit signature (1 unused bit). Hence the two signatures are not of equal lengths, and therefore CANNOT be identical. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Julien Pierre wrote: Thanks for tracking the problem down with the certificate ! Well, I try to not only be the guy who constantly bugs you about the /right/ way to validate a CRL ;-) ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Jean-Marc Desperrier wrote: I didn't require that :-) I believe this also means you use the same alg as Microsoft CAPI which makes things simpler for everybody. And the specification for that algorithm would be where ? The signed part of them should. The unsigned part is not required to. Can you give any pointer to specs that document this ? In fact, openssl used to produce all certs with some BER elements in the unsigned part in the earlier versions (0.9.4). And as many CA don't issue truly DER encoded certificate, every toolkit just has no choice but to support it. Actually, NSS has not supported any BER encoding in certs since version 3.6, about a year and a half ago, since the QuickDER decoder was introduced and used in the cert dedcoding, as opposed to the more versatile but much slower BER/DER decoder. This padding issue is the first one I hear about that points to BER encoding in certs. So, perhaps CAs really do issuer DER certificates ? Or users of CAs that don't aren't using any NSS-based products such as Mozilla. Therefore, opposite to what I thought before watching in exact details, the version that has one unused bit set is the correct DER encoding version, and the one that does not set one unused bit, but instead includes it with a value of zero, is BER encoding and not DER encoding. The decoded value of the signature is exactly the same in the two case, so it's normal that signature verification does not fail. No, they are two different cases. The example you cite in the key usage is not a plain BIT STRING, but rather a named bit list, and the DER encoding for that dictates the shortest possible encoding, which in this case means truncating the upper byte if all its bits are 0, and removing the upper bit in the lower byte, if it is zero. Signatures are encoded as plain BIT STRING, not a named bit lists. The DER encoding rules for it specify that upper bits should not be removed even if they are zero. Imagine a 2048 bits RSA signature that just happened to have all 1024 upper bits set to zero. If encoded as name bit string like key usage, it would be indistinguishable from a 1024 bit signature. The DER encoding for BIT STRING must only remove the bits that are not part of the string, not all non-significant zeroes. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Henrik, Henrik Gemal wrote: Thanx for the into Pierre. First name is Julien actually... 2 Could you help determine the cause of this alert to I can report it to the server admins. I narrowed it down to these URL. To reproduces first go to: https://i.tdconline.dk/tdco/gfx/local/sso/knap_q.gif then go to: https://bestilling.certifikat.tdc.dk/csp/authenticode/README and you get the error. I couldn't reproduce the problem browsing these two URLs with Mozilla 1.6. Try with a brand new profile and a fresh mozilla. The serial number is most likely in conflict with one of the permanent certs in your database . That could be either your personal certificate, or one of the intermediate certificates . Look at the serial numbers in the entire certificate chain, not just the final certificate (end entity). ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Henrik Gemal wrote:
I narrowed it down to these URL. To reproduces first go to:
https://i.tdconline.dk/tdco/gfx/local/sso/knap_q.gif
then go to:
https://bestilling.certifikat.tdc.dk/csp/authenticode/README
You found a *very* interesting case.
The culprint is the third certificate in the certificate chain, not the
server certificate itself.
And the problem is that *one* *bit* of data is different between the
two. But it's not inside the signed part of the certificate, not even
really inside the data, just inside the der padding.
It makes the der encoding only very slightly invalid, der decoders will
just ignore the error. dumpasn1 does report it, but not openssl
asn1parse. Haven't tested with NSS's asn1 dumping tool;-)
But the fingerprint of the two certificates do not match anymore, so NSS
reports them as two different certs with the same serial number.
Maybe for *that* particular case, NSS should use a fingerprint based on
the signed part of the cert.
It is annoying to not be able to use the cert, because of an error on
the unsigned part of it, that certainly has nothing to see with the ca,
but some mistreatment later.
On the other hand, this kind of case might be very rare, and maybe you
can just solve it by telling the server operator they got something
wrong when they installed i.tdconline.dk by showing them, the cert is a
bit different from the supposedly same cert from bestbilling.
If you want to reproduce you can use :
openssl s_client -connect i.tdconline.dk:443 -showcerts
openssl s_client -connect bestilling.certifikat.tdc.dk:443 -showcerts
and Peter Gutmann's dumpasn1.
Joining the two certs as attachment, as well as dumpasn1 output.
-BEGIN CERTIFICATE-
MIIDhDCCAmygAwIBAgILAQAA5fIRge4wDQYJKoZIhvcNAQEFBQAwXzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExFDASBgNVBAsTC1Bh
cnRuZXJzIENBMR8wHQYDVQQDExZHbG9iYWxTaWduIFBhcnRuZXJzIENBMB4XDTAx
MDQwMTEyMDAwMFoXDTA4MTIzMTEyMDAwMFowQzELMAkGA1UEBhMCREsxFTATBgNV
BAoTDFREQyBJbnRlcm5ldDEdMBsGA1UECxMUVERDIEludGVybmV0IFJvb3QgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDEuEC8kdVjH9eZoIsMQB50
t0idRowCsuAkX/AZE6c3g2tdx475hDDOGjv6+86LbSPGw25mn4ml3+BCUGf6H2we
9NAF1r/K1k7kaGBsRqocXWPhB4YOZQCnLqZxxry5gag6fRrS+dGsS8vOda/ce/qB
c9T8ur1BiNR0s/leODo8Q6jSlU53bRMMnY94AbdaIB8DNzXiLNtLKyx4uUnbxNDH
nJzkiiAJIRZWZv8F7Fvj8M+rJCRew39wehLE0rUQoLYh4Y14aVVEafXKlhw0hRcl
d+L2LyeYeP15Bjqi1lpDwf/sBDvuE+/TWFr/kuvsrtryNwNHQbaXyS0KQSK7u+an
AgMBAAGjXTBbMAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQUbGQBx/2FbazI2p5QCIUI
tTxWqFAwHwYDVR0jBBgwFoAUQySNcBUIYlWcTwxAF12GXg+iTPswDAYDVR0TBAUw
AwEB/zANBgkqhkiG9w0BAQUFAAOCAQEBOHbxCwLKbxsuL9kLsTaP6Ky6qqxWs51t
kT4EkuIEzxkuD4jwCXY+MvS55uw5Y3dQ9Ln2XEPIY6dY8qJXQOP9JWA6YvPWONSX
BDXCFuyxnpZrOjG4Ofp6hDosNQE7+U7VSnL0uaZK2vT7VEaXxmEMELngDb8FcSKs
BehWbmeTAunQphF3HAhSlk2q+tN6d1mNIutQfdrHOl+Z7rbCF4PrWylcg/6wwzcu
KGKTVblmUG3HjyoqGkvRN05Wbl/P73LLN62dPpECliyE/NFEB0XBWuNin3GJkxqZ
/uIfhiwuqlYcfddKe+rSc9Y79azxsp3K9qObGJjHf/xa/k80ovy2/g==
-END CERTIFICATE-
Cannot open config file 'dumpasn1.cfg', which should be in the same
directory as the dumpasn1 program, a standard system directory, or
in a location pointed to by the DUMPASN1_PATH environment variable.
Operation will continue without the ability to display Object
Identifier information.
If the config file is located elsewhere, you can set the environment
variable DUMPASN1_PATH to the path to the file.
30 82 03 84 30 82 02 6C A0 03 02 01 02 02 0B 01 00 00 00 00 00 E5 F2 11
0 900: SEQUENCE {
30 82 02 6C A0 03 02 01 02 02 0B 01 00 00 00 00 00 E5 F2 11 81 EE 30 0D
4 620: SEQUENCE {
A0 03 02 01 02
83: [0] {
02 01 02
101: INTEGER 2
: }
02 0B 01 00 00 00 00 00 E5 F2 11 81 EE
13 11: INTEGER 01 00 00 00 00 00 E5 F2 11 81 EE
30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00
26 13: SEQUENCE {
06 09 2A 86 48 86 F7 0D 01 01 05
289: OBJECT IDENTIFIER '1 2 840 113549 1 1 5'
05 00
390: NULL
: }
30 5F 31 0B 30 09 06 03 55 04 06 13 02 42 45 31 19 30 17 06 03 55 04 0A
41 95: SEQUENCE {
31 0B 30 09 06 03 55 04 06 13 02 42 45
43 11: SET {
30 09 06 03 55 04 06 13 02 42 45
459: SEQUENCE {
06 03 55 04 06
473: OBJECT IDENTIFIER '2 5 4 6'
13 02 42 45
522: PrintableString 'BE'
: }
: }
31 19 30 17 06 03 55 04 0A 13 10 47 6C 6F 62 61 6C 53 69 67 6E 20 6E 76
56 25: SET {
30 17 06 03 55 04 0A 13 10 47 6C 6F 62 61 6C 53 69 67 6E 20 6E 76 2D 73
58 23: SEQUENCE {
06 03 55 04 0A
603: OBJECT IDENTIFIER '2 5 4 10'
13 10 47 6C 6F 62 61 6C 53 69 67 6E 20 6E 76 2D 73 61
65 16: PrintableString 'GlobalSign nv-sa'
: }
: }
31 14 30 12 06 03 55 04 0B 13 0B 50 61 72 74 6E 65 72 73 20 43 41
83 20: SET {
30 12 06 03 55 04 0B 13 0B 50 61 72 74 6E 65 72 73 20 43 41
85
Re: Invalid certificate alert
Jean-Marc, Jean-Marc Desperrier wrote: But the fingerprint of the two certificates do not match anymore, so NSS reports them as two different certs with the same serial number. Maybe for *that* particular case, NSS should use a fingerprint based on the signed part of the cert. It is annoying to not be able to use the cert, because of an error on the unsigned part of it, that certainly has nothing to see with the ca, but some mistreatment later. I disagree that NSS should blindly accept these certs, on the contrary I think it should detect the encoding error. First, both NSS and OpenSSL are now using the same algorithm to compute fingerprints - on the entire certificate encoding, not the signed part. We had complaints that it was different and made it match (I don't remember what the difference was, as I didn't write the fix, I think Nelson did). So, if we change NSS to compute the fingerprint differently, then it will not match with OpenSSL's fingerprint once again. Second, certificates are supposed to be DER-encoded, which means Distinguished Encoding Rules, precisely so that there can only be one possible encoding for them. This case clearly violates it and the server or CA operator should fix it. NSS should be able to detect it. If it did, we would have known from the beginning which one of the two certificate chains was bad. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Julien Pierre wrote: First, both NSS and OpenSSL are now using the same algorithm to compute fingerprints - on the entire certificate encoding, not the signed part. We had complaints that it was different and made it match (I don't remember what the difference was, as I didn't write the fix, I think Nelson did). So, if we change NSS to compute the fingerprint differently, then it will not match with OpenSSL's fingerprint once again. This has been filed as bug 235585. Currently, PSM is determining what to fingerprint itself, it isn't calling into NSS. I'd appreciate if you could provide details of what was changed and when in the bug, so I can decide whether to fix it or not. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Invalid certificate alert
I'm having problem accessing sites where I have to present my digital signature. I'm getting the error that's attached. I have no idea what it means. And the text in the alert box isn't clear enough. Is it a problem with my certificate or the server? -- Henrik Gemal Mozilla Evangelist Mozilla Blog with news, devinfo, links, etc: http://gemal.dk inline: certalert.png
Re: Invalid certificate alert
Henrik, I thought the message made it quite clear that it is a problem with the server. There could be a lot of reasons for this, but the main one is somebody is trying to play CA and does not know the rules of PKI. They may have issued multiple server certs with the same serial number, or even your client cert with the same serial number as their server cert. That's not legal and that's why Mozilla tells you. You need to contact the server administrator as instructed. We have a bug in bugzilla that explain this in more detail, but I can't recall the number right now. Henrik Gemal wrote: I'm having problem accessing sites where I have to present my digital signature. I'm getting the error that's attached. I have no idea what it means. And the text in the alert box isn't clear enough. Is it a problem with my certificate or the server? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
