18

I just ran a quick test at ssllabs.com: got A+, which I'm happy about.

However there's one thing I don't know how to "fix": My site supports OCSP stapling and ssllabs keeps telling me: Chain issues: Contains anchor. I know this is just a "warning" in the sense that it slows down the connection a bit.

nginx config:

..
ssl_certificate             public.crt;
ssl_certificate_key         private.key;
ssl_stapling                on;
ssl_stapling_verify         on;
ssl_trusted_certificate     my-chain.pem;
..

Where:
- public.crt is the public certificate I got from StartSSL
- private.key the certificate's private key
- my-chain.pem (ssllabs calls this: "Additional Certificates (if supplied)") consist of:

1.) StartCom Class 1 Primary Intermediate Server CA  
2.) StartCom Certification Authority

I found a site which also uses StartCom (StartSSL) certificates, supports OCSP stapling, but does not have the issue described above.

This site's "Additional Certificates":

1.) StartCom Class 1 Primary Intermediate Server CA

I've tried the same: Only put "StartCom Class 1 Primary Intermediate Server CA" to my-chain.pem.
However then ssllabs says: OCSP stapling: No So this seems to completely break OCSP stapling.

Any idea?

EDIT:

Finally fixed!

ssl_certificate = Site certificate + StartCom Class 1 Primary Intermediate Server CA  
ssl_trusted_certificate = StartCom Class 1 Primary Intermediate Server CA + StartCom Certification Authority
  • 2
    BTW, just as a word of caution to others. When Ben says ssl_certificate = Site certificate + StartCom Class 1 Primary Intermediate Server CA that is not actually a directive in the config. + signs are not allowed. You need to merge it in the files themselves. Would be neat though if the syntax was accepted – cavalcade Feb 23 '15 at 2:50
  • 1
    I know you've stated that you know it's a warning, but for anyone else coming across this there isn't necessarily a problem sending the trust anchor: see security.stackexchange.com/a/24566/7043 which covers this. – Chris J Jun 17 '15 at 10:05
10

According to nginx documentation the ssl_trusted_certificate parameter contains trusted CA certificates used to verify client certificates and OCSP responses if ssl_stapling is enabled and the list of these certificates will not be sent to clients.

Therefore I think that what ssllabs calls "Additional Certificates (if supplied)" are the certificates in the ssl_certificate file which are not the server certificate.

For me:

public.crt should contain these 2 certificates:

1) your server certificate
2) StartCom Class 1 Primary Intermediate Server CA 

my-chain.pem should contain these 2 certificates:

1) StartCom Class 1 Primary Intermediate Server CA // required to validate the server certificate OCSP response 
2) StartCom Certification Authority  // required to validate the intermediate CA certificate OCSP response 
  • So confused, what does this mean "and the list of these certificates will not be sent to clients." – cavalcade Feb 23 '15 at 2:37
2

Right now, you have your site's certificate referenced by ssl_certificate and a file containing both the intermediate cert and the CA cert referenced by ssl_trusted_certificate

Instead, what you should do is, have a file containing both your site's cert and the intermediate cert referenced by ssl_certificate and ONLY the CA cert referenced by ssl_trusted_certificate

ie:

public.crt should contain:

1) your site's cert, issued by StartCom
2) StartCom Class 1 Primary Intermediate Server CA 

and my-chain.pem should contain:

1) StartCom Certification Authority

Yes, the is the oppposite of how Apache does things. But nginx != apache.

  • Just tried that. Again -- ssllabs says: OCSP stapling: No – Ben Richard Jan 19 '15 at 15:48
  • Some versions on nginx won't staple until after the site has been loaded at least once. So, if you restart nginx, and then immediately run the test, you'll get a "No" but if you re-run the test again, you should get a "yes". – Joe Sniderman Jan 23 '15 at 15:57
  • Thank you for your comment. It indeed seems that nginx does not share the OCSP information between all worker threads. I finally fixed the "issue" by following Jcs' answer: security.stackexchange.com/questions/79519/… – Ben Richard Jan 31 '15 at 1:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.