SSL Checker guide
What the XGM SSL Checker reads from a certificate and TLS connection, how to read the grade, chain, protocol and cipher findings, and how to fix them.
What a certificate proves
A TLS certificate binds a host name to a public key and is signed by a certificate authority (CA) that browsers trust. When a browser connects to https://example.com, the server presents its certificate, and the browser checks that it is valid today, issued for example.com, and chains up to a trusted root. Only then is the connection considered secure.
The certificate is only half of it. The TLS handshake also negotiates a protocol version and a cipher suite, which decide how well the connection is protected. The SSL Checker reports both parts so a valid certificate on an outdated configuration is not mistaken for a healthy setup.
How to use the SSL Checker
- Open the TLS Checker and enter a host name served over HTTPS, such as
example.comorwww.example.com. - XGM connects from its server to port 443 of that host and completes a TLS handshake.
- Read the grade and the summary: issuer, expiry, key, signature, OCSP stapling, HSTS preload status and the protocol table.
- Check the findings and fixes, then share the permalink or export the result. The Full report tab runs the scored SSL / TLS report with recommendations.
Check every host name you serve separately. example.com and www.example.com may be served by different certificates or even different platforms, and a CDN may present a different certificate from your origin server.
What the findings mean
| Finding | Severity | Action |
|---|---|---|
| Intermediate certificate missing | Critical | Serve the full chain (fullchain.pem), not only the leaf certificate. |
| Certificate is not trusted | Critical | Expired, wrong name or unknown CA: issue a new certificate. |
| Certificate expires in n days (under 14 / under 30) | Critical / Warning | Renewal should have happened; check the automation. |
| RSA key of n bits (under 2048) | Critical | Generate a 2048-bit RSA or an ECDSA P-256 key. |
| Certificate signed with SHA-1 or MD5 | Critical | Reissue with SHA-256; browsers reject these signatures. |
| TLSv1.0 and TLSv1.1 still enabled | Warning | Allow only TLS 1.2 and 1.3; caps the grade at B. |
| TLS 1.3 not supported | Warning | Upgrade OpenSSL (1.1.1+) and enable TLS 1.3; caps the grade at A-. |
| 3DES or RC4 accepted | Critical | Remove them from the cipher list; caps the grade at C. |
| RSA key exchange accepted / CBC with SHA-1 accepted | Warning / Info | Prefer ECDHE with AEAD ciphers (GCM, ChaCha20). |
| No OCSP stapling | Info | Enable stapling if your CA still runs OCSP. |
| No HSTS header / short max-age | Warning | Send HSTS with at least six months; needed for A+. |
Renewal windows
Common certificate problems
| Symptom in browsers | Cause | Fix |
|---|---|---|
| "Your connection is not private" with a date error | Expired certificate | Renew; fix the renewal job |
| Name mismatch error | Certificate does not list the host name in its SAN | Reissue including every host name, such as www |
| Unknown issuer on some devices only | Intermediate certificate missing from the server | Serve the full chain file |
| Warning only on old devices | Old root store or TLS version support | Usually acceptable; check the client platform |
| Works on www, fails on the bare domain | Different server block or certificate for each name | Cover both names and configure both hosts |
A missing intermediate is a classic problem because desktop browsers often fill in the gap from cache, while mobile apps, API clients and command-line tools fail. Configure the server with the full chain file your CA provides, not just the leaf certificate.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null | grep -E 's:|i:'Certificate types and issuers
Publicly trusted certificates differ in how the CA validated the requester, not in how strong the encryption is. Domain-validated (DV) certificates prove control of the domain, organisation-validated (OV) and extended-validation (EV) certificates add checks on the organisation. Browsers treat them the same way for the padlock, so DV certificates from automated CAs are the normal choice for most sites.
| Option | Covers | Notes |
|---|---|---|
| Single host name | example.com | Simplest; add www as a second name |
| Multi-name (SAN) | example.com, www.example.com, api.example.com | One certificate for a fixed set of names |
| Wildcard | *.example.com | Any single-label subdomain, not the bare domain and not deeper levels |
| ECDSA key | Any of the above | Smaller and faster than RSA; supported by current clients |
Wildcards are convenient but spread one private key across every service that uses them. A compromise of any of those servers exposes the key for all subdomains, so prefer separate certificates where services are run by different teams or platforms.
Renewal and monitoring
Certificate lifetimes for publicly trusted certificates are limited by CA/Browser Forum rules and are getting shorter, which makes manual renewal impractical. ACME clients renew automatically with CAs that support the protocol, and hosting platforms and CDNs do it for you. What automation does not do reliably is tell you when it stops working.
- Monitor expiry independently of the renewal system, with an alert at 21 days or more.
- Watch every host name, including mail servers, API hosts and admin panels.
- After changing DNS, CDN or hosting, confirm renewal still works: HTTP-based validation can break when traffic moves.
- Keep CAA records in line with the CAs you actually use, so renewals are not refused.
The TLS Checker turns the expiry into the dates that matter - the 90-day issue date, the 60-day order date, the 30-day renewal date and the expiry itself - and offers them as an .ics file you can import into any calendar, with one event per date and the host named in each. An intermediate that expires before the leaf, or a second certificate with its own expiry, gets its own event. The file is built in your browser from the result on screen: XGM does not keep the dates and does not send reminders, so the calendar you import is the only thing that will remind you.
The XGM API offers the same check as JSON at /api/v1/ssl/example.com, which is easy to call from a scheduled job. The TLS 1.3 guide covers protocol and cipher configuration, and the HSTS guide explains why expiry turns into a hard outage once HSTS is enabled.
FAQ
Is SSL the same as TLS?
SSL is the old name. All SSL versions are obsolete, and certificates today are used with TLS. The term SSL certificate stuck, but the protocol is TLS.
Which port does the checker use?
Port 443, the standard HTTPS port. Mail servers and other services on different ports are not covered by this check.
Why does the checker show a different certificate than my browser?
The host may be behind a CDN or load balancer that serves different certificates by location, or your browser may reach an IPv6 address while XGM uses IPv4. Check the address the name resolves to.
What is a Subject Alternative Name?
The certificate extension that lists every host name the certificate is valid for. Browsers use it instead of the older common name field.
Can I check a private or internal host?
No. XGM refuses private, loopback and internal addresses. Use openssl s_client from inside your network for internal services.
Does a valid certificate mean the site is safe?
It means the connection is encrypted to a server that controls the domain. It says nothing about whether the site itself is trustworthy.
How often should I check certificates?
Continuously through monitoring, with alerts well before expiry. Manual checks are useful after migrations and configuration changes.