27

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
  • 3
    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, 2015 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.
    – Callie J
    Jun 17, 2015 at 10:05

2 Answers 2

12

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 
1
  • So confused, what does this mean "and the list of these certificates will not be sent to clients."
    – cavalcade
    Feb 23, 2015 at 2:37
3

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.

3
  • Just tried that. Again -- ssllabs says: OCSP stapling: No Jan 19, 2015 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". Jan 23, 2015 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/… Jan 31, 2015 at 1:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .