SSL Certificate Checker

Connects to the server exactly as a browser or mail client would, captures the certificate chain and verifies it against the Mozilla trust store. Add a port to check mail and control-panel services, for example mail.example.com:993 or server.example.com:2087.

Common problems this finds

“Not trusted” with a valid expiry date usually means a missing intermediate certificate — browsers may cope, but APIs, curl and mail clients fail. A hostname mismatch means the certificate was issued for a different name; on cPanel run AutoSSL for the domain or the service subdomain.

Public certificate lifetimes are shrinking (200 days from March 2026, heading to 47 days by 2029), so automate renewal and monitor expiry with a script such as our SSL expiry check.

SSL certificate checker at a glance

How to use this tool

1. Enter a hostname such as example.com or www.example.com. A full URL works too; the scheme and path are ignored.
2. For a service other than HTTPS, add the port: :465 (SMTPS), :993 (IMAPS), :995 (POP3S), :2083 (cPanel), :2087 (WHM), :2096 (Webmail) or :8443 (Plesk and alternative HTTPS). Other ports are refused.
3. Press Check certificate. The checker connects twice: once to collect the certificate chain exactly as the server sends it, and once with full verification to get the trust verdict.
4. Read the summary, then the chain and the list of names the certificate covers.

Only implicit-TLS ports are supported. Ports that start in plain text and upgrade with STARTTLS (25, 587, 110, 143) need a different handshake; for mail submission on 587 use the SMTP test. The checker connects to the first address the hostname resolves to (A record first, then AAAA) and sends the hostname as SNI, as browsers do. Results are cached for 5 minutes.

How to read the results

Row	What it means
Trusted by browsers	Yes when the chain leads to a root in the Mozilla trust store and the hostname matches. No is followed by the reason from OpenSSL when one is available.
Expires	Expiry date and time in UTC with the days left. Amber under 14 days, red once expired.
Hostname match	Whether the name you entered is in the certificate’s Subject Alternative Names. A wildcard such as *.example.com covers exactly one level: www.example.com but not example.com or a.b.example.com.
Issuer	The organisation of the CA that signed the certificate, for example Let’s Encrypt, Sectigo or Google Trust Services.
Protocol / cipher	The TLS version and cipher suite negotiated with our client, which offers modern versions. TLSv1.3 is the best result.
Key	Key type and size plus the signature algorithm, for example RSA 2048-bit · RSA-SHA256 or ECDSA 256-bit · ecdsa-with-SHA256.
Handshake	Time to complete the TLS handshake from our server and the IP address tested.

The Certificate chain table lists every certificate the server sent, in order. Server is your certificate, Intermediate rows are the CA certificates that link it to a root, and Top of chain is simply the last certificate sent. It is normally an intermediate or a cross-signed certificate; the root itself lives in the browser and does not need to be sent. If the table has only a Server row and the certificate was not issued directly by a root, the intermediate is missing.

Names covered (SAN) lists up to 100 names the certificate is valid for. Browsers ignore the old Common Name field, so a name must be in this list to count.

Common problems and how to fix them

“Trusted by browsers: No” with a valid date and matching name

Almost always a missing intermediate certificate. The error in curl and many applications is unable to get local issuer certificate. Install the full chain: in cPanel paste the CA bundle into the Certificate Authority Bundle field, in nginx point ssl_certificate at the full-chain file (for Let’s Encrypt, fullchain.pem), and in Apache 2.4.8 or later put the intermediates in the file named by SSLCertificateFile. See exactly what the server sends:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

ERR_CERT_COMMON_NAME_INVALID or SSL_ERROR_BAD_CERT_DOMAIN

Chrome and Firefox wording for Hostname match: No. Either the certificate lacks that name (often www or the bare domain) or the server serves a different site’s certificate because the domain has no SSL virtual host of its own. Compare the SAN list with the name you need, then reissue or fix the vhost. The cPanel case is covered in ERR_CERT_COMMON_NAME_INVALID on cPanel.

NET::ERR_CERT_DATE_INVALID or an expired certificate

Renewal failed or the service still serves the old file. If the panel shows a new certificate but the checker does not, restart or reload the service that serves it (web server, Exim, Dovecot or cpsrvd). If renewal itself fails, the usual causes are a domain that no longer points to the server, a CDN or redirect blocking the validation file, or a CAA record that does not allow the CA; check those with AutoSSL failed: DCV, CAA and CDN problems and the CAA checker. Check a certificate file on the server:

openssl x509 -in /path/to/cert.pem -noout -subject -issuer -enddate

NET::ERR_CERT_AUTHORITY_INVALID on :2087, :2083 or :993

The service uses a self-signed certificate, typical of a new cPanel server before the hostname has a trusted certificate. Make sure the server hostname resolves to the server, then let AutoSSL issue for it; the services pick it up automatically. See cPanel hostname SSL.

“Could not complete a TLS handshake with example.com:443”

The port is closed, filtered, or not speaking TLS. Common causes: the port only accepts STARTTLS, the firewall blocks our server, the domain has no SSL virtual host so the server closes the connection, or the site is behind a WAF that drops data-centre clients. Check locally with the same openssl s_client command; if it fails there too, the problem is on the server.

The checker shows a Cloudflare or CDN certificate

When the domain is proxied, the checker sees the CDN’s edge certificate, which is the one visitors get. Your origin certificate is still important for Full (strict) mode. Test the origin directly by connecting to its IP with the right SNI:

openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null | openssl x509 -noout -subject -issuer -dates

Certificate lifetimes are getting shorter

Under CA/Browser Forum ballot SC-081, the maximum lifetime of a publicly trusted TLS certificate fell from 398 to 200 days on 15 March 2026. It drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029, and the period a CA may reuse a domain validation shrinks on the same dates, to 10 days in 2029. Manual renewal stops being practical, so automate issuance (AutoSSL, Let’s Encrypt or another ACME client) and watch expiry with the uptime, SSL and blacklist monitor. Background: the 47-day certificate lifetime.

Official documentation: Let’s Encrypt documentation, cPanel & WHM documentation, AlmaLinux wiki.

Related guides: CVE-2026-65638, 65639 and 67402 explained: patching the CSF Messenger and URLGET remote-code flaws · CrowdSec vs Imunify360 vs BitNinja: choosing a post-CSF security stack for shared hosting · KernelCare on cPanel and DirectAdmin servers: setup, verification and rollback.

Frequently asked questions