SSL Certificate Checker and Certificate Viewer

What the checker shows

For a domain, the checker connects to the server over TLS, just like a browser, and reads the certificate chain it presents. For each certificate you see:

• Subject and issuer – who the certificate was issued to and which certificate authority (CA) signed it.
• Validity – the start and expiry date, with the number of days remaining.
• Subject Alternative Names (SAN) – every domain name or IP address the certificate covers. Browsers only look at these names, not at the common name.
• Public key and signature – for example RSA 2048 or ECDSA P-256, signed with SHA-256.
• Fingerprints, serial number, key usage, OCSP and CRL addresses – useful for pinning, revocation checks and audits.

The summary also tells you whether the server sends the complete chain, whether it leads to a root in a standard trust store, whether the certificate matches the host name you entered, and which TLS version and cipher were negotiated.

Common certificate problems

• Expired certificate. Certificates have a fixed lifetime, often 90 days for automated certificates. An expired certificate causes a full-page browser warning.
• Host name mismatch. The name in the address bar must appear in the SAN list. A wildcard such as *.example.com covers www.example.com but not example.com or a.b.example.com.
• Missing intermediate certificate. The server must send the intermediate CA certificates. Some browsers fetch a missing intermediate themselves, others do not – which is why a site can work in one browser and fail in another. The checker follows the chain from the server certificate to a trusted root and shows exactly which intermediate is missing, with a link to download it from the CA.
• Self-signed or private CA. Fine for internal systems, but public visitors will see a warning.

PKIoverheid and UZI certificates

Dutch government and healthcare certificates carry an identity that ordinary viewers do not show. The checker decodes it:

• OIN – the 20-digit organisation identification number in the subject serial number of a PKIoverheid certificate. You can copy it or look it up in the OIN register.
• UZI-register identity – certificates and passes from the UZI-register (CIBG) hold a subject ID in the Subject Alternative Name: the UZI number, the card type (care provider pass, employee pass or server certificate), the subscriber number (URA), the role with the profession, and the AGB code. Most tools, OpenSSL included, show this only as “othername: unsupported”.
• OIN from the URA – for UZI certificates the OIN is derived from the subscriber number as 00000009 + URA + 0000, as the OIN Stelsel prescribes.
• Certificate policies – a PKIoverheid policy shows that the certificate was issued under the PKIoverheid Programme of Requirements.

Many of these certificates chain to a Staat der Nederlanden private root that browsers do not trust. For server-to-server connections such as Digikoppeling that is expected; the checker says so instead of only reporting an unknown root.

Mail servers and other ports

Besides HTTPS on port 443 you can check servers that use TLS directly: mail.example.com:993 for IMAPS, :995 for POP3S, :465 for SMTPS, :636 for LDAPS, :853 for DNS over TLS and :8443. Servers that only offer STARTTLS on ports 25, 587 or 143 are not supported.

Privacy and safety

Certificates are public information. Pasted certificates are decoded on our server and not stored. The checker refuses private keys: if you ever paste a private key into a website, treat it as compromised and replace it. Domain checks only connect to public internet addresses.

Sources

• RFC 5280 – Internet X.509 Public Key Infrastructure Certificate Profile
• RFC 6125 – Service identity and host name verification
• RFC 8446 – TLS 1.3
• CA/Browser Forum – Baseline Requirements
• Logius – PKIoverheid
• Logius – OIN Stelsel
• UZI-register (CIBG)