You’ve got a production certificate that’s expiring in three days, and you need to verify the chain, the SANs, and the signature algorithm. Your first instinct might be to paste it into one of those free SSL checker websites. Don’t. The moment you do, you’ve handed your certificate’s subject DN, internal hostnames, organizational structure, and intermediate chain to a third-party server you don’t control. For anything beyond a throwaway test domain, that’s a dangerous exposure. This article walks through inspecting X.509 certificates locally in your browser, reading every field the chain exposes, understanding the security flags that matter, and catching the misconfigurations that cause real deployment outages, all without sending a single byte to an external service. Every tool in CapyToolkit’s browser-based security suite that processes files without any uploads follows this same local-first model.
What an X.509 Certificate Contains
An X.509 certificate is not an opaque blob of encoded text. It’s a structured data object with clearly defined fields, each serving a specific role in establishing trust during a TLS handshake (how X.509 certificates are structured). Every certificate carries identity information, validity dates, a public key, extensions that define its permitted uses, and a digital signature from the issuing authority.1 When you can read these fields fluently, you stop guessing about certificate problems and start diagnosing them.
CapyToolkit’s certificate inspector that parses PEM, DER, and raw Base64-encoded certificate formats entirely in your browser keeps every byte on your device. No certificate data leaves your device. Each certificate in a chain renders as a separate card with field-level detail and color-coded security flag badges, so you can scan the structure at a glance and focus on what needs attention.
Here’s how to read the core fields you’ll encounter on every certificate.
| Field | Belongs To | Purpose |
|---|---|---|
CN (Common Name) | Subject | Primary hostname the certificate covers |
O (Organization) | Subject | Organization that owns the certificate |
OU (Organizational Unit) | Subject | Department or team within the organization |
C, ST, L | Subject | Country, state, and city of the organization |
Issuer DN fields | Issuer | Same structure as Subject, but identifies the signing CA |
SAN extension | Subject | Additional hostnames and IP addresses beyond the CN |
That table gives you the vocabulary. The sections below explain how these fields interact during a real TLS handshake, and which misconfigurations cause the most pain in production.
Subject and Issuer Fields
Mapping out who owns the identity, the Subject DN bundles several standardized fields: CN (Common Name), which typically holds the primary hostname; O (Organization) and OU (Organizational Unit) for corporate identity; and C (Country), ST (State), and L (Location) for geographic context. Flipping the lens, the Issuer DN uses the exact same field structure but names the Certificate Authority that signed and issued the certificate. When Subject and Issuer are identical, you’re looking at a self-signed certificate, common for internal CAs and root certificates, but a trust red flag if you encounter it on a public-facing leaf cert.
Validity Period and Serial Number
Every X.509 certificate has two timestamps: notBefore, when the certificate becomes valid, and notAfter, when it expires. The validity window can range from days to years, but public CA lifetimes are shrinking as automation becomes the norm: Google’s ACME guidance uses 90-day certificates as its renewal example and recommends renewing at about 60 days.2 Internal CAs and legacy systems may still issue longer-lived certs, but 90 days is a practical planning target for public-facing services that use ACME. Expired certificates cause immediate TLS handshake failures across every client: browsers, API consumers, mobile apps, all of them. Catching SSL certificate expiry before it takes down your endpoints is the single highest-value check you can run. The serial number, assigned by the issuing CA, must be unique within that CA’s namespace. While the serial number itself isn’t a security feature, it becomes critical when checking Certificate Revocation Lists, since revoked certificates are identified by their serial.
Public Key and Signature Algorithm
The public key field specifies the algorithm (RSA or Elliptic Curve) and the key size. RSA keys should be 2048 bits or larger; anything below that is considered weak by current standards.3 EC keys on the P-256 curve or stronger are NIST-recommended elliptic curve options.4 The signature algorithm tells you how the CA signed the certificate. SHA-256 or stronger is the baseline you want. SHA-1 has a known collision weakness, and Microsoft blocks SHA-1-signed certificates in Edge and Internet Explorer 11.5 If you see SHA-1 on a production cert, it needs replacement immediately.
Understanding Subject Alternative Names
The CN field used to be the sole way to specify which hostname a certificate covered. That changed with the Subject Alternative Name extension, which now serves as the authoritative source for hostname matching. Modern browsers ignore the CN entirely for hostname validation and rely exclusively on SANs.6 A single certificate for example.com might include www.example.com, api.example.com, and *.example.com as separate SAN entries, each covering a different scope of your infrastructure.
Wildcard SANs cover all subdomains at one level only. A wildcard on *.example.com matches blog.example.com and api.example.com but does NOT match sub2.sub1.example.com. The wildcard only spans a single label. Getting this wrong is one of the most common causes of “certificate name mismatch” browser warnings. You think you’ve covered your subdomains; the browser disagrees. Incorrect SANs are also easy to miss during renewal, since the CSR generation process doesn’t always carry forward the previous SAN list automatically.
Reading the Full Certificate Chain
A TLS certificate is rarely alone. During a handshake, the server presents a chain: the leaf certificate identifying the domain, one or more intermediate certificates that bridge trust upward, and a root certificate that anchors the chain in the client’s trust store. CapyToolkit’s inspector orders this chain leaf-first and renders connector lines between each issuer-issued pair, making the trust path visible at a glance. Inspecting only the leaf is insufficient. An expired intermediate causes the exact same handshake failure as an expired leaf, and it’s a problem you won’t see unless you look at the full chain. Validating the complete certificate chain from leaf to root surfaces these gaps before they reach a production handshake.
Chain Order and Relationships
The leaf certificate is what the server presents during the TLS handshake. Each subsequent certificate in the chain issued the one above it. The issuer DN of the leaf matches the subject DN of the first intermediate, and so on up the chain. The root certificate is self-signed, meaning its issuer field points to itself. If the chain ends without a self-signed certificate, you have a partial chain. This doesn’t necessarily break TLS, since clients cache known root CAs locally, but it does mean the server isn’t sending the complete chain, which can cause validation failures on clients that don’t have the intermediate cached.
When the Chain Is Broken
Expired intermediates are the silent killer. Your leaf certificate is valid for another six months, but the intermediate expired last week. Every client that doesn’t have that intermediate cached will reject the connection. Mismatched key identifiers are another failure mode: modern X.509 validation uses the Authority Key Identifier and Subject Key Identifier extensions to stitch the trust path together, not simple DN string matching. If the AKID of one certificate doesn’t match the SKID of the next, the chain is structurally broken, even when the DN fields appear identical. Missing intermediates cause the same class of error: clients that can’t build a complete path to a trusted root will refuse the connection, often with a generic “certificate not trusted” message that gives you no useful diagnostic information (incomplete TLS certificate chains and how to fix them). CapyToolkit flags expired certificates with red badges and makes chain relationships visible through connector lines between cards, so you can spot these issues before they reach production.
Security Flags and What They Mean
The inspector shows color-coded badges for conditions that need attention. Flags are evaluated per-certificate, so a clean leaf can sit alongside a flagged intermediate, and that flagged intermediate is still a problem.
| Flag | Severity | Meaning | Action |
|---|---|---|---|
| EXPIRED | Critical (red) | Past the notAfter date | Replace immediately |
| EXPIRES IN N DAYS | Warning (orange) | Fewer than 30 days remaining | Start renewal now |
| WEAK KEY | Warning (orange) | RSA key under 2048 bits | Upgrade to RSA 2048+ or EC P-256+ |
| SHA-1 SIGNATURE | Warning (amber) | Signed with broken SHA-1 | Replace with SHA-256 or stronger |
| WILDCARD SAN | Info (muted) | Wildcard DNS name in SAN list | Review scope covers intended subdomains |
Critical Flags: Expired and Weak Keys
A red EXPIRED badge means the certificate’s notAfter date has passed, causing immediate TLS failure for every client. When fewer than 30 days remain on the validity window, an orange EXPIRES IN N DAYS warning surfaces. Treat this as your renewal signal, because certificate issuance isn’t always instant, especially when you’re dealing with an internal CA or coordinating across teams. An orange WEAK KEY badge flags RSA keys under 2048 bits. These should be replaced with RSA 2048 or an EC key on a P-256 curve or stronger. A weak key on an intermediate or root is especially dangerous because it compromises every certificate that chains through it.
Warning Flags: SHA-1 and Wildcard SANs
SHA-1 SIGNATURE (amber) means the certificate was signed using a hash algorithm with a known collision weakness. Microsoft blocks SHA-1-signed certificates in Edge and Internet Explorer 11, and any cert carrying this badge needs replacement with SHA-256 or stronger. WILDCARD SAN (muted) is informational: it indicates at least one wildcard DNS name in the SAN list. This isn’t a problem by itself, but it’s worth reviewing the scope. A wildcard like *.internal.company.com might cover more subdomains than you intended, including systems that shouldn’t share a certificate.
Why Inspect Certificates Locally Instead of Using Online SSL Checkers
Online SSL checkers (SSL Labs, certificate decoder sites, and similar services) receive your full certificate data when you submit it. That includes the subject DN with your organization name and location, every SAN entry revealing your internal hostnames, and the complete chain showing your CA relationships. For production certificates, you’re handing a map of your infrastructure to a third party. If you’re inspecting certificates for any domain where hostname enumeration is a security concern, that’s a real exposure.
Like all browser-based tools that process everything locally, CapyToolkit’s inspector runs entirely in your browser via client-side JavaScript. No certificate data leaves your device. For public or internet-routable endpoints, the “Fetch from domain” feature uses a stateless proxy to pull the live certificate and stream it back to your browser for client-side parsing without storing, logging, or inspecting the bytes in transit. For internal CAs and private-network certificates, paste the PEM directly. Both paths keep your certificate data out of third-party hands. Beyond privacy, local inspection is also faster. There’s no network round-trip to a third-party service, no queue waiting for a scan to complete, and no rate limits interrupting your workflow during a production incident. When you’re debugging a TLS failure at 2 AM, the last thing you want is to wait for an external service to process your request, or to realize the service is rate-limited or temporarily offline. Local inspection also fits naturally into CI/CD pipelines and pre-deployment scripts. You can verify certificates as part of your build process without introducing a dependency on an external service, keeping your deployment workflow self-contained and reliable.
Common Certificate Misconfigurations You Can Catch Before Deployment
Before pushing a certificate to production, run through this checklist. Every item here can break TLS validation.
- Expired leaf or intermediate certificates. Check every certificate in the chain, not just the leaf.
- Watch for
SHA-1signed certificates still lingering in rotation. Microsoft blocks them in Edge and Internet Explorer 11, so if one surfaces during your audit, replace it before it reaches a production handshake. RSAkeys shorter than2048 bitson production certificates. Weak keys undermine the entire trust model. Upgrade toRSA2048+ orECP-256+.- Missing
SANsare easy to overlook. If a hostname the certificate should cover isn’t listed in theSANextension, clients will throw name mismatch errors, even if that hostname was perfectly valid on the previous certificate. - Wildcard scope that’s too broad. A wildcard like
*.internal.company.commight unintentionally cover sensitive subdomains. Review wildcardSANsduring every renewal. - Servers should send the leaf followed by intermediates, in order. A chain presented out of sequence, or one missing an intermediate entirely, forces clients to fetch the gap themselves, and many won’t bother.
- Internal
CAcertificates that aren’t in the client’s trust store. Everything works fine inside your organization, but the moment an external user or partner API consumer hits the endpoint, the handshake fails.
Catching these issues locally, before deployment, turns a potential production incident into a five-minute review. That’s the difference between a quiet Tuesday and a 2 AM page.
- 1.
D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280
- 2.
Google, “September 2025 - ACME Best Practices,” developers.google.com, April 2026. https://developers.google.com/public-key-infrastructure/updates/september2025-acme-best-practices
- 3.
Elaine Barker and Allen Roginsky, “Transitioning the Use of Cryptographic Algorithms and Key Lengths,” SP 800-131A Rev. 2, NIST, March 2019. https://csrc.nist.gov/pubs/sp/800/131/a/r2/final
- 4.
Lily Chen, Dustin Moody, Andrew Regenscheid, Angela Robinson, and Karen Randall, “Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters,” SP 800-186, NIST, February 2023. https://csrc.nist.gov/pubs/sp/800/186/final
- 5.
Microsoft, “Deprecation of SHA-1 for SSL/TLS Certificates in Microsoft Edge and Internet Explorer 11,” Microsoft Security Advisory 4010323, learn.microsoft.com, May 2017. https://learn.microsoft.com/en-us/security-updates/securityadvisories/2017/4010323
- 6.
P. Saint-Andre and R. Salz, “Service Identity in TLS,” RFC 9525, IETF, December 2023. https://www.rfc-editor.org/rfc/rfc9525
