Free SSL certificate checker
Enter a domain, or paste an https URL. See whether the certificate is trusted, whether the hostname matches, when it expires, and which certificates are in the chain.
Free, no signup. The rows come from one TLS handshake to the host you submit.
The check runs on the Uno Directory server. It opens a TLS connection and reads the certificate. It does not fetch the page, and the hostname is not added to the directory.
Type a domain such as example.com, or paste an https URL. The checker keeps the hostname and drops the path.
Leave the port off for 443. Use :8443 only when the certificate is served there. Any other port is rejected.
Click Check certificate. Valid means the chain is trusted, the hostname matches, and at least 30 days remain.
Valid. The chain is trusted, the hostname matches, and 30 or more days remain.
Problems. The chain is not trusted, the hostname does not match, the dates are outside the validity period, or fewer than 30 days remain.
Trust. Node checked the certificates against its built-in CA store. A missing intermediate is a common reason this row fails.
Chain. The first row is the server certificate. Each later row is the issuer Node followed, which can include a root the server did not send.
How to read an SSL check
A TLS server sends its own certificate first. Each certificate after that should be the one that signed the certificate before it. RFC 8446 section 4.4.2 says that for TLS 1.3, and RFC 5246 section 7.4.2 says it for TLS 1.2. The root is usually left out, because the client is supposed to have it already. Let's Encrypt's chain document describes the same layout: the end-entity certificate plus the intermediate, so a browser can follow the signatures to a root it trusts. If the intermediate is missing, a client that has not cached it cannot build that path, and this checker reports the chain as not trusted.
Trust on this page is Node's default CA store, not a separate list maintained by Uno Directory. Node's tls.rootCertificates are a snapshot of Mozilla's CA store taken when that Node version was built. The hostname is a separate check. tls.checkServerIdentity compares the name you entered with the subject alternative names. Those names are the subjectAltName extension in RFC 5280 section 4.2.1.6. Which of them a client should accept is specified in RFC 9525. A certificate can be signed by a trusted CA and still fail this row when it was issued for a different name.
The dates are notBefore and notAfter from RFC 5280 section 4.1.2.5. This page warns when fewer than 30 days remain, and it treats a certificate that is not yet valid, or that has expired, as a failed expiry check. For publicly trusted subscriber certificates, the maximum length of that window is set by the CA/Browser Forum Baseline Requirements, section 6.3.2, under ballot SC-081v3. Certificates issued before 15 March 2026 must not exceed 398 days. From 15 March 2026 until 15 March 2027 the maximum is 200 days. From 15 March 2027 until 15 March 2029 it is 100 days. From 15 March 2029 it is 47 days. A day in that section is 86,400 seconds. Let's Encrypt's integration guide says its own certificates are valid for 90 days and recommends renewing when a third of the lifetime is left.
The checker does not accept an IP address or localhost, and it will not connect when DNS returns a private, loopback, link-local, or other reserved address. It connects to one address from the lookup it already accepted, and it sends your hostname in the TLS server name so a shared address can present the right certificate.
Mail for the same domain is a different check. The email DNS checker reads MX, SPF, and DMARC. The DKIM record checker reads the public key for one selector.
Questions
Submit a tool to Uno Directory
Built a product founders should be able to find? List it on Uno Directory. A free listing needs a backlink badge. A paid listing goes live without one.
Submit a tool