Configuration Snapshot

Capture a snapshot of current SSL/TLS configuration

Domain

Port

Results

About

The SSL Configuration Snapshot tool captures a complete point-in-time snapshot of your server's TLS configuration, including supported protocols, cipher suites, certificate details, and security headers. This snapshot serves as a baseline for detecting configuration drift, validating changes, and maintaining audit records.

Configuration snapshots are invaluable for disaster recovery (restoring a known-good configuration), change management (comparing before/after states), and compliance (proving configuration consistency over time). Each snapshot includes a timestamp, full configuration details, and can be compared against later snapshots to identify exactly what changed.

How to Use

1Enter the domain name you want to snapshot
2Click "Take Snapshot" to capture the current TLS configuration
3View the complete configuration summary including protocols, ciphers, and certificate details
4Save the snapshot for future comparison or download it as a report

Use Cases

•Disaster Recovery: Store known-good TLS configurations that can be restored quickly after a misconfiguration or server rebuild
•Change Management: Capture before/after snapshots when making TLS changes to document exactly what was modified
•Drift Detection: Compare current configuration against the baseline snapshot to identify unexpected changes over time
•Audit Documentation: Maintain historical configuration records for compliance audits and security reviews
•Multi-Server Consistency: Snapshot all servers in a cluster to verify they share identical TLS configurations

What A Snapshot Captures

Most TLS configuration is externally observable, and a dated record of it is what lets you prove what was live at a past moment. This page takes that record.

1Capture the connection facts from a live handshake — protocol version and cipher — since those are the first things a serving-path change shows up in.
2Break the HSTS header into its parts, reporting max-age, includeSubDomains and preload separately. Split out like this, two snapshots can be compared meaningfully and you can see exactly which of the three changed.
3Record the other security headers and stamp the result with its time, so a series of snapshots documents drift over months rather than only the present.

This records what an outside client sees, not your configuration file. Certificate paths, cipher lists and OCSP settings are invisible from here and belong in version control alongside these snapshots.

Tips & Best Practices

•Take snapshots after every TLS configuration change as part of your change management process
•Store snapshots in a version-controlled repository for complete audit history
•Compare snapshots before and after deployments to verify only intended changes were applied
•Use snapshot comparison as a pre-deployment validation step in your CI/CD pipeline

Technical Details

●Captured Data: Protocols, cipher suites, certificate chain, key parameters, security headers, OCSP status

●Storage: Snapshots stored with timestamps and metadata for historical comparison

●Comparison: Side-by-side diff showing additions, removals, and modifications

●Export: JSON, YAML, and PDF export formats for integration and documentation

Frequently Asked Questions

Snapshots capture a complete configuration state at a specific moment, while continuous monitoring tracks specific metrics over time. Snapshots are better for change management and disaster recovery, while monitoring is better for real-time alerting. Use both approaches for comprehensive TLS management.

Snapshots provide the configuration data needed to restore TLS settings, but you must manually apply the configuration to your server. The snapshot includes the exact cipher suite order, protocol versions, and certificate references needed to recreate the configuration on Nginx, Apache, or HAProxy.

Snapshots are retained for 12 months by default, with older snapshots archived. Critical snapshots (taken during incident response or before major changes) can be marked as permanent. The retention policy is configurable in your account settings.

Not of the file — it is a record of observable behaviour. That covers the negotiated protocol and cipher, the HSTS policy and the security headers, which is what proves a change took effect and when. It cannot capture certificate paths, cipher lists or OCSP settings, none of which a client can see. Keep the files in version control as well; the two together cover what neither can.

Drift is gradual and almost invisible from any single check. A header dropped during unrelated work, a cipher preference altered by an update, a node left behind after a rollout — each is small, and a series of dated snapshots is what makes the accumulation visible. Comparing the current state against one from six months ago frequently shows more change than expected, which is the point.

Three things in order of value: whether a change you made actually took effect, whether both values are what you intended where a change was expected, and whether anything changed that you did not make. The third is the one that finds real problems — a certificate renewed on one node, a header removed by a deployment, a proxy introduced without anyone noticing.

Before and after any change, always; that pairing is what proves the change landed. On a schedule, monthly suits an environment that changes often and quarterly suits one that does not. The value comes from the series rather than any single snapshot, so store them together and keep them — a snapshot with no predecessor answers nothing on its own.

Because a raw header string differs cosmetically between equivalent configurations, which makes comparison useless, while the three facts it encodes can each change independently. Split out, a comparison immediately shows that the max-age dropped or a preload directive was added — and those are exactly the changes that need explaining.