[Mod_nss-list] OCSP errors

Kim, Ernest ekim at mitre.org
Thu Aug 20 14:46:04 UTC 2009


>-----Original Message-----
>From: Rob Crittenden [mailto:rcritten at redhat.com]
>Sent: Thursday, August 20, 2009 10:27 AM
>To: Kim, Ernest
>Cc: mod_nss-list at redhat.com
>Subject: Re: [Mod_nss-list] OCSP errors
>
[TRIMMED]
>>
>> Hi Rob, thanks for your reply.
>>
>>> The server is validating its own server certificate at startup and
>that
>>> request is failing so the server is refusing to start.
>>
>> I don't understand why this is. With OCSP turned off, I can start my
>server
>> using the same RapidSSL certificate for https without having to use
>the .
>> Furthermore when I do a certutil -V on my RapidSSL certificate, it
>responds
>> saying that the certificate is valid. Here are the results of my
>certutil -L
>> -d...
>
>Right, the problem isn't with the certificate validity. When the server
>starts and OCSP is enabled then NSS is going to use OCSP to valid it.
>The OCSP response is signed by an untrusted entity so NSS is marking the
>certificate as unverified so the server refuses to start.

Ohhh... I just had a light bulb moment.  So correct me if I'm wrong here,
because we have the default OCSP responder turned on, the RapidSSL
certificate is being sent to our default OCSP responder for validity.  But
our SSL certificate wasn't issued by our default OSCP responder.  It was
issued by RapidSSL which is a child of Equifax.  Our default OCSP responder
is the DoD's OCSP responder for CACs.  And as a result, when the DoD
responder gets the RapidSSL it's sending back an invalid cert message.  And
this is the reason why NSS is giving the error messages it is.  If I remove
the default responder settings, I should be okay right?  The OCSP responder
in the RapidSSL certificate (if there is one) will say that the certificate
is valid (hopefully), right?

>
>>
>> Server-Cert                                                  u,u,u
>> Equifax-CA                                                   CT,C,C
>> alpha                                                        u,pu,u
>> RapidSSL-CA                                                  CT,C,C
>> RapidSSL                                                     u,u,u
>> cacert                                                       CTu,Cu,Cu
>> ocsp-responder                                               CT,C,C
>>
>> certutil -V -n RapidSSL -u V comes up with this:
>>
>> certutil -V -n RapidSSL -u V -d /etc/httpd/alias/
>> certutil: certificate is valid
>
>You might want to try /usr/lib/nss/unsupported-tools/ocspclnt as well.
>You might be more details on the OCSP response.
>
>>> You need to trust the certificate that is signing the OCSP response.
>I
>>> didn't see that after a quick look on the RapidSSL site, maybe their
>>> support can point you to it.
>>
>> I do trust the certificate, It's the certificate with the nickname
>> ocsp-responder.  It's issued by the DoD.
>
>Ok, there is a bit of a difference in your configuration vs your
>database. You set NSSOCSPDefaultName to ocsp-disa-mil-responder but the
>cert nickname is ocsp-responder. Can you try changing the configuration
>to match the nickname?

Yup they do.  It was a typo on my part when writing up the email message.  

-Ernie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3497 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/mod_nss-list/attachments/20090820/3b9469db/attachment.bin>


More information about the Mod_nss-list mailing list