A tool near your trust plane should explain itself.
You are considering pointing a third-party service at your certificate estate. Before you do, you deserve specifics - what we can see, what we cannot, what we store, and what happens when something goes wrong. This page is that explanation, in plain language. Where a claim is structural - enforced by how the system is built rather than by policy - we say so, because a design guarantee is stronger than a promise.
Read-only, by design
SSLScan observes certificates the way a browser does: it opens a TLS connection and records what the server presents. There is no code in the product that installs, renews, revokes, binds or modifies a certificate - not a disabled feature, not a hidden admin mode; the capability does not exist. The worst a compromised SSLScan account could do to your servers is read the same public handshake data anyone on the network can read.
This also means SSLScan needs no credentials to your systems. No SSH keys, no service accounts, no WMI, no API tokens for your infrastructure. Nothing to leak because nothing is held.
Private keys never reach us - structurally
Two separate design decisions make this a property of the system rather than a policy:
- Monitoring cannot see keys. A TLS handshake never transmits the server’s private key - that is the entire point of public-key cryptography. A monitor built on handshakes is incapable of collecting keys, ours included.
-
The toolkit runs in your browser. When you open a
.pfx,.pemor.p7bin the certificate toolkit, the file is parsed and converted locally, in your browser tab. It is not uploaded. Close the tab and it is gone. You can verify this yourself in your browser’s network inspector - no request carries the file.
What we store, and what we deliberately do not
| We store | We do not store |
|---|---|
| Certificates as presented on the wire (public data), and the hostnames, ports and IP addresses you monitor | Private keys, in any form, from any source |
| Check results and findings - validity, chain, key strength, protocol versions, and their history | Files you open in the certificate toolkit (they never leave your browser) |
| Your account e-mail and a scrypt hash of your password | Your password in any recoverable form |
| Subscription state (plan, renewal date) received from our payment provider | Card numbers or payment credentials - those live with Paddle, our merchant of record |
Everything is encrypted in transit (TLS - we would be a strange product otherwise) and at rest on our infrastructure. Tenants are isolated at the data layer: every query is scoped to your account.
Reporting a vulnerability
If you believe you have found a security issue in SSLScan, we want to hear about it - and we will not threaten researchers who report in good faith.
- Email security@sslscan.net with enough detail to reproduce the issue.
- We acknowledge within 2 business days, keep you informed as we investigate, and credit you (with your consent) when the fix ships.
- Please do not access other customers’ data, degrade the service, or publicly disclose before we have had a reasonable chance to fix - 90 days is our default coordination window.
We do not currently run a paid bounty programme; we do say thank you, in public, and mean it.