HTTPS Configuration Audit

Paste the response headers of a site — and, if you have them, its certificate, a snippet of its page source and the host name — and this page reports how the HTTPS side is configured: whether HSTS is set and for how long, whether a content security policy upgrades insecure requests, whether cookies are marked Secure and SameSite, whether a server banner gives away a version, and what the proxy headers say about the request the application actually saw. The certificate is audited in the same report, plain http:// subresources are counted out of the page source, and the commands that can see the handshake are listed for you to run yourself. Everything runs in your browser and the page makes no request of its own.
1. Response headers
The whole response header block, status line included. Easiest source: curl -sI https://example.com/ in a terminal, or the Headers panel of the Network tab in browser developer tools, copied from the top of the file. Extra headers are read and ignored; only the HTTPS relevant ones are reported.
2. Certificate or chain (optional)
With this filled in the same report also carries the full certificate audit, so configuration and certificate are read together. PEM, a bare base64 or hexadecimal body and a PKCS#7 .p7b all work; the certificate checker goes into the certificate on its own in more depth.
3. Page source snippet (optional)
Paste the page source (or just the tags with URLs) and every plain http:// address is listed, because a subresource loaded over HTTP breaks the padlock and can be rewritten in transit even when the page itself arrived over HTTPS. Addresses to the site's own host are called out separately, since those are the ones a relative URL would fix.
4. Host name (optional)
With a host name here the audit checks the subject alternative names the way a browser does, including the wildcard rules, and matches the plain http:// addresses against it.
nothing audited yet
The sample is deliberately imperfect, so that every part of the report has something in it: a header block with HSTS and a content security policy (but no preload and one cookie without SameSite), a two certificate chain, and a page snippet that loads a script over plain http:// and points an image at the site's own host the same way. Expect an F on the sample and read the findings underneath to see what each one means.
What gets checked. From the header block: HSTS, its max-age, includeSubDomains and preload; a content security policy that upgrades insecure requests; the Secure, HttpOnly and SameSite flags on every Set-Cookie; a server banner that names a product and a version; and the forwarded headers that tell you whether the application saw the request as HTTPS. From the certificate block: the complete certificate audit, down to whether each link in the chain really signed the next. From the page source: the plain http:// subresources. The three are reported separately and then summarised together, because a broken padlock is usually one of those three and not the other two. For the full OWASP list of security response headers — X-Content-Type-Options, frame protection, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP and the graded score — paste the same header block into the Security Headers Check page; the two pages split the work along the TLS layer and the header layer.

What it cannot see. This page never opens a TLS connection. Browsers do not expose the handshake to a page, so the protocol version, the cipher suite, the key exchange group, OCSP stapling, session resumption, 0-RTT, the certificate chain a live server actually sends, and whether an HTTP to HTTPS redirect happens at the origin or at a proxy are all outside what any web page can report. It also cannot reach a third party site to collect the headers for you, and it cannot tell you whether a certificate is trusted, because that depends on a root store a page cannot read. The commands further down this page do see those things, and they are meant to be run by you, on your own machine.

Where to get the header block. In a terminal, curl -sI https://example.com/ prints exactly what this page wants. In a browser, open developer tools, go to the Network tab, reload the page, select the document request and copy the whole Response Headers area, or use Copy → Copy response headers. For the redirect check, run curl -sI http://example.com/ as well and paste both blocks, the page reports them one after the other.
Audit report
Nothing audited yet. Paste a header block above and press Audit this configuration for the full report; a certificate, a page source snippet and a host name are optional and each adds its own section.
Reachability probe — the only part of this page that uses the network
A page cannot open a TLS connection, but it can try an ordinary request. If the site allows cross origin reads, the URL the response ends up at shows whether http:// was redirected to https://, and that is all this can prove. If the request fails, this page cannot tell you whether the host is down, your own connection is down, or the site simply does not allow cross origin reads — the last is the common case, because most sites do not send Access-Control-Allow-Origin. An http:// URL is answered before any redirect, so this is the one thing here that a browser will attempt on a plain connection. Nothing leaves the browser until you press the button.
Commands that do see the handshake
curl -sI https://example.com/ # the header block this page reads curl -sI http://example.com/ # is plain HTTP answered, or redirected? curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.com/ openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName nmap --script ssl-enum-ciphers -p 443 example.com testssl.sh example.com # or: docker run --rm -ti drwetter/testssl.sh example.com
These are meant to be run by you, on a machine you control, against a host you are allowed to test. The -showcerts output can be pasted straight into the certificate checker, and the header output back into this page.
The certificate is a public document. Every publicly trusted certificate is published to Certificate Transparency logs, so any host name inside one — including an internal or mistyped name that a public certificate authority signed — can be found by searching those logs. A certificate also carries the revocation addresses its issuer chose, and those occasionally name an internal host. This is why the certificate a CDN serves says nothing about the origin server: the names in it belong to the CDN. If the audit turns up a host name you did not expect, treat it as public and replace whatever it protects.

Privacy: the header block, the certificate and the page source are read locally and never uploaded, and no request of any kind is made unless you press the button in the reachability probe. To create a certificate of your own use the self-signed certificate generator; to check that a private key belongs to a certificate use the certificate and key matcher.