This is seen using a special build of Firefox, that uses NSS_3_11_2_BETA Steps to reproduce: - start with empty cert db - start firefox - enable OCSP (certs with service url) - import attached ROOT file (contains one root only), trust all - go to https://eca-ca.orc.com/ - get error -8048 error -8048 means: SEC_ERROR_OCSP_INVALID_SIGNING_CERT "Invalid OCSP signing certificate in OCSP response." Surprisingly, the following WORKS: - start with empty cert db - start firefox - enable OCSP (certs with service url) - go to https://eca-ca.orc.com/ - works fine Suprisingly, the following WORKS, TOO: - start with empty cert db - start firefox - enable OCSP (certs with service url) - import attached CHAIN file (root and intermediate), trust all (note, the chain file was obtained from https://eca-ca.orc.com/getCAChain?op=download&mimeType=application/x-x509-ca-cert ) - go to https://eca-ca.orc.com/ - works fine

Note, when I said "import file" I meant: - open cert manager - go to authorities tab - hit import button - select file - check all boxes - OK

Additional information, the OCSP responder is including both an intermediate and root cert which are different than the above chain in it's response. I'll post them to the bug shortly. I don't know why the correct CA is selected if the above intermediate is in the database. If I don't load the incorrect root from the OCSP response, then the verification succeeds (expected behavior). I see 2 bugs coming together here: 1) NSS is not prefering the trusted issuer cert when selecting an issuer. 2) The OCSP responder is incorrectly sending the root certificate. We can avoid the first issue by not loading any untrusted selfsigne roots from a response (such certs are not useful in validating a cert since if we chain to them we will fail). bob

I encountered similar problems with CAcert.org certificates. As soon as I turn on OCSP (using the OCSP-Service-URL), Firefox (1.5.0.3) returns an -8048 for every https site I try to enter that is based on a CAcert.org certificate. Example Error: “Alert” “Error establishing an encrypted connection to secure.cacert.org. Error Code: -8048.” Moreover Thunderbird (1.5.0.2 (20060308)) refuses to Sign my mails usind CAcert Certificates as long as OCSP is turned on. When I look at my personal certificates using the Certificate Manager it says “Could not verify this certificate for unknown reasons.” (Firefox) “Dieses Zertifikat konnte aus unbekannten Gründen nicht verifiziert werden.”(Thunderbird. German Error Message with the same meaning as the above stated English one.) Note that there is no such message if I lock at the authorities’ certificates “CAcert Class 3 Root” and “CA Cert Signing Authority”. Even if this is a CAcert Bug, the error messages should be improved.

The reason you don't see this error in the cert manager is that OCSP gets turned off when the cert manager opens, and then back off when the cert manager exits. Unfortunately, there is no way to improve the current error message for OCSP given the current APIs.

Pretty printed version of first cert attached above

In comment 0, this bug says: > Surprisingly, the following WORKS: > - start with empty cert db > - start firefox > - enable OCSP (certs with service url) > - go to https://eca-ca.orc.com/ > - works fine That's not what I experience. I get the dialog about the cert having an untrusted issuer. That's what I expect, and that's what I experience. I'm testing with SeaMonkey 1.0.1 + NSS 3_11_2 BETA

pretty printed PKCS7 file containing two certs

I'm wondering, are this server and these unusual cert chains part of a test bed, perhaps, set up to test PKI implementations to see if they can be deceived into declaring invalid chains as valid?

