Configuration Compare

Compare SSL/TLS configurations between two domains

Domain A

Domain B

Port

Results

About

The SSL Configuration Comparison Tool lets you compare TLS configurations between two servers or the same server at different points in time. It analyzes cipher suites, protocol versions, certificate chains, and security headers side-by-side, highlighting differences in supported algorithms, encryption strengths, and security features. This is invaluable when migrating servers, validating configuration changes, or ensuring consistency across your infrastructure.

The tool generates a detailed diff showing exactly which ciphers were added, removed, or changed, along with the security implications of each difference. It also compares HSTS settings, OCSP stapling status, and other TLS-related headers that affect the overall security posture of your web servers.

How to Use

1Enter the first domain name and port (the baseline configuration to compare against)
2Enter the second domain name and port (the configuration to compare)
3Click "Compare Configurations" to analyze both servers
4Review the side-by-side comparison showing differences in ciphers, protocols, and security settings

Use Cases

•Server Migration Validation: Compare old and new server TLS configurations to ensure no security features are lost during migration
•Configuration Drift Detection: Identify unexpected differences between servers in a load-balanced cluster that should have identical TLS settings
•Security Audit Evidence: Generate comparison reports showing TLS configuration improvements after hardening efforts
•CDN vs Origin Comparison: Verify that your CDN is forwarding TLS connections with the same security level as your origin server
•Compliance Baseline: Compare your configuration against a known-secure reference configuration to identify gaps

What Is Compared

Two configurations doing the same job should produce the same observable behaviour. This page compares two hosts and reports where they diverge.

1Gather identical facts from each host — negotiated version, cipher, key length and certificate identity — so the comparison is genuinely like for like rather than comparing different measurements.
2List each differing field with both values, because the field list is the real output. A field that matches needs no attention; one that differs is either expected during a migration or a bug that needs chasing.
3Summarise as a proportion of matching fields so two hosts can be tracked over a migration and watched converging. An error on one side is reported rather than treated as a difference, since nothing was measured there.

Differences can originate at a load balancer rather than in configuration, so repeat a comparison before acting on any single field. Where the two hosts share a proxy, that proxy is what both comparisons are really measuring.

Tips & Best Practices

•Use this tool after any TLS configuration change to verify only intended differences were applied
•Compare production servers against a hardened reference configuration regularly
•When comparing servers behind a load balancer, test each backend individually to detect configuration drift
•Save comparison results for audit trail documentation

Technical Details

●Cipher Analysis: Compares full cipher suite lists including key exchange algorithms, authentication methods, bulk encryption, and MAC algorithms

●Protocol Comparison: Identifies differences in supported TLS versions (1.0, 1.1, 1.2, 1.3) and SSL versions

●Security Headers: Compares HSTS, CSP, X-Frame-Options, and other security-related HTTP headers

●Certificate Comparison: Shows differences in certificate issuer, key type, key size, and SAN entries

Frequently Asked Questions

Critical differences include protocol version downgrades (e.g., one server supports TLS 1.0 while another requires TLS 1.2+), weak cipher suites present on one server but not the other, and missing security headers like HSTS. Moderate differences include cipher ordering and key exchange algorithm choices that affect performance but not security.

Yes, the tool connects to each server independently from our infrastructure. However, if firewall rules block our analysis server, the comparison may fail for that endpoint. Ensure ports 443 (or your custom port) are accessible from external IPs for accurate results.

The comparison report includes specific configuration snippets for Nginx, Apache, and HAProxy to align the configurations. For cipher suite differences, update your SSLCipherSuite directive. For protocol differences, modify your SSLProtocol directive. Always test configuration changes in staging before applying to production.

Because the configuration is not the only thing that determines behaviour. A load balancer, a CDN edge or a different container base image may all terminate TLS with different settings, and the connection is answered by whichever component is closest to the client. Comparing hosts reveals which component is varying; it does not tell you which, which is why the second check should be against the origin directly.

Context decides. During a migration, a different certificate issuer is expected and unremarkable. The same difference after the migration completed means a host was missed. Cipher differences between nearby hosts are often benign if both suites are modern. The comparison gives you the facts; whether a difference matters is a judgement about what you were doing when you ran it.

No. It is a convenient summary, and it compresses several independent measurements into one value that can hide which field actually differs. Two configurations with the same score can differ in ways that matter very differently. Read the field list and treat the score as a signal that something changed, not as a target.

Run it before and after. The before establishes what the fleet looked like and the after shows whether the change reached every host. A single host still showing the old certificate or cipher is the finding, and it is the failure mode that survives casual checking because every host is individually healthy.

That host contributed no measurements, which is reported as an error rather than counted as a difference. Treating an unreachable host as a mismatch would inflate the difference count with something that is a connectivity problem. Fix the reachability first — the handshake debugger identifies which stage failed — and re-run.