{"slug": "the-apache-ssl-line-that-looks-right-and-still-won-t-start", "title": "The Apache SSL line that looks right and still won't start", "summary": "A developer building a free Nginx and Apache SSL config generator found that Apache 2.4 rejects the common pattern of placing SSLStaplingCache inside a <VirtualHost> block, because mod_ssl allows SSLUseStapling there but restricts SSLStaplingCache to server-level config. The generator also had to replace Nginx's shared:SSL:10m cache syntax with Apache's shmcb path-and-byte-size form, add the missing SSLSessionCache directive, and point ErrorLog at /dev/stderr so startup failures inside Docker test containers were visible.", "body_md": "I built a free config generator for Nginx and Apache. Before shipping the SSL part, I ran every output against a real Nginx 1.27 and Apache 2.4 server. Using AI, I built a test sandbox instead of just reading the configs over.\n\nThat saved me more than once. The Apache version had two errors, both on the same line, and both looked completely fine on screen.\n\nThe goal was simple enough. Take a Let's Encrypt certificate and produce the Apache config for HTTPS with OCSP stapling turned on. Stapling lets your server send the certificate's \"still valid\" proof along with the handshake, so the visitor's browser doesn't have to go and ask the certificate authority itself.\n\nOn Apache, stapling needs two directives:\n\n`SSLUseStapling on` turns stapling on.`SSLStaplingCache` tells Apache where to keep the stapled responses.\nVersion 1 put everything inside the site's `<VirtualHost *:443>` block, the way a lot of snippets online do:\n\n```\n<VirtualHost *:443>\n    SSLEngine on\n    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem\n    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem\n    SSLUseStapling on\n    SSLStaplingCache \"shared:SSL:10m\"   # two errors on this one line\n</VirtualHost>\n```\n\nIt reads fine. But it isn't.\n\nApache didn't start. `apachectl configtest` stopped with a syntax error on the `SSLStaplingCache` line, saying the directive is \"not allowed here\".\n\nThe reason is scope. In Apache's mod_ssl, `SSLUseStapling` is allowed inside a `<VirtualHost>`, but `SSLStaplingCache` is server config only. It sets up one cache shared by the whole server, so it must sit in the main config: `httpd.conf`, or `ssl.conf` / `mods-available/ssl.conf` on Debian and Ubuntu. Put it inside any `<VirtualHost>` and Apache refuses the file.\n\nIt's an easy mistake to make, because the two directives belong together, so they naturally end up next to each other in the same block.\n\nAfter moving the line out of the `<VirtualHost>`, Apache still rejected it. This time it was the value.\n\n`shared:SSL:10m` is Nginx syntax, borrowed from Nginx's `ssl_session_cache` directive. Apache uses its own cache providers, and the common one is `shmcb` (shared memory, cyclic buffer), written as a path plus a size in bytes:\n\n```\nSSLStaplingCache \"shmcb:/tmp/ssl_stapling_cache(32768)\"\n```\n\nWhen you're building something like this, you often write the Nginx and Apache outputs side by side. I was using AI to speed things up, got a bit lazy, and the Nginx habit slipped into the Apache side. A developer who knows Nginx might read `shared:SSL:10m` and move on. Apache doesn't.\n\nOne more lesson came from the sandbox itself. For a while, Apache seemed to just exit with no error at all. My test container had `ErrorLog` pointing at a file, so when Apache died during startup, the error was written to a log file inside a container that had already stopped.\n\nPointing `ErrorLog` at `/dev/stderr` for testing fixed it immediately, and the real error messages showed up. If you test Apache in Docker, do that first. Save yourself the headache!\n\nWhile I was in there, the testing also showed that the Apache output was missing `SSLSessionCache`, which the Nginx side already had. It's the same kind of directive (server config only), and it uses `shmcb` too.\n\nThe fix was to split the output into two clearly labelled parts.\n\n**Once, in the main server config (outside any `<VirtualHost>`):**\n\n```\nSSLSessionCache  \"shmcb:/tmp/ssl_scache(512000)\"\nSSLStaplingCache \"shmcb:/tmp/ssl_stapling_cache(32768)\"\n```\n\n**Inside your `<VirtualHost *:443>` block:**\n\n```\nSSLEngine on\nSSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem\nSSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem\nSSLProtocol -all +TLSv1.2 +TLSv1.3\nSSLUseStapling on\n```\n\nTest before you reload, so a mistake never takes the site down:\n\n```\nsudo apachectl configtest && sudo systemctl reload apache2   # httpd on RHEL/Alma/Rocky/Fedora\n```\n\nThe `&&` means the reload only happens if the test passes.\n\n`SSLUseStapling`. Only the server knows which context each one is allowed in.\nIf you'd rather skip the trial and error, my [ProxyForge SSL generator](https://proxyforge.tech/ssl-generator) gives you the Certbot command plus the matching Nginx or Apache config, with the Apache output already split into the two parts above. It's free, needs no signup and runs in your browser. The [how-to guide](https://proxyforge.tech/docs#ssl-generator) explains where each piece goes.\n\nHave you hit other Apache directives that are only allowed in one context? I'd like to hear about them, since they're exactly the kind of thing worth checking, and maybe adding to my tool.", "url": "https://wpnews.pro/news/the-apache-ssl-line-that-looks-right-and-still-won-t-start", "canonical_source": "https://dev.to/ba796/the-apache-ssl-line-that-looks-right-and-still-wont-start-58dc", "published_at": "2026-10-08 12:45:00+00:00", "updated_at": "2026-10-08 12:50:00.289120+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools"], "entities": ["Apache", "Nginx", "Let's Encrypt", "mod_ssl", "Docker"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/the-apache-ssl-line-that-looks-right-and-still-won-t-start", "markdown": "https://wpnews.pro/news/the-apache-ssl-line-that-looks-right-and-still-won-t-start.md", "text": "https://wpnews.pro/news/the-apache-ssl-line-that-looks-right-and-still-won-t-start.txt", "jsonld": "https://wpnews.pro/news/the-apache-ssl-line-that-looks-right-and-still-won-t-start.jsonld"}}