Backup and export your server's SSL/TLS security settings
Backing up configuration...
Configuration Summary
TLS Version
Cipher
HSTS
Server
Configuration JSON
About SSL Config Backup
Backs up and restores SSL/TLS configuration files from web servers. Supports Apache, Nginx, HAProxy, and other popular server configurations with version control.
How to Use
1Enter your server domain and port number
2Click "Backup Config" to capture current settings
3Download or copy the configuration JSON
Use Cases
•Disaster recovery and configuration restoration
•Configuration migration between servers
•Maintain audit trail of SSL configuration changes
Frequently Asked Questions
The backup captures the settings that decide your server's security posture: which protocol versions are offered, the cipher suites in order, HSTS configuration, the security headers in force, and the related TLS options. That is a description of the effective configuration rather than a file copy, which is deliberate: the same settings can be expressed across several files and an include chain, and a file copy would miss what is actually loaded. Regenerate a working configuration from the backup rather than trying to diff it against the original files.
Use the Config Template tool and feed the backed-up settings into it. That produces server-specific configuration text you can review before applying, which is the point: a restore should never be a blind paste of a file last edited months ago and never tested against the server it is going onto. Read the generated output, adjust anything the server has since changed, apply it, and then verify from outside the server with the SSL Checker rather than trusting that a reload succeeded.
They are provided as JSON exports, so the encryption question is really about where you keep the file rather than about the export itself. Treat it as sensitive either way, because a configuration dump describes your architecture in useful detail for an attacker: which protocols you support, which ciphers, how long your sessions last, which headers you set. Store it with restricted permissions, encrypt it at rest where your environment supports that, and do not commit it to a repository.
Not of the configuration itself — it is a snapshot of what an outside client observes. That covers the negotiated protocol and cipher, the HSTS policy parsed into its parts, and the security headers, which is genuinely useful for proving what was live on a date. It cannot capture anything in your configuration file: certificate paths, cipher lists, OCSP settings and directives are all invisible from outside. Keep those in version control as well, because this complements that rather than replacing it.
So two snapshots can be compared meaningfully. A raw header string differs in formatting for reasons that mean nothing, while max-age, includeSubDomains and preload are three distinct facts that can each change independently. Split out, you can see that the max-age dropped or that a preload directive was added, which is exactly the kind of change you need to notice and explain.
Before and after any change, always — that pairing is what proves the change took effect and shows exactly what it altered. On a schedule, monthly is reasonable for an environment that changes often and quarterly for one that does not. Keep the dated results, since the value is entirely in being able to say what was live at a past moment rather than only now.
Drift, mostly. Configuration changes accumulate gradually — a header removed during unrelated work, a cipher preference altered by an update — and a series of snapshots makes that visible where a single check would not. It also gives you the evidence an audit or an incident review asks for: what was the deployment actually serving, and when did it change.
It is the least effort and one of the more useful signals. The header names the software and often its version, which is genuinely useful reconnaissance for whoever is looking at your estate, and hardening guidance consistently recommends suppressing it. Capturing it here makes it easy to confirm the recommendation was followed, and comparing snapshots catches it being reintroduced by a deploy.
What Is Captured
The useful thing about TLS configuration is that most of it is observable from outside. This page captures the observable state of a deployment as a dated snapshot you can compare later.
1Record the connection facts — protocol version and cipher — from a real handshake, because those are what a change to the serving path would show up in first.
2Parse the HSTS header into its components: max-age, includeSubDomains and preload as separate fields rather than one opaque string. Split out like this you can compare them between snapshots and see exactly what changed, which a raw header would hide.
3Capture the other security headers — content type options, framing options, content security policy and the server header — and stamp the snapshot with its time. A series of these is how you prove what a configuration looked like on a given date.
What is captured is what an outside client can observe, not your configuration file. Certificate paths, cipher lists and directives this server never sees cannot be captured from here — for those, keep the files themselves in version control.
Tips & Best Practices
•Backup configurations before every security change
•Store backups securely and test restoration procedures
•Maintain multiple backup versions for rollback capability
•Include configuration backups in disaster recovery planning
Technical Details
Backup: Complete TLS configuration backup and storage Versioning: Version-controlled configuration backups Restore: Configuration restoration from backup Output: Backup confirmation with version details
