File "chain.pem" shared among all NGINX server blocks for OCSP stapling?

Hey everyone!

So I am in the process of improving the configuration of about a hundred websites using server blocks listening to port 443 and using HTTP/2 and I some doubts related to OCSP stapling.

All my SSL options are in a separate file, included from each server block (but for ssl_certificate and ssl_certificate_key, of course). Since all my TLS certificates are issued by Let's Encrypt via an Ansible playbook (using community.crypto.acme_certificate), I was considering adding the following to these shared SSL options:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/isrg-root-ocsp-x1.pem;

That is, sharing the ~/letsencrypt/etc/live/ file, which is the same for all my certificates (since the root and intermediate certificates used to generate such file are the same).


  1. Is it "okay" to do so or is there some reason I am not taking into consideration that would lead me to moving the ssl_trusted_certificate directive out of the shared include and into each server block, where the linked file would be the chain.pem file generated for each certificate?

  2. Is the ISRG Root OCSP X1 (Signed by ISRG Root X1) certificate available at the OCSP Signing Certificate section of the Chain of Trust page of Let's Encrypt a valid value for this directive, or does it have to be the chain.pem file generated with each certificate?

I ask this because, ideally, I would take it from that web page and deploy it while setting up my NGINX server via an Ansible playbook rather than when deploying a website (where I would just be copying the fullchain.pem for the ssl_certificate directive and the privkey.pem for the ssl_certificate_key directive).

Anybody feedback would be much appreciated. Thanks in advance.

My domain is: N/A
I ran this command: N/A
It produced this output: N/A
My web server is (include version): NGINX 1.23.3
The operating system my web server runs on is: Debian 11 Bullseye
My hosting provider, if applicable, is: N/A
I can login to a root shell on my machine: Yes
I'm using a control panel to manage my site: No
The version of my client is: Ansible module community.crypto.acme_certificate

@jsabater , welcome to the community!

I am telling this from my experience, I already burned my finger:
The situation that the chain file to be the same (not counting the alternate chain) for all the certificates just momentary. When time comes to renew the intermediate certificate by Letsencrypt, there will be case that the older leaf certificates are signed with the older intermediate and the newer leaf certificates are signed with the more recent intermediate. The only safe way is to treat the chain uniqe for each leaf certificates. (You may still do some optimization via deduplication, but that requires analysis of the content of the chain.)


You are absolutely right. I will move that bit to the specific server block template. Thank you for the heads-up!

Incidentally, do you have any information about the linked OCSP certificate from Let's Encrypt webpage? Would that be a valid option for this matter, albeit subject to the same problem you just described?

The Chain of Trust - Let's Encrypt OCSP signing certificate is used exclusively signing the OCSP reply of the old intermediate certificate and not for any leaf certificate. Its existence is irrelevent for the matter of that topic.