Will/does the letsencrypt client create a cert chain usable with OCSP stapling?


Title says it all, I’m testing with

ssl_certificate /etc/letsencrypt/live/le.revthefox.co.uk/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/le.revthefox.co.uk/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/le.revthefox.co.uk/fullchain.pem;

But I’m not sure if the cert paths are right, specifically the one for OCSP stapling (ssl_trusted_certificate).


https://certificate.revocationcheck.com/helloworld.letsencrypt.org shows helloworld.letsencrypt.org is correctly stapling.

That machine is running nginx >= 1.8, and has this configuration:

    # Site-Specific HTTPS configuration
    ssl_certificate      /etc/letsencrypt/live/helloworld.letsencrypt.org/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/live/helloworld.letsencrypt.org/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/helloworld.letsencrypt.org/fullchain.pem;
    ssl_stapling on;
    ssl_stapling_verify on;

Hope that helps!

OCSP: URI: http://ocsp.comodoca.com - why not https?
Nginx Configuration Sample

That clears it up, thanks.


It seems using fullchain for “ssl_trusted_certificate” doesn’t work. That field should be the “Root CA and Intermediate certs”, and should not include the site certificate.

Nginx continues complaining the following message when I use the fullchain there:

“ssl_stapling” ignored, issuer certificate not found


[quote=“upsuper, post:4, topic:2072”]
Nginx continues complaining the following message when I use the fullchain there:
[/quote]where you seeing that error ?


In /var/log/nginx/error.log


Actually, probably the issue is not that it includes the site certificate, but because of the lack of root CA certificate.


yeah i was worried the fullchain.pem wasn’t ideal for ssl_trusted_certificate as usually i have intermediates in there and root is optional

but i also used fullchain.pem for ssl_trusted_certificate with letsencrypt at Letsencrypt Webroot Authentication Tested on Beta invited/whitelisted domain and have no such errors in my logs

using Nginx 1.9.6


Hmm, well, it seems my nginx is quite old. I’m using Ubuntu 14.04LTS, and the nginx is 1.4.6. I guess that probably explains why it doesn’t work. I probably should try to upgrade my server…


if you have other nginx ssl vhost sites on server, check their ssl configs i.e. you may have enabled ssl stapling on a self signed ssl vhost other than letsencrypt vhost

check all your nginx vhost files to make sure

grep -Ro ssl_stapling /path/to/nginx/conf/* | uniq

i.e. for me on centminmod.com LEMP nginx

grep -Ro ssl_stapling /usr/local/nginx/conf/* | uniq


oh forgot to ask you are using beta invite whitelisted domain https://community.letsencrypt.org/t/beta-program-announcements/1631/6 ?

if not in beta invite, then the letsencrypt ssl certificate is untrusted like self-signed so ssl stapling options should be disabled as such and only enabled if you have trusted ssl certificate obtained via beta invite whitelisted domains


Same issue here, but without any errors in the log. Also Nginx 1.4.6 on Ubuntu 14.04 LTS. I think it should work on Nginx >= 1.3.7.


Hi this ( https://www.ssllabs.com/ssltest/analyze.html?d=suche.org ) is the prove that LE works with OCSP-Stapling
So maybe the Topic should be change to OCSP-Stpling + NGINX ?


best way to check is via command line

 openssl s_client -connect domain.com:443 -tls1 -tlsextdebug -status

look for

OCSP response: 
OCSP Response Data:
OCSP Response Status: successful (0x0)?


It seems using fullchain for “ssl_trusted_certificate” doesn’t work.

Yes, ssl_trusted_certificate should point at chain.pem, i.e. just the intermediate. I’m fairly confident the file it points to does not need to include the root. I used OCSP stapling in this configuration on my own server.


i use fullchain.pem for nginx and ocsp works - sometimes ssllab doesn’t report it but openssl cli command, testssl and cipherscan all report OCSP working


but yes root in fullchain.pem is generally not needed for ssl_trusted_certificate


Both chain.pem and fullchain.pem will work as the ssl_trusted_certificate for the purpose of OCSP verification, but chain.pem (aka one of the “Let’s Encrypt Authority X1” certificates) is more specific and, thus, better. The root is not needed in the case of Let’s Encrypt because the OCSP response is signed by the intermediate certificate itself.



The Nginx documentation says the following:

For the OCSP stapling to work, the certificate of the server certificate issuer should be known. If the ssl_certificate file does not contain intermediate certificates, the certificate of the server certificate issuer should be present in the ssl_trusted_certificate file.

So we don’t need to specify ssl_trusted_certificate, because Let’s Encrypt creates fullchain.pem containing all certificates and we use that for ssl_certificate already.


I’m wondering specifying ssl_trusted_certificate actually makes a difference. I only specified the following using Nginx 1.9.9:

  • ssl_certificate with fullchain.pem
  • ssl_certificate_key with privkey.pem
  • ssl_stapling on
  • ssl_stapling_verify on

Still, the command openssl s_client -connect <domain.com>:443 -tls1 -tlsextdebug -status gives me a successful OCSP response for my domain. Adding ssl_trusted_certificate does not seem to change the output of openssl. Is it somehow more efficient to specify ssl_trusted_certificate or is it unnecessary?


I use nginx 1.4.6 as it’s the Ubuntu 14.04LTS version. I’ve found errors in the logs due to inability to get the OCSP response quickly enough. Errors looked like this:

OCSP_basic_verify() failed (SSL: error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found) while requesting certificate status, responder: ocsp.int-x1.letsencrypt.org

My solution is to get the stapled file “offline” via a shell script cron job.



openssl ocsp -no_nonce \
             -respout      $DIR/ocsp.resp.new \
             -issuer       $DIR/chain.pem \
             -verify_other $DIR/chain.pem \
             -cert         $DIR/cert.pem \
             -url http://$HOST/ \
             -header "HOST" "$HOST" > $DIR/ocsp-reply.txt 2>&1

if grep -q ": good" $DIR/ocsp-reply.txt; then
    if cmp -s $DIR/ocsp.resp.new $DIR/ocsp.resp; then
        rm $DIR/ocsp.resp.new
        mv $DIR/ocsp.resp.new $DIR/ocsp.resp
        service nginx reload > /dev/null
    cat $DIR/ocsp-reply.txt | mailx -s "OCSP error for $SITE" $MTO

mv $DIR/ocsp-reply.txt $DIR/ocsp-reply-old.txt

Then, in the appropriate nginx site configuration file:

    ssl_stapling on;
    ssl_stapling_file /etc/letsencrypt/live/example.com/ocsp.resp;

and in the root crontab:

6 * * * * /etc/letsencrypt/get-ocsp.sh example.com

which refreshes it at 6 minutes past each hour.

Manual OCSP Stapling
OCSP responses inconsistent between different OCSP Servers