Apache SSL Config Validator — Check Settings

About Apache Config Validation

The Apache Config Validator analyzes your Apache SSL/TLS VirtualHost configuration for security misconfigurations, weak protocol support, and missing best practices. It checks SSLEngine directives, certificate paths, cipher suites, protocol versions, and security headers to help you maintain a hardened TLS deployment on your Apache web server.

How to Use

Copy your Apache SSL VirtualHost configuration block from your server.
Paste the configuration into the text area above.
Click Validate to analyze your configuration for security issues.
Review the score and detailed issue list with line-level suggestions for fixes.

Use Cases

Security Auditing: Review Apache SSL configurations for compliance with security standards.
Server Hardening: Identify weak ciphers, outdated protocols, and missing security headers.
Migration Validation: Verify configurations after migrating from HTTP to HTTPS or updating certificates.
DevOps Automation: Integrate config validation into CI/CD pipelines for consistent TLS deployments.

Frequently Asked Questions

It checks the directives that actually decide whether an Apache TLS configuration is safe: SSLProtocol, which decides which protocol versions are offered and where SSLProtocol all silently enables the broken ones; SSLCipherSuite, split into components so a weak suite is named individually; SSLEngine, SSLCertificateFile, SSLCertificateKeyFile and SSLCACertificateFile for correct wiring; SSLCompression, which should be off; and the presence of a Strict-Transport-Security header. Every finding comes with the replacement text rather than just a warning.

A score of 80% or higher indicates a well-configured Apache SSL setup. Scores between 50-80% need improvement, while below 50% has critical issues requiring immediate attention. The validator provides specific fix suggestions for each issue.

No, this tool analyzes the configuration text you provide, not a live server. It is designed to catch issues before deployment. After fixing your config, use the SSL Certificate Checker to test the live server.

Because it enables every protocol the compiled binary knows about, including SSLv2 and SSLv3 on a typical build. Those are not merely old: SSLv3 has fallen to padding oracle attacks and SSLv2 to sufficiently severe ones that no client should negotiate either. The setting looks permissive rather than dangerous, which is exactly why it survives. Note that Apache 2.4.8 and later default to a safe set, so this only bites when someone has overridden it deliberately — usually years ago.

Remove the broad directives first, then add the explicit ones, so you are never left in a window with nothing enabled. Set SSLProtocol -all +TLSv1.2 +TLSv1.3, keep your cipher list with the weak components dropped, and set SSLCompression off. Reload rather than restart so existing connections drain, then check the negotiated protocol from a second machine — your own browser will keep using a session that is still alive and hide the change.

Because the two compressions are not the same thing. Content encoding such as gzip produces a stream that is safe to compress, but TLS record compression compresses everything before encryption, including the parts an attacker can influence, which is what the compression side-channel attacks exploited. It has been disabled by default in Apache for years for that reason. If you see it enabled, it is almost certainly inherited from a very old configuration rather than chosen deliberately.

On Apache 2.4.8 and later the full chain belongs in SSLCertificateFile, concatenated leaf first and then each intermediate in order. Older naming, with SSLCertificateChainFile pointing at the intermediates, is deprecated and will eventually be removed. Either way the root should not be included — clients already have it, and the most common incomplete-chain fault is a file containing only the leaf.

Generally no, and the risk is not theoretical: TLS 1.0 and 1.1 have known weaknesses and no major browser sends them by default any more. If an internal system genuinely cannot be upgraded, scope the older protocol to that host rather than enabling it globally — a separate virtual host with its own SSLProtocol setting contains the exposure and keeps the public host modern. Better still, put the internal client behind a TLS-terminating proxy that speaks 1.3 to the world and 1.0 only inwards.

What the Validator Checks

Apache's TLS configuration is spread across mod_ssl and httpd directives, and the mistakes that matter are few and well defined. Paste the relevant block and each is checked, with the replacement text given for every finding.

SSLProtocol

SSLProtocol all is the single most damaging line in an Apache TLS config, because it enables every protocol the binary supports — including SSLv2 and SSLv3 on most builds. It reads as permissive rather than broken, which is why it survives in production for years. The fix is explicit: SSLProtocol -all +TLSv1.2 +TLSv1.3.

Cipher selection

Weak components are identified individually so you can drop only what is actually weak, rather than replacing a working list with one you have not tested.

Certificate wiring

SSLEngine on without an SSLCertificateFile or without an SSLCertificateKeyFile will not start on Apache 2.4.8 or later. Both cases are caught, because the error message when you get it wrong is famously unhelpful.

Compression

SSLCompression on is reported as an issue. Compressing inside TLS has repeatedly turned into a practical attack surface for well-known attacks against compression side channels.

Technical Details

Config: Apache SSL/TLS directive validation and analysis
Directives: SSLProtocol, SSLCipherSuite, SSLCertificateFile, SSLSessionCache
Syntax: Configuration syntax and best practices checking
Output: Configuration issues with specific fix recommendations

Apache Config Validator

Issues Found