Apache won't start after adding SSLStaplingCache

Updated 9 November 2026 · By Brent Alexis

Short answer: Apache won't start after adding SSLStaplingCache when the line is inside a <VirtualHost> (it's only allowed in the main server config), when it uses Nginx's shared:SSL:10m syntax, or when SSLUseStapling on has no cache at all. But if your certificate is from Let's Encrypt, the real fix is simpler: delete both lines. Let's Encrypt removed OCSP from its certificates in 2025, so stapling does nothing with them.

Reproduced in the lab with the official Apache (2.4.68) and Nginx (1.30.6) images, using certificates from a test certificate authority made to match Let's Encrypt's (no OCSP address), one that does have an OCSP server, and a real Let's Encrypt certificate checked on 9 November 2026: 29 checks. Let's Encrypt's OCSP timeline comes from its announcement. How it's tested

Match your error
"Syntax OK", but Apache won't start
Using Let's Encrypt? Remove stapling
The Nginx side
If your CA still supports OCSP
Check it

Match your error

Run sudo apachectl configtest (or sudo httpd -t on RHEL) and compare the message:

Error	Cause and fix
`SSLStaplingCache cannot occur within <VirtualHost> section`	The cache line is inside a virtual host. Move it to the main config, or delete it (see below).
`SSLStaplingCache: 'shared' stapling cache not supported`, followed by the cache types it knows	That's Nginx's `shared:SSL:10m` syntax. Apache uses `shmcb`, or delete the line.
`SSLSessionCache cannot occur within <VirtualHost> section`	The same rule applies to the session cache: main server config only.
Syntax OK, then `AH01958: SSLStapling: no stapling cache available`	`SSLUseStapling on` with no `SSLStaplingCache` anywhere. See the next section.

The main server config is /etc/apache2/mods-available/ssl.conf on Debian and Ubuntu, /etc/httpd/conf.d/ssl.conf on RHEL, or httpd.conf. A line there, outside every <VirtualHost>, applies to the whole server, once.

"Syntax OK", but Apache won't start

This one catches people who test first. In the lab, with SSLUseStapling on in the virtual host and no SSLStaplingCache anywhere, the config test said Syntax OK, but Apache refused to start. The reason was only in the error log:

AH01958: SSLStapling: no stapling cache available
AH02312: Fatal error initialising mod_ssl, exiting.
AH00016: Configuration Failed

So after any SSL change, check Apache actually came back: sudo systemctl status apache2 (or httpd), not just the config test.

Using Let's Encrypt? Remove stapling

OCSP stapling lets your server send proof that its certificate hasn't been revoked. It only works if the certificate names an OCSP server to ask. Let's Encrypt stopped putting that address in its certificates on 7 May 2025 and switched its OCSP servers off on 6 August 2025 (source: Let's Encrypt, checked 9 November 2026). Revocation is published in a list (CRL) instead, which browsers handle themselves.

In the lab, a real Let's Encrypt certificate (from Let's Encrypt's own test site, issued 4 November 2026) had no OCSP address at all, only a CRL address.

With a certificate like that, an Apache config with both stapling lines in the right places passed the test and started, but stapled nothing, and wrote two lines at the error level to the log every time it started:

AH02218: ssl_stapling_init_cert: no OCSP URI in certificate and no SSLStaplingForceURL set
AH02604: Unable to configure certificate example.com:443:0 for stapling

Fix: delete SSLUseStapling on from the virtual host and SSLStaplingCache from the main config. Keep SSLSessionCache; that's a different cache and still useful. Then test and restart:

sudo apachectl configtest && sudo systemctl restart apache2

With the stapling lines removed, the same server started cleanly, HTTPS worked, and the log said nothing about stapling. The SSL Generator no longer outputs stapling lines for this reason.

The Nginx side

Nginx doesn't refuse to start, it just ignores the setting. In the lab, with a certificate like Let's Encrypt's, nginx -t still passed but printed this every time, and nothing was stapled:

nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/letsencrypt/live/example.com/fullchain.pem"

Delete ssl_stapling on;, ssl_stapling_verify on; and the ssl_trusted_certificate line if it was only there for stapling, then run sudo nginx -t && sudo systemctl reload nginx. Without them, the test ran clean and HTTPS worked.

If your CA still supports OCSP

Some paid certificate authorities still run OCSP servers. Check your certificate:

openssl x509 -in /path/to/cert.pem -noout -ocsp_uri

No output means there's nothing to staple. If it prints a URL, stapling can work on Apache with the two lines in the right places:

# Main server config, outside any <VirtualHost>
SSLStaplingCache "shmcb:/tmp/ssl_stapling_cache(32768)"

# Inside <VirtualHost *:443>
SSLUseStapling on

In the lab, with a certificate that named a working OCSP server, those two lines gave a stapled OCSP Response Status: successful and Cert Status: good. On Nginx, stapling also needs a resolver line so it can look up the OCSP server's name: without one, the lab's Nginx logged no resolver defined to resolve ocsp while requesting certificate status and stapled nothing. The Nginx side with a working OCSP server isn't lab-tested here.

Check it

Ask your server for its stapled response from any machine with OpenSSL:

echo | openssl s_client -connect example.com:443 -servername example.com -status 2>/dev/null | grep -i "OCSP response"

With a Let's Encrypt certificate you'll see OCSP response: no response sent, with or without stapling turned on. That's expected now, not a fault.

Get the Certbot command and HTTPS config →

How to use ProxyForge · FAQ: common errors · Guides · What's new · About