SSL Certificate
Issuer, expiry, SAN list for any HTTPS hostname.
Certificate for easyhost.be
- Subject CN
- *.easyhost.be
- Issuer
- Sectigo Limited
- Valid from
- 2025-11-03 00:00 UTC
- Valid until
- 2026-12-02 23:59 UTC
- Signature algorithm
- RSA-SHA256
- Serial
- 1E391E61AA74A2C226DB6E6DAF43EFED
About SSL Certificate
This tool connects to your hostname on port 443, performs a full TLS handshake, and reads the X.509 certificate the server presents. It shows the common name, the issuing certificate authority, the validity window with days remaining, the serial number, the signature algorithm, and the full Subject Alternative Name list. The connection uses the supplied hostname for SNI so wildcard and multi-domain certs return the right cert.
When to use it
Use this after deploying a new TLS certificate to verify it loaded correctly and serves the right hostname. Run it weekly on critical sites to spot certs about to expire before your monitoring fires. Check before adding a new subdomain to confirm the existing wildcard cert covers it via the SAN list. It also helps when debugging mismatched cert errors that browsers report cryptically.
How to read the results
The expiry badge turns red if the cert has passed its valid_to date and amber if fewer than 30 days remain. Issuer tells you which CA signed the cert, with Let's Encrypt being free and 90-day, commercial CAs offering longer terms. The SAN list shows every hostname the cert covers. The signature algorithm should be sha256WithRSAEncryption or stronger, never sha1.
Frequently asked questions
My cert is expiring soon. What should I do? ▾
For Let's Encrypt, certbot or your hosting control panel should renew automatically. If renewal failed, check that your /.well-known/acme-challenge/ path is reachable. For commercial CAs, renew through their dashboard and reinstall the new cert on your server.
What is the SAN list and why does it matter? ▾
Subject Alternative Names list every hostname the cert is valid for. A cert issued to example.com but lacking www.example.com in the SAN will fail when browsers visit the www version. Modern certs include both as a baseline.
Why does the check fail with a TLS connect error? ▾
Connect errors usually mean the server is not listening on port 443, the firewall blocks the connection, or the hostname does not resolve. Confirm DNS resolves correctly and try connecting with openssl s_client to see the handshake details.
Does the verifier check the full certificate chain? ▾
It reads the leaf cert that the server presents. To verify the full chain back to a trusted root, use openssl s_client -connect host:443 -showcerts. Browsers reject sites where the chain is incomplete or contains an untrusted intermediate.