Documentation

Know your TLS setup still meets current guidelines

A valid certificate is half of HTTPS. The other half is how the server uses it: which TLS versions it accepts, which ciphers and key exchanges it offers, whether it still answers to protocols that were retired years ago. None of that shows in a browser's padlock, and all of it changes quietly — a new load balancer with its own defaults, a server image rebuilt from an older template, a library update that turns something back on.

Guidelines move as well. A configuration that met last year's edition of a guideline can fall short of this year's without anything changing on the server. Pingsured tests the configuration every day and tells you when it no longer meets the guideline you hold it to.

What the daily test looks at

Once a day, from each location a TLS check runs from, Pingsured probes the server's configuration: the TLS versions it accepts, the cipher suites and key exchange groups it agrees to, the certificate's key and signature, and whether it refuses a downgraded handshake. On port 443 it also reads the headers that protect HTTPS: Strict-Transport-Security, the redirect from port 80 and the Secure attribute of cookies.

Everything it finds is listed in the check's result, and the TLS findings page explains each finding and how to fix it on common servers.

The guideline you hold it to

You choose which published guideline a server is judged against. Mozilla's intermediate profile, the one most configuration generators produce, is the default. You can add:

• BSI TR-02102-2 and TR-02103, the German federal guidelines, which the German public sector commonly requires of its suppliers;
• NIST SP 800-52, the US federal guideline;
• NCSC-NL, the Dutch government's guidelines, widely followed in Dutch health care and finance.

Each guideline is pinned to one exact edition, and every result records the edition that judged it, so a result from today can still be read against the rules it was made under.

What you hear about

A finding against a guideline you selected sets the check's status: a warning by default, or an error, or only a note in the result if you prefer. That status reaches you like any other — by email, in the app or by webhook — through the subscriptions that include it. Findings outside your selected guidelines are still recorded but never alert.

When the certificate changes and the server's grade drops with it, the certificate-change notice says so.

The lock grade

Each result grades the configuration from one to five locks, so the state of a server reads at a glance:

The grade describes the configuration, not the certificate's remaining days, and below five locks the result names the findings that hold it back. Each location grades what it saw, and the check shows the lowest.

Why test your TLS configuration with Pingsured

• Every day, not once a year. A configuration that slips is found the day after, not at the next penetration test.
• Against the guideline you are asked about. The same check answers "is this secure enough for our customers" and "does this meet the BSI guideline our contract names".
• Explained, not just scored. Each finding is documented: which guideline counts it, under which clause, and how to fix it.
• From several locations. Servers behind a CDN or a load balancer can differ by region; each location reports its own grade.
• Hosted in the EU, by a German company. The details of your servers stay in Germany and Finland.

Limits worth knowing

• The configuration test runs at most once a day per server and location, so a change shows the day after it is made; certificate expiry and trust are still checked on every run.
• Some requirements cannot be seen from outside: client-initiated renegotiation, early data, the signature schemes of an encrypted TLS 1.3 handshake, and anything inside the server. They are not judged, and a server is not marked down for them.
• The check judges a server against a guideline. It is not a certification and does not replace an audit.