HTTPS Lookup
Fetch over HTTPS and inspect the TLS certificate.
Enter a value above to run HTTPS Lookup
e.g. example.com
Quick answer
HTTPS Lookup fetches a URL over HTTPS and inspects its TLS/SSL certificate, showing the issuer, validity dates, and covered domains alongside the response status. Use it to confirm a certificate is valid, matches the hostname, and hasn't expired.
HTTPS Lookup makes an HTTPS request to a hostname and shows you the TLS certificate the server presented during the handshake. You get the subject and issuer, the validity window, the Subject Alternative Names (SAN), and the certificate chain, along with the HTTP response status and headers. It is the quickest way to confirm that a site is serving the right certificate, that it has not expired, and that the hostname you typed is actually covered.
Certificate mistakes cause hard browser errors and blocked traffic, so a fast check before and after any deploy saves real downtime.
How it works
The tool opens a TLS connection to the host on port 443 and completes the handshake, exactly as a browser would. During that handshake the server sends its leaf certificate plus any intermediate certificates. We parse the leaf: its Common Name, SAN list, issuing CA, serial number, and the notBefore / notAfter dates. It then completes the HTTP request and reports the status code and response headers so you see both the transport and the application layer in one result.
How to read the results
Check the SAN list first: the hostname you queried must appear there, or browsers reject the certificate even if the Common Name looks right. Confirm notAfter is comfortably in the future and notBefore is in the past. Verify the issuer is a CA you expect, such as Let's Encrypt or DigiCert. If an intermediate is missing from the chain, some clients fail to build trust even when desktop Chrome succeeds, so treat a short chain as a warning.
Common problems & fixes
A name mismatch means the certificate does not list the hostname; reissue it with the correct SAN. An expired certificate returns notAfter in the past; renew and reload the web server. Serving only the leaf without intermediates causes intermittent 'unable to verify' errors on mobile and older clients; install the full chain your CA provides. If you see the wrong certificate entirely, a CDN or load balancer is likely terminating TLS with stale config that needs to be updated.
Frequently asked questions
- Why does the certificate work in my browser but fail here or on other clients?
- Desktop browsers cache intermediate certificates from earlier visits, so they can build a valid chain even when your server omits the intermediate. Fresh clients, mobile apps, and command-line tools cannot. If the lookup shows a short chain, add the intermediate bundle to your server configuration so every client can verify trust independently.
- What is the difference between the Common Name and the SAN list?
- The Common Name is a legacy single-hostname field. Modern browsers ignore it and validate strictly against the Subject Alternative Names. A certificate must list every hostname it serves in the SAN, including the www and bare-domain variants if you use both. If your hostname is missing from the SAN, expect a certificate error regardless of the Common Name.
- How far ahead of expiry should I renew a certificate?
- Renew well before notAfter, ideally with at least two weeks of margin. Automated tools like Certbot renew at roughly one-third of the lifetime remaining. Short-lived certificates, such as the 90-day ones from Let's Encrypt, make automation essential; a missed renewal takes the whole site down for every visitor at once.