How-to

How to Configure Strong TLS Settings on Apache

Apache's TLS hardening follows the same principles as Nginx's, with different specific directives, typically set in the SSL module configuration or a VirtualHost block.

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...
SSLHonorCipherOrder off

As with Nginx, use Mozilla's SSL Configuration Generator to produce a current, Apache-specific configuration block rather than assembling the cipher list manually — recommendations shift as cryptanalysis advances, and a generator reflects current guidance rather than a snapshot from whenever a given tutorial was written.

Restart, don't just reload

Some Apache SSL configuration changes require a full restart rather than a graceful reload to take effect fully, depending on your specific module and OS — check your platform's documentation, since a reload that appears to succeed can occasionally leave old settings partially active until a true restart.

What to do if applying a strict configuration breaks compatibility for some visitors

If a strict, modern-only configuration causes connection issues for a portion of your audience, checking your actual visitor analytics for browser and OS versions helps determine whether Mozilla's intermediate compatibility preset, rather than the strictest modern one, better fits your specific audience's real needs.

How to verify your configuration changes took effect after reloading Apache

Running an SSL scan tool or a direct OpenSSL cipher check against your domain after reloading confirms the new configuration is actually active, rather than assuming a successful reload command means the intended changes took effect exactly as written.

What Mozilla's SSL Configuration Generator specifically provides for Apache users

Mozilla's tool generates a ready-to-use Apache configuration block for your chosen compatibility level (modern, intermediate, or old), reflecting current best-practice cipher suites and protocol versions — a reliable starting point rather than manually assembling a cipher suite list from scratch.

How to verify your chosen cipher suite list doesn't inadvertently break older but still-relevant clients

Checking your actual visitor analytics for browser and OS version distribution before applying a strict, modern-only cipher suite list confirms you're not inadvertently cutting off a meaningful portion of your real audience — Mozilla's intermediate compatibility tier is a safer default absent specific evidence your audience skews entirely modern.

Why revisiting your configuration periodically matters as best practices continue to evolve

The recommended cipher suite and protocol configuration shifts over time as new research emerges and old options are deprecated, covered throughout our SSL History category — periodically regenerating your configuration against Mozilla's current tool, rather than treating a configuration written once as permanently correct, keeps your server aligned with current best practice.

What to do if a specific older client can't connect after hardening your configuration

If a specific, known-legitimate older client can no longer connect after hardening, checking exactly which protocol version or cipher suite that client requires against your new configuration identifies precisely what would need to be selectively re-enabled, rather than reverting your entire hardening effort.

How to apply hardened TLS settings consistently across multiple Apache virtual hosts

Defining your hardened TLS settings once in a separate, included configuration file, then referencing that file from every virtual host needing it, ensures consistency and means a future update to your standards only needs to happen in one place rather than being manually repeated across every individual virtual host.

A closing note on treating TLS hardening as ongoing maintenance, not a one-time task

Given how the recommended configuration shifts over time as covered throughout this site's SSL History category, treating TLS hardening as periodic, recurring maintenance rather than a one-time setup task keeps your server aligned with current best practice rather than gradually falling behind.

A final practical tip for future deployments

Saving your finalized, tested configuration as a template for future servers ensures every new Apache deployment starts from the same hardened baseline, rather than needing to regenerate and re-verify a strong configuration from scratch each time.