How to Check an SSL Certificate

How to Check an SSL Certificate: A Complete Inspection Guide

Checking an SSL certificate means verifying seven properties that together determine whether a TLS connection will succeed and remain secure. These properties cover the certificate's validity window, the domain names it authenticates, the strength of the key algorithm, the trustworthiness of the certificate chain, the presence of required extensions, the issuer's public trust status, and whether any security flags indicate a known weakness. A certificate that looks valid in isolation may fail when served to clients if the chain is incomplete, if the hostname does not match a SAN entry, or if an intermediate CA certificate has expired. Consequently, checking a certificate requires examining the full chain rather than the leaf alone¹. This guide walks through each check in order, using the CapyToolkit Certificate Inspector as the inspection tool throughout.

The seven properties to check in order

Every SSL certificate check should verify validity, coverage, key strength, chain completeness, issuer trust, extension correctness, and security flags. Each of these properties addresses a distinct failure mode, and skipping any one of them can leave a deployment vulnerable to a class of TLS errors that are difficult to diagnose after the fact.

Validity means confirming the current date falls between the certificate's notBefore and notAfter values. Coverage means confirming the hostname you serve appears in the Subject Alternative Names extension as a dNSName or iPAddress SAN. Key strength means confirming the algorithm is RSA 2048 or stronger, or ECDSA P-256 or stronger². Chain completeness means verifying a continuous path exists from the leaf up to a trusted root¹. Issuer trust means confirming the signing CA is publicly trusted. Extension correctness means verifying Basic Constraints, Key Usage, and Extended Key Usage are present and configured as expected. Finally, security flags mean checking for EXPIRED, WEAK KEY, SHA-1 SIGNATURE, and WILDCARD SAN conditions that warrant action.

How the seven checks map to common failure modes

Validity failures cause hard errors in every TLS client, while chain completeness failures often appear only on fresh clients that have not cached the intermediate certificate. Key strength and signature algorithm issues matter most for compliance frameworks that mandate minimum cryptographic strength, such as PCI DSS. Extension correctness affects whether a certificate can be used for its intended purpose, since a certificate missing the Extended Key Usage for TLS server authentication may be rejected even when the chain is valid.

The seven checks are most useful as a single pass rather than seven separate inspections. Running them together catches the combination failures that bite in production, such as a valid chain paired with a missing SAN for one hostname. The CapyToolkit Certificate Inspector runs all seven automatically and groups the results into badges that show whether a certificate passes all seven checks, so you see the whole picture in one screen instead of parsing each field by hand.

Checking the live certificate versus the stored certificate file

A certificate that passes all checks in a local file inspection may still fail in production if the wrong file is deployed to the server. Fetching the certificate from the live endpoint shows exactly what TLS clients receive, which may differ from what you believe is configured. The CapyToolkit Certificate Inspector provides a Fetch from domain field that retrieves the live certificate chain by hostname. Using this alongside local PEM inspection catches deployment mismatches: a newly issued certificate not yet deployed, a load balancer node that missed the certificate update, or a CDN that cached the previous certificate.

Furthermore, checking the live certificate confirms the server is sending the full chain rather than the leaf certificate alone, which is a common misconfiguration that causes handshake failures for clients without a cached copy of the intermediate. This issue is especially common when a CDN or reverse proxy terminates TLS separately from the origin server, because the edge node may have a different certificate configuration than the origin.

Interpreting security badges and taking action

The Certificate Inspector displays coloured badges for conditions that require action. EXPIRED (red) means the certificate is past its notAfter date; the only action is to deploy a replacement immediately. EXPIRES IN N DAYS (orange) means fewer than 30 days remain; initiate renewal now. WEAK KEY (orange) means the RSA key is shorter than 2048 bits per NIST SP 800-57; plan replacement at next renewal. SHA-1 SIGNATURE (amber) means the CA signed the certificate using the broken SHA-1 algorithm; replace at next renewal per NIST guidance³. WILDCARD SAN (muted) is informational rather than a security alert; it reminds you that the key covers the entire subdomain namespace and should have tighter key management. Conversely, a certificate with no badges is not necessarily misconfiguration-free; always verify the chain and SANs regardless of badge status.

What each badge means for your remediation timeline

EXPIRED and EXPIRES IN N DAYS require immediate action because clients reject certificates outside their validity window with no override option. WEAK KEY and SHA-1 SIGNATURE are not urgent blockers in most client configurations, but they fail compliance audits and should be addressed at the next planned renewal rather than waiting for an emergency. WILDCARD SAN is purely informational and requires no remediation beyond ensuring the key is stored securely and rotated on a regular schedule.

When a clean badge status still hides a problem

A certificate with green badges can still cause handshake failures if the server is sending only the leaf certificate without the intermediate, or if the SAN list does not include the hostname the client is connecting to. Always treat the badge status as a starting point rather than a complete audit, and use the chain view and SAN list in the inspector to verify the full deployment matches what the badges alone suggest.

When to use this

Use this guide when setting up a new TLS deployment, when debugging a TLS handshake failure, before a scheduled renewal to confirm the current certificate state, or when auditing a domain for a security assessment or compliance review. It also applies when you receive a certificate file from a vendor or partner and need to verify it meets your requirements before installing it on a production server. Run through these seven checks whenever you rotate keys, migrate from RSA to ECDSA, or change Certificate Authorities, since each transition affects fields that clients validate during every handshake connection. Furthermore, use these checks as a post-deployment verification step after any change to your TLS configuration, CDN settings, or load balancer certificate binding, confirming that clients connecting after the update will complete the handshake correctly without encountering errors caused by a misconfigured or misdeployed certificate.

Examples