335874 - error -8048 (Invalid OCSP signing certificate) with OCSP enabled

Status: RESOLVED WORKSFORME

(NSS :: Libraries, defect, P3)

Description

[Kai Engert (:KaiE:)]

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

Comment 1

[Kai Engert (:KaiE:)]

Attachment: ROOT cert

Comment 2

[Kai Engert (:KaiE:)]

Attachment: CHAIN of certs

Comment 3

[Kai Engert (:KaiE:)]

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

Comment 4

[Robert Relyea]

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

Comment 5

[Robert Relyea]

Attachment: Responder Certificate

Comment 6

[Robert Relyea]

Attachment: Intermediate Sent With Responder

Comment 7

[Robert Relyea]

Attachment: Root Sent with Responder

Comment 8

[Robert Relyea]

Attachment: Responder Cert (Pretty Print)

Comment 9

[Robert Relyea]

Attachment: Intermediate Cert Sent with Responder (pretty print)

Comment 10

[Robert Relyea]

Attachment: Root Sent with Responder

Comment 11

[Robert Relyea]

Attachment: Root Sent with Responder (pretty print)

Comment 12

[vwm]

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.

Comment 13

[Julien Pierre]

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.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Attachment: ROOT cert (pretty print)

Pretty printed version of first cert attached above

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

Attachment: CHAIN of certs (pretty print)

pretty printed PKCS7 file containing two certs

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

Attachment: https server's cert

Comment 18

[Nelson Bolyard (seldom reads bugmail)]

Attachment: https server's cert (pretty print)

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

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?  

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 23

[Kai Engert (:KaiE:)]

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.

Comment 24

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 25

[Julien Pierre]

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.

Comment 26

[Red_Blue]

(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

Comment 27

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 28

[Nelson Bolyard (seldom reads bugmail)]

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.