Configure Apache TLS

The fixssl.conf / vhost

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder     off
SSLSessionTickets       off
SSLUseStapling          off

sudo apachectl -t && sudo systemctl reload apache2

Directives on this page

SSLProtocol

Which TLS versions are offered. Must start with -all before adding versions: +TLSv1.2 alone, or all -SSLv3, both leave TLS 1.0 and 1.1 enabled.

• accepts[+|-]TLSv1.2 | [+|-]TLSv1.3 | all | -SSLv3
• defaultSSLProtocol all -SSLv3 (up to 2.4.16: all)
• valid inserver config, virtual host

httpd.apache.org 2.4 mod_ssl docs

SSLHonorCipherOrder

Whether the server's cipher preference wins over the client's. Already off by default, which is also the current recommendation.

• acceptson | off
• defaultSSLHonorCipherOrder off
• valid inserver config, virtual host

httpd.apache.org 2.4 mod_ssl docs

SSLSessionTickets

TLS session tickets. On by default; turning it off removes the ticket key as a forward-secrecy liability.

• acceptson | off
• defaultSSLSessionTickets on
• valid inserver config, virtual host

httpd.apache.org 2.4 mod_ssl docs

SSLUseStapling

Staples an OCSP response to the handshake. Off by default, and now a no-op for Let's Encrypt certificates since that CA stopped publishing an OCSP URL.

• acceptson | off
• defaultSSLUseStapling off
• valid inserver config, virtual host

httpd.apache.org 2.4 mod_ssl docs

If you see this

AH00526: Syntax error on line 13 of /etc/apache2/apache2.conf: Invalid command 'SSLProtocol', perhaps misspelled or defined by a module not included in the server configuration

mod_ssl is not loaded. Every SSL* directive vanishes with it, so a TLS block pasted into a server without mod_ssl fails on its first line rather than being quietly skipped. — apache/httpd server/config.c

AH00526: Syntax error on line 13 of /etc/apache2/apache2.conf: SSLProtocol: Illegal protocol 'TLSv1.9'

The token is matched against a fixed list — TLSv1, TLSv1.1, TLSv1.2, TLSv1.3. A version that does not exist is rejected outright, which is worth contrasting with SSLCipherSuite — that one accepts an unrecognised cipher string at config-test time without complaint. — apache/httpd modules/ssl/ssl_engine_config.c

Why it matters

TLS 1.0 and 1.1 are obsolete and rejected by every current browser. Leaving them enabled reaches nobody who couldn’t otherwise connect — the clients that need them can’t complete a modern handshake anyway — and it keeps you failing scans and offering downgrade surface.

SSLProtocol -all +TLSv1.2 +TLSv1.3 is the whole control.

Read the -all +TLSv1.2 syntax carefully

Apache’s SSLProtocol is additive and order-dependent, which is a genuine footgun:

SSLProtocol -all +TLSv1.2 +TLSv1.3     # correct: clear everything, add two back
SSLProtocol +TLSv1.2 +TLSv1.3          # WRONG: adds to the default, doesn't clear
SSLProtocol all -SSLv3                 # WRONG: everything except SSLv3, so TLS 1.0 is on

The second and third forms appear in a lot of copied configs and both leave TLS 1.0 enabled. Always start with -all, then add. And check the effective result from outside rather than reading the line — see the verify block.

Don’t hand-write SSLCipherSuite

Same argument as nginx and SSH: cipher lists age, and a list pasted from an old post encodes old opinions permanently.

Use the Mozilla SSL Configuration Generator, pick the intermediate profile, and regenerate it when you upgrade. A generated config you regenerate beats a curated one nobody revisits.

Two Apache-specific notes:

SSLCipherSuite does not control TLS 1.3. TLS 1.3 has its own suite set, configured with SSLCipherSuite TLSv1.3 ... in recent Apache — and OpenSSL’s defaults are short and all strong, so there is nothing worth tuning. A hand-written SSLCipherSuite line governs a shrinking share of your traffic.

SSLHonorCipherOrder off is deliberate. The old advice was on. Mozilla’s current intermediate guidance is off, because modern clients choose better than a fixed server ordering can — a phone with hardware AES and a laptop without want different suites, and only the client knows which it is.

OCSP stapling is mostly moot now

SSLUseStapling off

If you use Let’s Encrypt, stapling has nothing to do. Let’s Encrypt shut down its OCSP responder on 6 August 2025 and stopped including OCSP URLs in certificates, so SSLUseStapling on has no responder to query and quietly does nothing — leaving only a warning in your error log.

The full story is on the nginx OCSP page; it applies identically here. If your CA still runs a responder, stapling is still a small win; check with openssl x509 -noout -ocsp_uri.

Verify it worked

Check what the server assembled, not one file:

sudo apachectl -t -D DUMP_INCLUDES
sudo grep -rn 'SSLProtocol\|SSLCipherSuite\|SSLHonorCipherOrder' /etc/apache2/ /etc/httpd/ 2>/dev/null

Then test what it actually negotiates — this is what settles the -all question:

openssl s_client -connect your.site:443 -tls1 </dev/null 2>&1 | grep -E 'Protocol|handshake failure|alert'

Expect a handshake failure. Confirm 1.2 and 1.3 both work:

for v in tls1_2 tls1_3; do
  printf '%-8s %s\n' "$v" "$(openssl s_client -connect your.site:443 -$v </dev/null 2>&1 | grep -m1 'Protocol' || echo FAILED)"
done

Check the certificate has an OCSP URL before enabling stapling:

openssl s_client -connect your.site:443 </dev/null 2>/dev/null | openssl x509 -noout -ocsp_uri

Empty output means stapling can do nothing.

For the full external picture, run the site through the SSL Labs server test — it enumerates every protocol and suite from the outside, which is the view a scanner has.

Before you apply this

Dropping TLS 1.0/1.1 breaks genuinely old clients, and it looks like your site being down rather than a protocol negotiation problem.

Measure before you cut. Apache can log the protocol:

LogFormat "%h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %>s" ssl_combined
CustomLog ${APACHE_LOG_DIR}/ssl.log ssl_combined

Leave it a week, then count:

awk '{print $2}' /var/log/apache2/ssl.log | sort | uniq -c | sort -rn

Zero TLSv1 and TLSv1.1 — which is the normal answer on a public site — means this change is free. If they aren’t zero, you now know who to talk to instead of finding out from a support ticket. The usual suspects are payment terminals, embedded devices and an internal script on a server nobody upgraded.

SSLProtocol is per-vhost. Setting it in one vhost does nothing for the others, and a vhost without it inherits the server default — which may be everything. Check each one:

sudo apachectl -S 2>/dev/null | grep -c namevhost
sudo grep -rc 'SSLProtocol' /etc/apache2/sites-enabled/ 2>/dev/null

If those numbers don’t line up, some vhost is running on defaults.

apachectl -t then reload — never restart what you can reload.

Related

• Set security headers — including HSTS, which makes TLS mandatory.
• nginx OCSP stapling — the full story on why stapling is obsolete.