In comment 0, Kai wrote: > Suprisingly, the following WORKS, TOO: > - start with empty cert db > - start firefox > - enable OCSP (certs with service url) > - import attached CHAIN file (root and intermediate), trust all > (note, the chain file was obtained from >https://eca-ca.orc.com/getCAChain?op=download&mimeType=application/x-x509-ca-cert ) > - go to https://eca-ca.orc.com/ > - works fine When you go to that https url to download the CHAIN file, you must accept the server cert to complete that download. That act causes the cert to be marked valid, obviating the OCSP checks for the remainder of that process lifetime. I found that, after importing the CHAIN file and trusting its root, if you then restart the process, it behaves the same as when only the original root had been imported and trusted. So, importing the intermediate CA cert really has no effect. I confirm the first problem reported in comment 0 above, but not the second or third problems reported therein. This is (in my opinion) an extremely contrived test case. I'm not sure there's any erroneous behavior here, at all. Let me try to concisely describe this odd test case. There are two root certs, identical in *all* respects except serial number and signature. They have the same subject names, same public keys, same validity periods, same extensions, same subject key IDs (SKIDS). Their serial numbers are 7 and 14. There are two intermediate CA certs, identical in *all* respects except serial numbers and signatures. They have the same issuer names, subject names, public keys, validity periods, extensions, authority Key IDs (AKIDs), subject key IDs (SKIDs), same policy extensions. Their serial numbers are 8 and 26. I believe they are interchangable in all respects. The https server sends a cert chain containing its own cert (serial 36), its intermediate CA cert (serial 26) and its root (serial 14). (This is the content of the "CHAIN" file attached above.) The OCSP responder sends a cert chain containing its own cert (serial 14554), its intermediate CA cert (serial 8) and its root (serial 7). When root (serial 14) is imported and trusted, but root (serial 7) is not, NSS declares the OCSP responder's cert chain invalid. (NOTE that this is NOT an "unauthorized response" error, but an invalid cert error. That's a subtle but important difference here.) Whether intermediate CA cert (serial 26 is imported or not seems to make no difference (at least while it remains untrusted). IMO, it is correct to validate the chain that is presented, rather than to construct a new chain and attempt to validate that in place of the chain we received. And so, I think NSS's present behavior of declaring this OCSP responder's chain (14554 -> 8 -> 7) invalid is correct. But NSS thinks it IS constructing a replacement chain, so the question is: why is it constructing a replacement chain that does not prefer the trusted perm cert to the temporary one?

In reply to comment 19, to put it antoher way, if this user (CMS customer) is NOT trying to create a convoluted test case, and is just trying to setup a normal PKI. Perhaps they're just a CMS user who got themselves into trouble by creating too many almost-identical root certss and too many almost-identical intermediate CAs. If that is the case, then they need to pick ONE of those two almost-identical root CA certs, and ONE of those two almost-identical intermediate CA certs, and then use those two chosen certs, and ONLY those two chosen certs, in all their servers and clients. That includes their their https (CMS) server and their OCSP responder, and all their other servers and clients. They need to abandon any other roots that may be confused with the ir one chosen root, and to abandon any other intermediate CAs that may be confused with their intermediate CAs. Then things should start to work normally for them.

This is yet another instance of PSM's infamous "for unknown reasons" dialog.

If I understand correctly, your assessment is - there is no bug in NSS - we need to tell the CMS customer to clean up their environment So this bug could be resolved as INVALID. In addition you are proposing that PSM's error message could be improved. In bug 107491 we'll eventually add the human readable string in addition to the error code. But I don't think the text "Invalid OCSP signing certificate" will give a real clue to end users, we'd still need to analyze as deeply as you did to understand what's going on.

Kai, THIS particular bug is extremely contrived. I'm not sure if better error text would have helped THIS bug, but it would surely help resolve the typical non-contrived bug. The NSS developers need to decide if this bug is a real bug or not. There is no specification for this unusual and contrived case. If we decided it is a real bug, then we also need to decide how important it is to fix in a timely fashion. IMO, it IS a real bug, but it isn't worth fixing, because it only happens under the most contrived circumstances and it fails safe. This bug is somewhat unusual in that the end user seems to be uninvolved in it. IMO, someone needs to speak for the end user, and tell us if this contrived problem was accidental or intentional. Did they intend to have multiple almost-identical root and intermediate CA certs? or was that an accidental result of learning about CMS as a new user? If accidental, I think we should mark this bug invalid. If intentional, perhaps WONTFIX.

This problem will be resolved when libpkix is available and used. When validating the OCSP signing cert, libpkix will explore all possible certification paths - and will prefer trusted issuers to begin with. Thus, the error will not manifest itself, even with this contrived environment.

(In reply to comment #12) > I encountered similar problems with CAcert.org certificates. As soon as I turn > on OCSP (using the OCSP-Service-URL), Firefox (1.5.0.3) returns an -8048 for > every https site I try to enter that is based on a CAcert.org certificate. The problem is in CAcert's "OCSP Responder" certificate (serial#74271) being expired on "Not After : May 16 04:45:44 2006 GMT". It has been reported to CAcert.org via their "bugzilla" already almost 2 moths ago, with nothing done to fix it. Since you need an account just to read the bug database, here is a picture of it: http://img209.imageshack.us/img209/8697/cacertocsp1ju.png

Today, using a recent trunk browser build, I took a fresh profile, imported the ROOT cert attached to this bug (the first attachment) and marked it trusted. Then I visited the original URL found in comment 0, which was https://eca-ca.orc.com/ and it all worked without any problem. I suspect that the user has gotten rid of the confusing almost-duplicate root and intermediate CA certs, and is now using the same certs consistently. In any case, if this is no longer an issue, can we now resolve this worksforme?

I took a fresh look at the information previously recorded in this bug, including the various CA certs, and I now completely understand what was originally going on, and why NSS behaved as it did. Recall from comment 20 that there were two nearly identical root CA certs, and two nearly identical intermediate CA certs. The two roots were identical to each other except for serial number, validity dates, and signatures. Likewise, the two intermediate CA certs were identical to each other, except for serial numbers, validity dates, and signatures. Here is a table summarizing the CA certs involved. Server's OCSP responder's Chain Chain Root CA serial # 14 7 Validity 2004 Jun 14 10:20:09 2004 Jun 14 11:18:09 (newer) 2040 Jun 14 10:20:09 2040 Jun 14 11:18:09 (newer) Subject CN=ECA Root CA, OU=ECA, (same subject as server root) O=U.S. Government, C=US Pub Key ae:4a:f6:79:[...] (same pub key as server root) 76:41:5a:71 AKID & SKID f6:b8:04:27: (same AKID & SKID as server root) 0e:56:16:d9: b9:63:d9:fd: a1:54:65:41: a0:08:48:2f Policy OIDs 2.16.840.1.101.3.2.1.12.1 (same policy OIDs as server root) 2.16.840.1.101.3.2.1.12.2 Intermediate CA serial # 26 8 Validity 2004 Jun 14 13:04:51 2004 Jun 14 12:04:51 (Older) 2010 Jun 15 12:04:51 2010 Jun 15 11:04:51 (older) Subject CN=ORC ECA, OU=Certification Authorities, (same subject as server CA) OU=ECA, O=U.S. Government, C=US Pub key 87:e6:de:6a:[...] (same pub key as server CA) 23:af:3f:cd SKID ac:f7:4b:b6: (same SKID as server CA) d6:d2:36:69: f3:bb:a2:03: 67:97:19:87: 33:65:2e:a5 Policy OIDs (same as both roots) (same as both roots) The two intermediate CA certs were both equally valid and were completely interchangeable (for cert path validation purposes). The server's intermediate CA cert was newer than the OCSP responder's CA cert, and so NSS always used the server's intermediate CA cert. But it really didn't matter. Either one would have worked as well. It all comes down to the validity dates on the root CA certs. The OCSP responder's root CA cert was newer, by about an hour, than the https server's root CA cert. So, when both certs were in memory, NSS versions before 3.12 (and the non-PKIX code in 3.12) always used the newer one. The newer one was not trusted. The older one was. So, when validating the chain for the OCSP responder's cert, the chain led to an untrusted root, which is why NSS reported that the OCSP responder's cert was invalid. So, I conclude that NSS was working correctly all along. Today, the server is using a different cert, one that does not include an AIA extension specifying OCSP at all. So, Any test of that URL today does not reproduce the problem.