X.509 Certificate Inspector Reference

X.509 Certificate

X.509 is the international standard that defines the structure of a public key certificate.¹ Defined in RFC 5280, it specifies every field a certificate must carry to participate in the Public Key Infrastructure used by TLS, S/MIME, and code signing.² Each X.509 certificate binds a public key to an identity through a cryptographic signature produced by a Certificate Authority. Consequently, any software trusting the CA automatically extends that trust to the certificate it signed. The standard has evolved through three versions; version 3, the current form, introduced the extensions mechanism that enables Subject Alternative Names, Key Usage constraints, and Certificate Transparency signed certificate timestamps.¹ Understanding the X.509 structure lets you verify that a certificate carries the fields your application, browser, or TLS library actually needs before you deploy it to production.

What is X.509?

Certificate structure: the TBSCertificate fields

Inside every X.509 version 3 certificate, the TBSCertificate (To-Be-Signed Certificate) holds the content the CA commits to with its signature. RFC 5280 defines these core fields: version number (always 2 for v3), a serial number unique within the issuing CA, the signature algorithm OID, the issuer distinguished name, the validity window as notBefore and notAfter UTC timestamps, the subject distinguished name, and the SubjectPublicKeyInfo block encoding the algorithm and key material.³ Furthermore, the extensions field in version 3 carries named extensions such as Basic Constraints, Key Usage, Extended Key Usage, Subject Alternative Names, and Authority Information Access.⁴ Building on this, the CA computes a digest of the DER-encoded TBSCertificate and signs it with its private key, producing the signatureValue that seals the whole structure against any tampering.²

The role of the signature algorithm OID

The signature algorithm OID in the TBSCertificate tells the verifying party which hash-and-sign algorithm the CA used to produce the signatureValue. Common values include sha256WithRSAEncryption and ecdsa-with-SHA256. The algorithm identifier is part of the signed content, so an attacker cannot downgrade the signature algorithm without invalidating the certificate. When you inspect a certificate in the CapyToolkit Certificate Inspector, the signature algorithm field appears in the General section alongside the serial number and validity window.

How the extensions field grows without breaking the core format

The extensions field is what makes X.509 version 3 extensible. Each extension carries an OID, a criticality flag, and an encoded value. Basic Constraints with the CA flag distinguishes certificates that can sign other certificates from leaf certificates that cannot. Key Usage restricts what the public key may be used for, such as digital signature, key encipherment, or certificate signing. A certificate consumer that encounters a critical extension it does not understand must reject the certificate outright, which prevents unknown security-relevant constraints from being silently ignored.

A verifier does not treat every extension as equal in practice. Extended Key Usage narrows the certificate purpose to a specific application such as server authentication or code signing, and a browser rejects a certificate presented for a purpose outside its EKU entries. Authority Information Access points clients to the issuing CA's OCSP responder or CA issuer certificate, which is what lets a browser perform revocation checks and complete a chain it cannot find locally.

X.509 versions and the extensions mechanism

Three versions of X.509 exist, and virtually all certificates in current use are version 3. Version 1 introduced the basic fields: subject, issuer, serial, validity, and public key. Version 2 added Issuer and Subject Unique Identifiers, which proved insufficient for PKI at internet scale. Consequently, version 3 introduced the extensions mechanism, allowing the standard to grow without redesigning the core structure. Extensions can be marked critical or non-critical; a certificate consumer must reject the certificate if it encounters a critical extension it does not understand, ensuring security-relevant constraints are never silently ignored.⁵ Yet not all extensions are critical: Subject Alternative Names carry domain names but a non-critical marking lets legacy implementations that predate SAN support still parse the certificate without failing the connection.⁶

Why version 2 unique identifiers fell short

Version 2 introduced Issuer Unique Identifier and Subject Unique Identifier fields to disambiguate subjects and issuers across time. In practice, these fields were rarely populated by CAs and rarely consumed by TLS libraries. The extra identifiers added complexity to certificate parsing without solving the real problem of binding multiple hostnames to a single certificate. The industry converged on the version 3 extensions mechanism as the cleaner solution, and version 2 fields are now treated as obsolete by modern clients.

How criticality flags shape client behavior

Every version 3 extension carries a criticality boolean. When a client encounters a critical extension it does not recognize, RFC 5280 requires the client to reject the certificate entirely rather than ignore the extension. This rule prevents a CA from sneaking a security-relevant constraint past an older client that lacks support for it. Non-critical extensions, by contrast, may be safely ignored if the client does not understand them, which allows graceful deployment of new extensions without breaking older clients. The CapyToolkit Certificate Inspector displays each extension with its criticality flag so you can see at a glance which constraints are mandatory for clients to honor.

How browsers validate an X.509 certificate

Browser certificate validation follows the path-validation algorithm in RFC 5280 Section 6. Starting from the server's leaf certificate, the browser builds a chain by matching each certificate's issuer name and Authority Key Identifier to the subject and Subject Key Identifier of the next certificate up the chain, ending at a self-signed root in the browser's trust store.⁴ At each step, the browser verifies the CA's signature, checks the validity window against the current time, and enforces Basic Constraints: only certificates with the CA flag set may sign other certificates. Conversely, a leaf certificate with the CA flag set is suspicious and browsers reject it as a potential attack. Inspecting the full chain with the CapyToolkit Certificate Inspector reveals each of these fields so you can catch misconfigurations before they cause handshake failures in production.

Chain building and the Authority Key Identifier match

The browser builds the certificate chain by matching the Authority Key Identifier extension of each certificate to the Subject Key Identifier of the next certificate up the hierarchy. This pairing is more reliable than matching issuer names alone because distinguished names can be reused across CA reissues, while key identifiers change whenever the CA generates a new key pair. When a missing intermediate breaks this chain, the browser cannot find a certificate whose Subject Key Identifier matches the Authority Key Identifier of the leaf, and the handshake fails with an unable-to-verify-leaf error.

Why Basic Constraints matter for CA boundary enforcement

Basic Constraints with the CA flag set marks a certificate as authorized to sign other certificates. A leaf certificate that accidentally has the CA flag set is a security risk because any private key holder could use it to issue arbitrary certificates that browsers would trust. For this reason, browsers reject leaf certificates with the CA flag set unless the certificate also carries a path length constraint that explicitly permits the CA role. The CapyToolkit Certificate Inspector flags this condition with a warning badge so you can spot a misconfigured CA flag before deployment.

Practical uses of X.509 certificate inspection

Knowing the X.509 structure makes certificate inspection a productive troubleshooting step rather than a lookup of unfamiliar terms. When a TLS handshake fails, inspecting the certificate chain immediately tells you whether the problem is an expired certificate, a missing intermediate, a hostname mismatch, or a weak key algorithm. Each condition maps directly to X.509 fields: the validity window for expiry, the chain of Issuer and Subject pairs for completeness, the Subject Alternative Names extension for hostname coverage, and the SubjectPublicKeyInfo block for key algorithm and bit length.⁶ Consequently, a competent reading of an X.509 certificate reduces the diagnostic space for most TLS failures to a known cause within seconds. The CapyToolkit Certificate Inspector parses all of these fields into a structured card view so you and non-expert teammates can read and act on the same information.

Try in the tool

TLS Certificate

TLS certificates authenticate servers and encrypt traffic between browsers and web servers. Every HTTPS connection begins with a TLS handshake in which the server presents an X.509 certificate; the client verifies that certificate against its trusted CA store before agreeing to exchange encrypted data. RFC 5280 defines the certificate structure, while RFC 8446 defines TLS 1.3, the current handshake protocol. Consequently, inspecting a TLS certificate reveals whether the server's identity is trustworthy and whether any security flags warrant attention before you proceed. The certificate shows the domain names the Subject Alternative Names extension covers, the key algorithm and bit length, the issuing CA, and the validity window that determines when renewal is required. Expired TLS certificates cause immediate user-facing errors that break all encrypted traffic to the affected host without any grace period.

What is TLS?

TLS certificate fields that matter for HTTPS

Checking a TLS certificate for HTTPS means verifying six things in order. First, confirm that the domain name appears in the Subject Alternative Names extension as a DNS entry. CN-only matching is obsolete and modern browsers ignore it per RFC 6125.² Second, check the notAfter date to verify the certificate has not expired. Third, look at the key algorithm: RSA 2048-bit is the practical minimum, while ECDSA P-256 provides equivalent security with a smaller key.³ Fourth, verify the issuing CA is publicly trusted. Fifth, check that the Basic Constraints extension does not set the CA flag unless the certificate is intentionally an intermediate. Building on this, the CapyToolkit Certificate Inspector surfaces all six checks via security badges so you can spot problems at a glance without running openssl commands manually.

Subject Alternative Names and the deprecation of CN matching

Modern TLS clients ignore the Common Name field entirely when a SAN extension is present. RFC 6125 made this mandatory for all clients implementing hostname verification, which means a certificate that lists only a domain in the CN field without a SAN entry fails hostname verification in every current browser. When you inspect a certificate in the CapyToolkit Certificate Inspector, the SAN section shows every dNSName entry so you can confirm coverage for all hostnames you intend to serve.

Key algorithm choices and their handshake consequences

RSA 2048-bit remains the most compatible key algorithm, but ECDSA P-256 produces a smaller certificate and a faster handshake. The handshake size difference matters on high-traffic servers where every byte of the Certificate message adds up across thousands of connections per second. Choosing ECDSA also reduces the computational cost of signature verification on clients, which is especially noticeable on mobile devices with limited CPU resources.

Picking the key algorithm is not only a security decision but a performance one. A smaller ECDSA certificate shrinks the TLS Certificate message, which helps pages reach first byte faster on constrained mobile networks where every round trip is expensive. RSA 2048-bit stays the safer choice when the client base includes older hardware or libraries that lack ECDSA support, so the right answer depends on the traffic you actually serve.

How a TLS certificate is verified during the handshake

During the TLS 1.3 handshake, the server sends its certificate chain immediately after the server-hello message.¹ The client constructs a path from the leaf certificate to a trusted root by matching issuer names and Authority Key Identifiers up the chain. At each step the client verifies the CA's signature over the certificate below it. Consequently, a missing intermediate certificate causes the handshake to fail even when the leaf certificate itself is valid, because the client cannot complete the trust path to the root. Yet many TLS misconfigurations are exactly this: a correctly issued leaf certificate served without the required intermediate. The fix is to append the intermediate certificate to the server's certificate file, ordering the chain leaf-first, which is what Let's Encrypt's fullchain.pem provides by default.⁴

Why a missing intermediate breaks the chain silently

A leaf certificate served without its intermediate forces the browser to search for the intermediate in its local trust store. Most browsers do not cache intermediates aggressively, so visitors connecting for the first time see an untrusted certificate error even though the leaf is correctly signed. The CapyToolkit Certificate Inspector flags this condition by showing the chain ending at an INTERMEDIATE CERTIFICATE card rather than a ROOT CERTIFICATE card, making the missing link immediately visible without inspecting each certificate's issuer separately.

How stapling and TLS 1.3 change the verification path

OCSP stapling lets the server attach a signed revocation status response during the handshake, which saves the browser a separate HTTP request to the CA's OCSP responder. TLS 1.3 made stapling negotiation cleaner by folding it into the CertificateStatus message. When stapling is absent, the browser may perform a soft-fail OCSP check that delays the handshake or, in strict environments, a hard-fail check that blocks the connection entirely if the OCSP responder is unreachable.

TLS certificate renewal and the shrinking validity window

Certificate validity windows have been shrinking steadily, driven by security research and CA/Browser Forum policy. Let's Encrypt currently issues certificates valid for 90 days and announced a reduction to 45 days by 2028.⁵ The CA/Browser Forum ballot SC-081v3, passed in April 2025, will reduce the maximum publicly trusted TLS certificate lifetime from 398 days to 47 days by March 2029.⁶ Furthermore, shorter validity windows reduce the damage window if a private key is compromised, since an attacker can use a stolen key only until the certificate expires. Building on this, the shrinking validity window makes automated renewal via ACME (RFC 8555) a practical requirement rather than an optional convenience for any site running more than a handful of TLS endpoints.⁵

Why shorter lifetimes reduce the blast radius of key compromise

When a private key is stolen, the attacker can impersonate the server until the certificate expires or is revoked. Revocation is unreliable because many browsers soft-fail on OCSP checks, so a compromised certificate may continue to be trusted for days even after the CA marks it revoked. Short-lived certificates cap this exposure window automatically: a 47-day certificate stolen on day 46 is only useful for one day. This is the primary security argument behind the CA/Browser Forum's move toward shorter lifetimes.

How ACME automation changes the operational model

ACME clients like Certbot automate the renewal process by proving domain control via HTTP-01 or DNS-01 challenges and submitting a new certificate request to the CA. The entire flow runs on a schedule, typically every 60 days for a 90-day certificate, and the client reloads the web server after obtaining the new certificate. With 47-day certificates, the renewal cadence tightens to roughly every 30 days, which makes reliable automation essential rather than optional. The CapyToolkit Certificate Inspector's Fetch from domain feature lets you verify that the renewed certificate is actually deployed after each renewal cycle.

Fetching live TLS certificates for inspection

Inspecting a TLS certificate from a live server tells you exactly what clients receive, which may differ from what you believe is deployed. The CapyToolkit Certificate Inspector's Fetch from domain field retrieves the certificate chain by hostname, sending only the hostname to the certificate service and parsing everything client-side. For command-line inspection, echo | openssl s_client -connect hostname:443 -servername hostname -showcerts retrieves the full chain, which you can then paste into the inspector for a structured view. Conversely, inspecting only the certificate file on disk without fetching from the live endpoint leaves a stale deployment undetected: a CDN caching an old certificate, a load balancer node that missed the update, or a server still serving the expired certificate after an incomplete rollout.

Try in the tool

SSL Certificate Expiry

Certificate expiry is one of the most preventable causes of production HTTPS outages. When a certificate's notAfter date passes, browsers immediately reject the connection and display an untrusted certificate error. There is no grace period. The notAfter field is defined in RFC 5280 Section 4.1.2.5 as a GeneralizedTime or UTCTime value encoding the exact UTC moment the certificate ceases to be valid.¹ Consequently, a certificate that expires at midnight on a Sunday causes production failures that surprise teams at the start of the working week if monitoring is absent. The CapyToolkit Certificate Inspector displays the expiry date, the number of days remaining, and an EXPIRES IN N DAYS badge when fewer than 30 days remain, giving you an immediate visual signal without running openssl commands against each server.

What is notAfter?

What happens when a certificate expires

When a certificate's notAfter date passes, every TLS library that enforces certificate validation rejects it. Browsers show a full-page warning that blocks users from reaching the site. API clients using strict certificate validation throw errors that abort requests immediately. Monitoring tools emit alerts if they exist, and load balancers may route traffic to other backends that are also serving the expired certificate. Consequently, expiry events are rarely isolated: the same certificate deployed across multiple servers or CDN edges fails simultaneously. Yet the root cause is almost always the same: a renewal process that was manual, inconsistently applied, or not monitored. Fixing the renewal process matters as much as replacing the expired certificate in the immediate aftermath.

Why expiry hits all backends at once

Most production sites deploy the same certificate to multiple servers behind a load balancer, and often to CDN edge nodes as well. When that certificate expires, every node serving it starts rejecting connections simultaneously. The result is a complete outage rather than a partial degradation, because TLS validation happens at the connection layer before any application logic runs. There is no graceful fallback: the browser displays an untrusted certificate page and the user cannot proceed without clicking through a security warning.

The monitoring gap that makes expiry a surprise

Teams often assume that certificate renewal is handled by the CA or by an automated tool, but they lack monitoring that confirms the renewed certificate is actually deployed. Without such monitoring, a failed renewal or a deployment that skipped one server goes unnoticed until the certificate expires. The CapyToolkit Certificate Inspector surfaces the expiry countdown as a prominent badge when fewer than 30 days remain, giving operations teams a visual signal that is easy to include in status dashboards and weekly reviews.

The cheapest defence is a repeatable inspection habit rather than a heroics-driven response. A weekly pass that checks the Days Left countdown across every public endpoint turns expiry from a page-on-call event into a routine item you close during business hours. Pair that with the structured X.509 parsing in the CapyToolkit Certificate Inspector and the same inspection covers intermediates and SAN coverage, so one workflow catches the three most common TLS incidents before they reach users.

Renewal timing and the 30-day warning window

Industry guidance recommends renewing TLS certificates at least 30 days before expiry.³ The 30-day threshold gives enough time to retry a failed renewal without urgency, and it aligns with the default alerting threshold in popular monitoring tools. Let's Encrypt's ACME client Certbot begins renewal attempts when less than one-third of the certificate's lifetime remains, which leaves roughly 30 days on a standard 90-day Let's Encrypt certificate.⁴ Furthermore, with the CA/Browser Forum's approved reduction of maximum certificate lifetimes to 47 days by March 2029², the renewal window becomes a much larger fraction of the total validity period. Building on this, a 30-day renewal window on a 47-day certificate means you must renew within 17 days of issuance, making ACME-based automation the only practical solution at any meaningful scale.

Why the 47-day limit changes the renewal calculus

On a 398-day certificate, a 30-day renewal window is only 7.5 percent of the total lifetime, which leaves ample room for manual intervention. On a 47-day certificate, that same 30-day window consumes 64 percent of the lifetime, leaving only 17 days between issuance and the start of the renewal window. This compression makes manual renewal impractical for any organization operating more than a handful of certificates, because the renewal work becomes a near-continuous operational task rather than a quarterly ritual.

How Certbot and other ACME clients schedule renewal

Certbot begins renewal attempts when less than one-third of the certificate lifetime remains, which translates to roughly 30 days on a 90-day certificate. The client runs twice daily and retries on failure, so a transient DNS or HTTP challenge failure does not immediately cause an outage. With 47-day certificates, the same one-third rule kicks in around day 16, which means the client starts trying to renew almost immediately after deployment. This tight loop makes reliable challenge infrastructure essential: a DNS provider outage on day 16 of a 47-day certificate can cause an expiry event.

Intermediate certificates also expire independently

Checking certificate expiry before it becomes an incident requires reading the notAfter field for every certificate in the chain, not just the leaf. Intermediate certificates also expire, typically on a longer cycle of five to ten years⁵, but a forgotten intermediate that expires causes the same handshake failure as an expired leaf. Furthermore, certificates served by CDNs, edge proxies, or API gateways may differ from the certificate in your management system, especially when deployments are inconsistent across a fleet. Running the CapyToolkit Certificate Inspector against your live domain using the Fetch from domain field shows you exactly what certificate clients receive, including its expiry countdown, which may differ from what you believe is deployed.

Why intermediate expiry is easy to forget

Intermediate certificates carry validity windows of five to ten years, which is long enough for the original deployment team to rotate out of the organization before the certificate comes up for renewal. When the intermediate finally expires, every leaf certificate it signed becomes part of an invalid chain, and the failure mode is identical to an expired leaf: browsers display an untrusted certificate error and API clients abort requests. The CapyToolkit Certificate Inspector shows the Days Left countdown for every certificate in the chain, so you can spot an intermediate approaching its expiry date during a routine inspection of a leaf certificate.

How CDN and gateway caching hide intermediate changes

CDNs and edge proxies sometimes cache the certificate chain served by the origin, which means replacing the intermediate on the origin does not take effect until the cache expires. This delay can cause a newly deployed intermediate to go unnoticed until a client that does not have the old intermediate in its cache attempts to connect and fails. Running the CapyToolkit Certificate Inspector against your live domain shows the exact chain that clients receive, including any intermediate that the CDN has not yet refreshed.

Internal certificates and long-lived validity windows

Internal certificates issued by private CAs are not subject to CA/Browser Forum requirements and may carry validity periods of multiple years. While longer validity is convenient for internal services, a compromised internal certificate stays valid far longer without detection. Checking the notBefore and notAfter fields in the Certificate Inspector gives you the exact window for every certificate in the chain, including long-lived intermediates that are forgotten until they expire during a production incident. Conversely, even internal PKI benefits from a defined renewal cadence: organizations with automated renewal for internal certificates tend to detect key material compromise faster than those relying on manual cycles triggered only by upcoming expiry notices.

Try in the tool

Self-Signed Certificate

A self-signed certificate carries no third-party trust. Unlike a CA-issued certificate, where a Certificate Authority vouches for the identity by signing the certificate with its own key, a self-signed certificate is signed by the same private key whose public key the certificate contains. RFC 5280 Section 3.2 defines a self-signed certificate as one where the Subject and Issuer distinguished names are equal and the signature validates against the certificate's own public key.¹ Browsers display an untrusted certificate error for self-signed certificates unless the certificate is explicitly added to the device's trust store. Yet for private infrastructure, internal services, and development environments, self-signed certificates are entirely appropriate: they provide encryption without the overhead of CA issuance and are not subject to CA/Browser Forum validity limits.²

What is self-signed?

When self-signed certificates are appropriate

Self-signed certificates serve legitimate purposes in controlled environments where the certificates are explicitly trusted by the clients that connect. Private CA infrastructure uses self-signed root certificates as trust anchors: the root CA signs intermediate certificates with its own key, and the root certificate is distributed to client trust stores out-of-band rather than through the public CA chain. Internal services communicating over a corporate network use self-signed certificates to provide TLS encryption without exposing internal hostnames to a public CA. Furthermore, development environments routinely use self-signed certificates to replicate HTTPS behavior locally without purchasing or automating CA-issued certificates. Building on this, tools like mkcert generate locally-trusted self-signed certificates and add the necessary root CA to your operating system's trust store automatically, giving you browser-trusted HTTPS at localhost without the untrusted certificate warning.³

How private PKI uses self-signed roots as trust anchors

A private PKI begins with a self-signed root certificate that serves as the trust anchor for the entire hierarchy. The root certificate is distributed to every device that needs to trust certificates issued by the PKI, typically through group policy on Windows, mobile device management profiles on iOS and Android, or manual installation on Linux. Once the root is in place, the organization can issue intermediate CA certificates and leaf certificates without involving any public CA. The CapyToolkit Certificate Inspector identifies these roots with the ROOT CERTIFICATE · self-signed label so you can see the top of the chain at a glance.

Why development environments benefit from self-signed certificates

Development environments need TLS for testing HTTPS behavior, cookie security flags, and mixed-content behavior, but purchasing or automating publicly trusted certificates for every developer workstation is impractical. Self-signed certificates provide the same encryption and handshake behavior as publicly trusted ones, with the only difference being that browsers display a warning unless the certificate is explicitly trusted. Tools like mkcert automate this trust setup by installing a local CA into every major trust store on the developer's machine.

The practical trade-off is trust distribution versus convenience. A self-signed certificate is free and instant, but every client must install its key before the connection is trusted, which does not scale beyond a handful of controlled machines. A CA-issued certificate shifts that burden to the public trust store, so any visitor is trusted automatically. For a small internal tool the self-signed route is fine; for anything with outside users the public CA path avoids the untrusted warning entirely.

Security risks of self-signed certificates in production

Using a self-signed certificate on a publicly accessible service carries real security risks. The untrusted certificate warning that browsers display is not merely cosmetic: it signals that the client cannot verify the server's identity through any trusted third party, making man-in-the-middle attacks possible for any attacker who can position themselves between the client and the server. Consequently, users who click through the warning accept an unverifiable connection. For API clients, disabling certificate verification to allow self-signed certificates suppresses the protection that TLS provides, defeating the purpose of encryption entirely. Common examples include using the -k flag in curl⁴ or verify=False in Python requests⁵. Yet developers often enable this option in staging environments and then accidentally retain it in production code, which is a serious security gap.

Why disabling verification in staging becomes a production risk

Developers frequently disable certificate verification in staging to avoid configuring trust stores for self-signed test certificates. The risk is that this configuration propagates to production through copy-paste, through environment files that are not properly separated, or through Docker images built with staging defaults. Once verification is disabled in production, the application accepts any certificate, including one presented by an attacker performing a man-in-the-middle attack. The CapyToolkit Certificate Inspector helps you audit this risk by showing exactly which certificates the server presents and whether they chain to a trusted root.

How man-in-the-middle attacks exploit unverified connections

In a man-in-the-middle attack, an attacker intercepts the connection between the client and the server and presents their own certificate. If the client does not verify the certificate, the attack succeeds without any visible warning. The attacker can then read and modify all traffic passing through, including authentication credentials and sensitive data. This is why disabling verification, even for self-signed certificates, removes the core protection that TLS is designed to provide. The attack is especially dangerous on public Wi-Fi networks where an attacker can position themselves between the client and the server without either party noticing.

Identifying self-signed certificates in the inspector

The CapyToolkit Certificate Inspector labels self-signed certificates with the badge ROOT CERTIFICATE · self-signed when the Subject and Issuer distinguished names match. Inspecting the Issuer fields next to the Subject fields shows this immediately without reading raw certificate bytes. A self-signed certificate intended as a trust anchor will also show Basic Constraints with CA: true and typically carries a path length constraint appropriate for the depth of PKI hierarchy it supports. Furthermore, the signature algorithm field shows the algorithm the certificate used to sign itself. For production troubleshooting, seeing a self-signed leaf certificate where you expected a CA-issued certificate immediately indicates that the wrong certificate was deployed or that the ACME renewal process failed silently.

Creating development certificates with mkcert

For local development, mkcert is the most practical tool for generating self-signed certificates that your browser trusts without warnings.³ Running mkcert -install creates a local CA certificate and installs it in your operating system's trust store and in Firefox's certificate store if installed. Running mkcert localhost 127.0.0.1 ::1 then generates a certificate for local addresses signed by that CA. Consequently, browsers on your machine trust the resulting certificate because they trust the local CA you installed. Yet this trust is limited to your machine: other devices or CI environments do not have the local CA installed, so you cannot reuse these certificates beyond your development workstation. The CapyToolkit Certificate Inspector parses mkcert-generated certificates the same as any other PEM, showing you the self-signed issuer and the local CA chain.

Why mkcert certificates are trusted locally but not on other devices

mkcert installs a local CA certificate into the trust stores of the operating system and any detected browsers. This CA is unique to your machine and is not shared with other devices, so a certificate signed by it will be trusted on your machine but rejected elsewhere. This is by design: the local CA never leaves your machine, so an attacker cannot use it to issue certificates that are trusted on other devices. The CapyToolkit Certificate Inspector shows the local CA in the chain view, making it clear that the certificate is intended for local use only.

How mkcert handles multiple local hostnames

mkcert accepts multiple hostnames on the command line, generating a single certificate with each hostname as a dNSName SAN entry. This means you can run mkcert localhost 127.0.0.1 ::1 myapp.local and get a certificate that authenticates all of those names. The CapyToolkit Certificate Inspector displays every SAN entry in the Extensions section, so you can verify that the certificate covers all the hostnames your local development environment needs.

Try in the tool

Wildcard Certificate

Wildcard certificates cover a single subdomain label using the asterisk character as the leftmost component in a Subject Alternative Name. A certificate with *.example.com in its SAN list authenticates www.example.com, api.example.com, mail.example.com, and any other single-label subdomain without requiring a separate certificate for each. RFC 6125 Section 6.4.3, which governs how TLS clients match domain identifiers against certificates, restricts wildcard matching to the complete left-most label: the asterisk matches exactly one label, not multiple nested subdomains.¹ Consequently, *.example.com does not cover sub.api.example.com, a point that frequently surprises teams adding new nested subdomains to existing infrastructure. The CapyToolkit Certificate Inspector flags any certificate containing a wildcard SAN with a WILDCARD SAN badge so you can identify this constraint immediately during an audit.

What is *.domain?

What a wildcard certificate covers and what it does not

A wildcard certificate with *.example.com in its SAN list authenticates any hostname that substitutes a single DNS label for the asterisk: www.example.com, api.example.com, staging.example.com, and so on. Checking the Subject Alternative Names field in the CapyToolkit Certificate Inspector shows the full list of names the certificate covers, including any wildcard entries. Yet the single-label restriction has real operational consequences. When you add a service at app.api.example.com, the wildcard *.example.com does not cover it; you would need *.api.example.com or a certificate listing app.api.example.com as an explicit SAN. Furthermore, wildcard certificates do not cover the apex domain itself: *.example.com does not authenticate example.com. Certificates that need to cover both typically include *.example.com and example.com as two separate SAN entries.

Why the single-label restriction surprises teams

RFC 6125 restricts wildcard matching to a single DNS label, which means *.example.com matches www.example.com but not a.b.example.com. Teams often assume the asterisk matches any number of labels, leading to hostname mismatch errors when they add a nested subdomain. The CapyToolkit Certificate Inspector shows the wildcard SAN entry alongside all other SANs, so you can see exactly which hostnames are covered and plan for nested subdomains that require their own wildcard or explicit SAN entry.

How to cover both the apex domain and subdomains

A wildcard certificate with *.example.com does not authenticate example.com itself, because the asterisk must substitute at least one label. To cover both, the certificate must include *.example.com and example.com as two separate SAN entries. Most publicly trusted CAs include both by default when you request a wildcard certificate, and the CapyToolkit Certificate Inspector displays both entries in the Extensions section so you can confirm the coverage is complete.

When planning certificate coverage, count the namespace the wildcard actually protects rather than the number of hostnames it appears to cover. A single *.example.com entry handles every one-label subdomain you might spin up, which keeps the certificate list short as the service grows. The CapyToolkit Certificate Inspector renders each SAN entry individually, so a quick scan of the Extensions section tells you whether the apex, the wildcard, and any explicit hostnames are all present before you deploy.

Security implications of wildcard certificates

Wildcard certificates concentrate private key risk across all subdomains they cover. If the private key for *.example.com is compromised, an attacker can impersonate any subdomain, including internal, staging, and administrative subdomains, until the certificate is revoked and replaced. Consequently, the revocation and replacement cost is higher than for a single-domain certificate. NIST SP 1800-16B recommends that CNs and SANs should not include wildcards, and the broader NIST key management framework emphasizes that key management discipline must be proportional to the number of systems the key protects.² Building on this, multi-domain certificates listing individual hostnames without wildcards provide better key compartmentalization when the number of subdomains is predictable. Wildcard certificates remain the practical choice for dynamic subdomain architectures where new subdomains are created frequently.

Why key compartmentalization matters for wildcard certificates

A wildcard certificate uses the same private key for every subdomain it covers. When that key is compromised, the blast radius includes every subdomain, not just the one where the compromise occurred. Multi-domain certificates with individual SAN entries let you use different keys for different subdomains, so a compromise of one key does not expose the others. The CapyToolkit Certificate Inspector shows the key algorithm and bit length in the General section, making it easy to verify that all certificates in your inventory use consistent key strength.

When wildcards are the right operational choice

Wildcard certificates shine in environments where subdomains are created frequently and unpredictably, such as multi-tenant SaaS platforms that provision a new subdomain per customer. In these environments, issuing a new certificate for every subdomain would require constant CA interaction and DNS validation. A wildcard certificate covers all current and future subdomains under a single SAN entry, at the cost of concentrating key risk across the entire namespace.

Wildcard SANs versus wildcard Common Name

Modern TLS clients match domain names against the Subject Alternative Names extension, not the Common Name field in the Subject. RFC 2818 specifies that if a certificate contains a SAN extension, the CN must not be used for hostname matching.³ Consequently, a certificate with *.example.com only in the CN field and no SAN extension is rejected by current browsers and TLS libraries, even though older clients once accepted CN-only matching. The WILDCARD SAN badge in the Certificate Inspector confirms that the wildcard appears in the correct field, the SAN extension, where TLS clients actually look for it. Conversely, a wildcard in the CN without a SAN extension produces a certificate that fails hostname verification in all modern clients.

Why CN-only wildcard matching was deprecated

Early TLS implementations matched the server hostname against the Common Name field when no SAN extension was present. This worked for single-domain certificates but provided no standard way to cover multiple domains. The SAN extension solved this by allowing multiple hostnames in a single field, and RFC 6125 made SAN matching mandatory when the extension exists. The CapyToolkit Certificate Inspector displays the SAN extension separately from the CN field, so you can see exactly which names the certificate authenticates.

How to verify a wildcard is in the SAN extension

A wildcard that appears only in the CN field is ignored by modern clients, which means the certificate fails hostname verification even though the wildcard looks correct at a glance. The CapyToolkit Certificate Inspector flags wildcards in the SAN extension with the WILDCARD SAN badge, confirming that the wildcard is in the field that TLS clients actually check during hostname verification.

Let's Encrypt wildcard certificate issuance via DNS-01

Let's Encrypt issues wildcard certificates only through the DNS-01 ACME challenge⁴, which requires you to create a TXT record in your domain's DNS zone to prove control over all subdomains.⁵ The HTTP-01 challenge cannot be used for wildcard certificates because it only proves control over specific hostnames, not the entire subdomain namespace. Consequently, automating wildcard certificate renewal requires your ACME client to have API access to your DNS provider for programmatic TXT record creation. Furthermore, many DNS providers offer APIs specifically for this purpose, and ACME clients such as Certbot, acme.sh, and Caddy ship with plugins supporting the major DNS providers.⁶ After Let's Encrypt issues the wildcard certificate, the CapyToolkit Certificate Inspector displays the *.example.com SAN entry with the WILDCARD SAN badge, confirming the certificate covers the intended namespace.

Try in the tool

Intermediate CA Certificate

Intermediate Certificate Authority certificates occupy the middle layer of the public key infrastructure hierarchy. A root CA, whose certificate is embedded in operating system and browser trust stores, signs one or more intermediate CA certificates. Those intermediate CAs then sign the leaf certificates that web servers present during TLS handshakes. This two-layer structure keeps root CA private keys offline and air-gapped, since the root needs to sign only a small number of intermediate certificates rather than signing every leaf certificate directly.¹ Consequently, if an intermediate CA's private key is compromised, the root CA can revoke it without requiring every browser to update its trust store. Understanding the role of intermediate certificates is essential for debugging certificate chain errors and configuring web servers correctly.

What is Intermediate CA?

Why intermediate CAs exist in the PKI model

Root CA certificates are trusted because browser and OS vendors have agreed to include them in their trust stores after a rigorous audit process. Adding or removing a root from all device trust stores takes years and requires coordination with every major OS vendor.³ Consequently, root CA private keys are stored in hardware security modules that are often physically air-gapped to protect them from compromise.¹ Because these keys cannot be used continuously for signing millions of leaf certificates, intermediate CAs were designed to bridge the gap. The root CA signs a small number of intermediate CA certificates, whose private keys are operational and used daily to sign leaf certificates. Furthermore, intermediate CAs can be revoked by the root if compromised, replacing only the intermediate key without disrupting the root's position in trust stores across billions of devices.

Why root CA keys are kept offline

Root CA private keys are the most valuable assets in the public key infrastructure because every certificate chains up to a root. If a root key is compromised, every certificate ever issued by that root or its intermediates becomes untrustworthy. To prevent this, root keys are stored in hardware security modules that are physically air-gapped and require multiple authorized personnel to operate. The CapyToolkit Certificate Inspector identifies root certificates with the ROOT CERTIFICATE · self-signed label, making it easy to see which certificate sits at the top of the chain.

How intermediate revocation limits the blast radius

When an intermediate CA key is compromised, the root CA can revoke just that intermediate without affecting the root or other intermediates. This limits the blast radius to the certificates signed by the compromised intermediate, rather than invalidating every certificate in the PKI. The CapyToolkit Certificate Inspector shows the chain structure so you can see which certificates are signed by which CA and assess the impact of a revocation.

A practical takeaway is to keep the chain shallow and the roots protected. Each extra intermediate in the path adds another certificate that must stay valid and correctly deployed, so a chain with two intermediates carries two independent expiry dates and two places to misconfigure. The CapyToolkit Certificate Inspector renders each link in the chain as a card, so you can verify at a glance that every intermediate is present, in order, and signed by the certificate directly above it.

Configuring web servers to send the full chain

Web servers must send the complete certificate chain, including the leaf and all intermediate certificates, during the TLS handshake. Sending only the leaf certificate causes handshake failures on clients that do not have the intermediate cached, which is most clients connecting for the first time. The order matters: the leaf certificate must appear first, followed by each intermediate in sequence up to but not including the root.⁴ Browsers download the root from their trust store, not from the server. When you configure nginx or Apache, you typically concatenate the leaf and intermediate into a single PEM file. Building on this, the CapyToolkit Certificate Inspector's chain view makes the missing-intermediate problem immediately visible: if the chain ends with an INTERMEDIATE CERTIFICATE card rather than a ROOT CERTIFICATE · self-signed card, the chain is incomplete and you need to add the missing certificate to your server configuration.

Why chain order matters for TLS handshakes

The TLS handshake expects the certificate chain in leaf-first order, with each certificate issued by the one that follows it. If you reverse the order or omit an intermediate, the client cannot build a valid path from the leaf to a trusted root, and the handshake fails. The CapyToolkit Certificate Inspector displays the chain in the correct order with connector lines between cards, so you can verify that each certificate is issued by the next one in the sequence.

How to concatenate the full chain for nginx and Apache

For nginx, the ssl_certificate directive should point to a file that contains the leaf certificate followed by one or more intermediate certificates, all in PEM format. For Apache, the SSLCertificateFile directive points to the leaf, while SSLCertificateChainFile points to the intermediate. Let's Encrypt provides a fullchain.pem file that concatenates the leaf and intermediate in the correct order, ready to use with nginx. The CapyToolkit Certificate Inspector parses this file and shows each certificate as a separate card in the chain view.

Inspecting intermediate certificate fields

An intermediate CA certificate shares the same X.509 structure as any other certificate, but several fields distinguish it from a leaf. The Basic Constraints extension has cA: true, allowing it to sign further certificates. The Key Usage extension typically includes Certificate Sign and CRL Sign, while leaf certificates carry Digital Signature and sometimes Key Encipherment.² The pathLenConstraint, if present, limits the depth of subordinate CAs the intermediate is permitted to sign. Yet not all intermediate certificates carry a pathLenConstraint; its absence simply means no depth restriction is enforced at the certificate level. Inspecting the full chain using the Certificate Inspector shows each certificate's role label and expands each card individually so you can compare fields across the chain without running separate openssl commands for each certificate.

Intermediate CA expiry and multi-year validity

Intermediate CA certificates expire independently of the leaf certificates they signed. A typical intermediate CA certificate carries a validity window of five to ten years, which means it is easy to forget about until it expires and suddenly makes every leaf certificate it signed invalid.⁵ Monitoring intermediate expiry requires reading the notAfter field for the full chain, not just the leaf. Furthermore, when an intermediate CA expires, replacing it requires the root CA to sign a new intermediate and republish it, which takes coordination with the CA. Building on this, the CapyToolkit Certificate Inspector shows the Days Left countdown for every certificate in the chain, so you can spot an intermediate approaching its expiry date during a routine inspection of a leaf certificate and plan the CA coordination before it becomes a production incident.

Why intermediate expiry is easy to forget

Intermediate certificates carry validity windows of five to ten years, which is long enough for the original deployment team to rotate out of the organization before the certificate comes up for renewal. When the intermediate finally expires, every leaf certificate it signed becomes part of an invalid chain, and the failure mode is identical to an expired leaf. The CapyToolkit Certificate Inspector shows the Days Left countdown for every certificate in the chain, so you can spot an intermediate approaching its expiry date during a routine inspection.

How to plan intermediate replacement with the CA

Replacing an intermediate requires the root CA to sign a new intermediate certificate and republish it, which takes coordination with the CA and may involve a waiting period. Planning this replacement well in advance of the expiry date ensures you have time to deploy the new intermediate to all servers before the old one expires. The CapyToolkit Certificate Inspector displays the notAfter date for every certificate in the chain, giving you the exact deadline for planning the replacement.

Try in the tool

Root CA Certificate

Root CA certificates are the trust anchors of the entire public key infrastructure. A root CA certificate is self-signed, meaning its Issuer and Subject distinguished names are identical and the signature validates against its own public key. Operating systems, browsers, and TLS libraries ship with a pre-installed collection of trusted root certificates; any certificate that chains up to one of these roots is automatically trusted without additional configuration. Defined in RFC 5280, root CAs sit at the top of the certification hierarchy¹ and their private keys are guarded with the highest security measures, often stored in hardware security modules inside physically secured facilities.² Consequently, a compromised root CA certificate can undermine trust in every certificate it has signed or that chains through its intermediates, making root CA security a foundational pillar of internet security.

What is Root CA?

How root certificates enter trust stores

Operating system vendors maintain lists of trusted root CAs through a program that includes an audit requirement. Apple, Microsoft, Mozilla, and Google each maintain their own root programs with their own criteria. A CA that wants its root certificate included must pass an independent audit, typically a WebTrust or ETSI audit, agree to the program's policy requirements, and submit its root certificate for review.³ Consequently, becoming a publicly trusted CA takes years and requires ongoing compliance. Browsers and operating systems distribute root updates through software updates, which means newly added roots take time to propagate to all devices, and distrusted roots persist on devices that have not received the update. Building on this, the decision to distrust a CA, which removes all certificates it issued from trust, is one of the most consequential actions a root program can take.

Why root inclusion requires an independent audit

Root programs require CAs to pass a WebTrust or ETSI audit that verifies the CA's operational practices, key management procedures, and compliance with the program's policy requirements. This audit is conducted by an independent third party and must be renewed regularly. The CapyToolkit Certificate Inspector displays the root certificate's Subject and Issuer fields, which identify the CA by name and let you cross-reference the root against the CA's published root list.

How root updates propagate through software updates

Browsers and operating systems distribute root certificate updates through their regular software update channels. This means a newly added root takes time to reach all devices, and a distrusted root persists on devices that have not received the update. The CapyToolkit Certificate Inspector identifies self-signed certificates with the ROOT CERTIFICATE · self-signed label, but it cannot determine whether a given root is publicly trusted, because that depends on whether its fingerprint matches any entry in the browser's trust store.

For day-to-day operations, the useful check is whether the root you deployed is the one clients actually trust. A certificate can be technically valid and perfectly chained yet still trigger warnings if the leaf or an intermediate was signed by a root that a particular client's trust store does not contain. The CapyToolkit Certificate Inspector parses the chain and labels the root, so comparing that label against the root program list your clients use is the fastest way to find a trust gap before users report it.

Root CA certificate fields and security characteristics

Root CA certificates share the X.509 structure but differ from leaf and intermediate certificates in several key ways. The Basic Constraints extension has the CA flag set to true and typically no pathLenConstraint, allowing the root to sign intermediates at any depth. The Key Usage extension includes Certificate Sign and CRL Sign. Validity periods for root CAs are typically ten to thirty years, far longer than intermediate or leaf certificates, which means a root certificate created today may still be in use well into the 2040s.⁴ Furthermore, root CA certificates often use RSA 4096-bit or ECDSA P-384 keys rather than the RSA 2048-bit baseline, reflecting the long lifetime and the asymmetric importance of protecting the root key.⁵ Inspecting a root CA certificate in the CapyToolkit Certificate Inspector shows all of these fields alongside the ROOT CERTIFICATE · self-signed label.

Why root CAs use stronger keys than leaf certificates

Root CA certificates often use RSA 4096-bit or ECDSA P-384 keys, which provide a larger security margin than the RSA 2048-bit baseline used for leaf certificates. This reflects the long lifetime of root certificates and the asymmetric importance of protecting the root key: a root key compromise undermines every certificate that chains to it. The CapyToolkit Certificate Inspector displays the key algorithm and bit length in the General section, so you can verify that root certificates in your inventory use appropriate key strength.

How validity periods shape root CA operational planning

Root CA validity periods of ten to thirty years mean that a root certificate created today may still be in use well into the 2040s. This long lifetime requires CAs to plan for key rotation and cross-signing well in advance of expiry, because replacing a root that is embedded in billions of devices is a multi-year process. The CapyToolkit Certificate Inspector shows the notAfter date for every certificate in the chain, giving you the exact deadline for planning root transitions.

Private versus public root CAs

Not all root CA certificates belong to public trust programs. Organizations run private root CAs to issue certificates for internal services, VPN authentication, and device management without exposing internal infrastructure to public CAs. A private root certificate is distributed to devices through mobile device management, group policy, or manual installation rather than through an OS trust store update. Conversely, a certificate chaining to a private root is not trusted on any device that has not explicitly installed that root. The Certificate Inspector identifies self-signed certificates with the ROOT CERTIFICATE · self-signed label; whether the root is publicly trusted depends on whether its fingerprint matches any entry in the browser's trust store, information the inspector cannot determine from the certificate bytes alone.

Cross-signed root certificates and backward compatibility

Cross-signing allows a new root CA's public key to be trusted by older devices that have not yet received the new root in their trust store. In a cross-signed arrangement, an already-trusted CA signs the new root CA's public key as an intermediate certificate, creating a longer chain that terminates at the older trusted root instead of the new one. Consequently, clients with the old root in their store can validate the chain through the cross-signature even before the new root is distributed. Let's Encrypt used this approach during its early years, cross-signing with IdenTrust's DST Root CA X3 to ensure broad trust before ISRG Root X1 gained universal inclusion in device trust stores.⁵ Building on this, cross-signing is a deliberate operational decision that CAs make to smooth root transitions without disrupting existing clients.

Why cross-signing is necessary for new root inclusion

When a new root CA is created, it is not immediately trusted by any device because it has not yet been added to any trust store. Cross-signing solves this by having an already-trusted CA sign the new root's public key as an intermediate certificate. Clients that trust the old root can then validate the chain through the cross-signature, even though they do not yet trust the new root directly. The CapyToolkit Certificate Inspector shows the full chain including cross-signed intermediates, so you can see which root the chain terminates at.

How Let's Encrypt used cross-signing during its early years

Let's Encrypt cross-signed its ISRG Root X1 with IdenTrust's DST Root CA X3, which was already widely trusted in device trust stores. This allowed Let's Encrypt certificates to be trusted by older devices that had not yet received ISRG Root X1 in their trust store updates. As ISRG Root X1 gained universal inclusion, the cross-signature became unnecessary and Let's Encrypt eventually retired it. The CapyToolkit Certificate Inspector displays the chain structure so you can see whether a certificate relies on a cross-signature for trust.

Try in the tool

Subject Alternative Name (SAN)

Subject Alternative Names are the extension that tells TLS clients which hostnames, IP addresses, and email addresses a certificate authenticates. Every modern TLS certificate uses SANs rather than the Common Name field for domain validation; RFC 6125 establishes that when a SAN extension is present, clients must use the SANs and must not fall back to the CN for hostname matching¹. Consequently, a certificate that lists only a domain name in the CN field without a SAN extension fails hostname verification in all current browsers and TLS libraries, even though older clients accepted CN-only matching for many years². The CapyToolkit Certificate Inspector shows every SAN entry in the Extensions section of the certificate card, with the full list copyable in a single click when the certificate covers more than five names.

What is SAN?

SAN types and what each one authenticates

RFC 5280 defines several GeneralName types for SAN entries, of which three are common in TLS certificates³. The dNSName type covers hostnames: www.example.com or a wildcard like *.example.com. The iPAddress type covers IP addresses in binary form, so a TLS client connecting to an IP address rather than a hostname matches the certificate only if that IP appears as an iPAddress SAN. The rfc822Name type covers email addresses, used in S/MIME certificates for email signing. Furthermore, some certificates use the URI type for specific application protocols such as SPIFFE workload identity in service mesh environments. Understanding these type distinctions is essential when auditing a certificate, because each type triggers a different verification path in the TLS client and mixing them incorrectly can cause hostname validation to fail even when the certificate technically covers the intended identity.

How the common SAN types differ in practice

Each GeneralName type serves a distinct verification path, and understanding the differences helps you audit which identities a certificate actually authorizes. A dNSName entry supports exact hostnames as well as wildcard forms, where the asterisk matches any single label, so *.example.com covers both api.example.com and www.example.com but not api.v2.example.com. By contrast, an iPAddress entry requires clients to connect directly to that IP without any hostname resolution, which is common in internal microservice networks where DNS is bypassed. The rfc822Name type rarely appears in TLS server certificates because web browsers do not perform email-domain matching during HTTPS handshakes.

When multi-domain certificates make operational sense

Building on this, multi-domain certificates list multiple dNSName entries to cover a family of related hostnames on a single certificate, reducing the number of certificates to manage across your infrastructure. This approach works well when the same team controls all the listed domains and the private key can be stored in a single secure location. The trade-off is that every additional name expands the attack surface of a single key compromise, so you should only group domains that share the same security posture and renewal cycle.

A good audit habit is to compare the SAN list against the domains you actually operate rather than assume it matches your inventory. Extra names widen the blast radius of a key compromise and can leak internal hostnames you never intended to expose. The CapyToolkit Certificate Inspector lists every SAN entry and flags wildcards separately, so a quick pass catches both missing hostnames and names that should not be on a public certificate.

Why CN matching was deprecated for hostnames

For much of TLS history, clients matched the server hostname against the Common Name field in the Subject distinguished name. This worked when certificates covered only a single domain, but it provided no standard mechanism for multi-domain coverage. The SAN extension, defined in RFC 5280, addressed this by allowing multiple hostnames in one field. RFC 6125, published in 2011, formalized the rule that clients must prefer the SAN extension over the CN when both are present, and that CN matching is only acceptable as a fallback when no SAN extension exists.

Why CN-only certificates broke the multi-domain case

Before SANs became widespread, a certificate could only carry one hostname in its CN field, which meant every additional domain required its own certificate and its own private key. That approach scaled poorly: each new domain added configuration overhead on web servers, increased the number of expiring certificates to track, and multiplied the number of keys that could leak. The SAN extension solved this by making the list of authorized hostnames a first-class part of the certificate rather than an afterthought squeezed into the Subject DN.

How modern clients treat the CN field today

Consequently, modern clients no longer accept CN-only matching at all. Certificates issued today by publicly trusted CAs include at least one dNSName SAN, and the CN field in the Subject is sometimes just a copy of the primary domain for human readability rather than for machine hostname verification. Some CAs now omit the CN entirely in favor of a clean SAN-only structure, which removes any ambiguity about which field drives verification.

Inspecting and auditing SAN entries

Reviewing SAN entries matters for both security and operational correctness. When a certificate covers more domains than necessary, such as including a staging subdomain alongside production domains, a compromise of the private key exposes all covered names. Conversely, a certificate that omits a domain your service needs to authenticate causes hostname mismatch errors for those clients. The CapyToolkit Certificate Inspector shows all SAN entries in the Extensions section. For certificates with more than five SANs, the inspector shows a summary count and a Copy all button, letting you export the full list to your clipboard for comparison with your expected domain inventory. Furthermore, wildcard SANs are flagged separately with the WILDCARD SAN badge at the top of the certificate card, making them immediately visible during an audit without reading through all the extension fields.

Maximum SAN counts and certificate size impact

The X.509 standard and RFC 5280 impose no limit on the number of SAN entries in a certificate. Practical limits are set by Certificate Authorities: Let's Encrypt allows up to 100 SANs per certificate⁴, which is sufficient for most multi-tenant services. Very large SAN lists increase certificate size, which slightly increases TLS handshake overhead due to larger Certificate message payloads⁵. Yet for most deployments, this overhead is negligible compared to the operational benefit of consolidating many hostnames into fewer certificates.

How CA rate limits interact with large SAN counts

Building on this, the practical constraint on SAN count is rarely the protocol itself but rather the CA's rate-limit policy and renewal automation. Let's Encrypt's 100-certificate-per-domain weekly limit and 100-SAN-per-certificate cap mean a single certificate can cover a substantial fleet of related hostnames without triggering duplicate-rate-limit penalties, as long as the set of names stays stable across renewals. When the list of names changes frequently, however, each modification consumes a new issuance and brings you closer to the weekly cap.

Why SAN count affects handshake performance only slightly

The size of the Certificate message grows roughly linearly with the number of SAN entries, but each DNS name adds only a few dozen bytes, so even 50 entries add less than 2 KB to the handshake. For servers handling thousands of connections per second, that extra payload can add measurable CPU cost on TLS termination, but for typical web services and APIs the difference is dwarfed by the latency of the underlying network. Building on this, the CapyToolkit Certificate Inspector displays all SANs for any certificate you paste or fetch, regardless of the count, so you can audit even certificates with dozens of entries in a single structured view without scrolling through raw openssl output.

Try in the tool

Certificate Transparency Log

Certificate Transparency logs are append-only, publicly auditable records of every publicly trusted TLS certificate ever issued. RFC 6962 defines the Certificate Transparency protocol; under it, CAs must submit each certificate to one or more CT logs before issuance, and the log returns a Signed Certificate Timestamp that the CA embeds in the certificate or delivers during the TLS handshake.¹ Browsers enforce CT compliance: Chrome requires at least two SCTs from distinct log operators for any certificate it trusts.² Consequently, a certificate issued without CT compliance fails in Chrome even when the CA is otherwise trusted by the browser. CT enables domain owners and security researchers to discover unauthorized certificates issued for their domains by monitoring public logs, turning certificate issuance into a transparent, auditable process rather than an opaque one.

What is CT Log?

How SCTs are delivered and verified

Signed Certificate Timestamps reach TLS clients through three mechanisms, all defined in RFC 6962. The most common is embedding: the CA includes one or more SCTs directly in the certificate's X.509 extension before signing the certificate. Because the SCT is part of the certificate bytes, it arrives automatically during the TLS handshake with no additional infrastructure required on the server. The second mechanism is TLS extension delivery: the server includes SCTs in the ServerHello TLS extension during the handshake without embedding them in the certificate itself. The third mechanism, OCSP stapling with SCTs, was supported in older Chrome versions but has since been deprecated by Google's CT policy.

Why embedding is the dominant delivery method

Consequently, most modern TLS certificates use embedded SCTs, which makes them visible in certificate inspection tools including the CapyToolkit Certificate Inspector under the Extensions section.¹ Embedding survives server reconfiguration and certificate renewal without manual intervention, because the SCT travels with the certificate rather than depending on a correct TLS extension configuration. By contrast, TLS extension delivery requires the server operator to maintain a separate SCT provisioning pipeline, which adds operational complexity and breaks when the pipeline fails silently.

How to verify an SCT against its log key

Verifying an SCT requires the public key of the CT log that produced it, which operators publish in their log metadata. A client reconstructs the signed data from the certificate and the timestamp, then verifies the log's signature over that data. This verification confirms the log operator genuinely promised inclusion, and any mismatch between the SCT's log identifier and the known log key indicates a forged or misattributed timestamp that should cause the client to reject the certificate.

For practical monitoring, an SCT in the certificate is only useful if you actually watch the logs for your domains. Subscribing to a CT alerting service turns the log into an early-warning system that flags any certificate a CA issues for your name, whether or not you requested it. The CapyToolkit Certificate Inspector surfaces embedded SCTs in the Extensions section, so you can confirm at inspection time that a certificate carries the transparency proof browsers now require.

Using CT logs to monitor for unauthorized certificates

CT transparency gives domain owners a practical tool for detecting unauthorized certificate issuance. Every publicly trusted CA must submit certificates to CT logs before or shortly after issuance; the Maximum Merge Delay under RFC 6962 is typically 24 hours for production logs.⁴ Security teams can subscribe to CT monitoring services that alert them whenever a new certificate for their domain appears in a log. Furthermore, tools like crt.sh provide searchable interfaces over CT log data, making it possible to audit all certificates ever issued for a domain, including historical ones that have since expired. Building on this, a certificate issued by a compromised or rogue CA will appear in CT logs, giving domain owners a window to revoke the certificate and rotate to a new key before the attacker deploys it in an active attack.

CT requirements and when they do not apply

CT requirements apply to publicly trusted TLS certificates, meaning certificates that chain to a root in browser and OS trust stores. Internal certificates issued by a private CA are not subject to CT requirements and are not submitted to public CT logs. Self-signed certificates also do not appear in CT logs. Consequently, when the Certificate Inspector shows a certificate without SCT extensions, the certificate may be a legitimately private certificate rather than a suspicious one.

How to tell a private certificate from a CT violation

The distinction matters during a security audit: a missing SCT on a certificate served over the public internet from a publicly trusted CA is a genuine anomaly, while a missing SCT on an internal service certificate is expected and normal behavior. To classify a certificate correctly, check whether its chain roots in a public trust store and whether the subject matches an internal hostname or IP range. If the certificate chains to a public root but lacks SCTs, treat it as a compliance failure that needs immediate remediation. If it chains to a private root, the absence of SCTs is by design.

Why private CAs should still consider voluntary CT logging

Even though private CA certificates are exempt from browser CT requirements, some organizations choose to log them to public CT logs voluntarily. This practice gives the organization the same monitoring benefits that public-domain owners enjoy, including early detection of unauthorized issuance from a compromised internal CA. Voluntary logging also prepares the organization for a future where browser policies may extend CT requirements to private PKI, as several browser vendors have discussed in public forums.

Certificate Transparency Version 2 (RFC 9162)

RFC 9162, published in 2022, defines Certificate Transparency Version 2, which addresses limitations in the original RFC 6962 design.³ CT Version 2 introduces improved cryptographic agility, allowing CT logs to use hash algorithms beyond SHA-256 and signature algorithms beyond those required by the original specification. Building on this, CT v2 also improves the mechanism for clients to verify SCTs and introduces a more flexible log discovery mechanism.

What changes CT v2 introduces over CT v1

The most significant improvement in CT v2 is cryptographic agility, meaning logs are no longer bound to a single hash function and signature scheme. Under RFC 6962, every log used SHA-256 and a fixed signature algorithm, which made the entire CT ecosystem vulnerable to a future cryptanalytic break of SHA-256. CT v2 allows logs to advertise multiple hash algorithms and signature schemes simultaneously, so clients can verify SCTs using whichever algorithm they trust most while older clients still verify the legacy representation.

Why the transition to CT v2 is proceeding gradually

Yet RFC 6962 CT logs remain the operational standard as of mid-2026, and all production certificate SCTs you encounter in the Certificate Inspector will reference RFC 6962 CT log IDs rather than CT v2 log IDs.⁵ The transition to CT v2 is a gradual process that proceeds as log operators upgrade their infrastructure and browsers update their CT enforcement policies. Each log operator must run parallel CT v1 and CT v2 trees during the transition, which doubles their operational cost, so most operators wait until browser policies require CT v2 before committing resources to the migration.

Try in the tool

Certificate SHA-256 Fingerprint

A certificate fingerprint is the cryptographic digest of the complete DER-encoded certificate, used as a compact, unambiguous identifier. SHA-256 fingerprints are the current standard for certificate identity: each fingerprint is a 256-bit hash value, typically displayed as 64 hexadecimal characters or 32 colon-separated byte pairs.¹ Because SHA-256 is a one-way function, two certificates with different content always produce different fingerprints, making the fingerprint a reliable out-of-band identifier for certificate pinning, audit trails, and manual verification. The CapyToolkit Certificate Inspector displays the SHA-256 fingerprint prominently in the General section of each certificate card, with a Copy button that puts the value in the clipboard for immediate use in configuration files or incident reports.

What is SHA-256?

How fingerprints uniquely identify certificates

Certificate fingerprints serve as compact, collision-resistant identifiers because SHA-256 produces a unique digest for each distinct input. Any change to the certificate content, even a change as small as a single bit, produces a completely different fingerprint. This property makes it impossible to accidentally confuse two different certificates that share the same subject name, because their fingerprints will differ no matter how similar the content looks. Consequently, fingerprints are the preferred identifier when you need to confirm that a specific certificate is deployed, not just any certificate for the right domain. During a security incident, comparing the fingerprint of a deployed certificate against the fingerprint in your certificate inventory confirms whether the correct certificate is in place. Furthermore, fingerprints are used in application configurations when you need to pin trust to a specific certificate rather than to any certificate from a trusted CA.

SHA-256 versus SHA-1 fingerprints

SHA-1 fingerprints were the original standard for certificate identification, but SHA-1 has been cryptographically broken since 2017 when researchers demonstrated a practical collision.³ NIST deprecated SHA-1 for digital signatures and digital signature applications.⁴ SHA-256 is now universally preferred: it produces a 256-bit digest compared to SHA-1's 160-bit output, providing a substantially larger collision-resistance margin.⁵

How SHA-1 broke and why SHA-256 replaced it

The SHA-1 collision attack, dubbed SHAttered, demonstrated that an attacker could craft two distinct inputs with the same SHA-1 digest. For certificate security, this means a rogue CA could potentially create a benign certificate and a malicious certificate with identical SHA-1 fingerprints, undermining any pinning or identification that relies on the hash. SHA-256 resists known practical collision attacks as of 2026, and its larger digest size provides a meaningful security margin even if future cryptanalysis weakens the algorithm.

What the inspector displays and why SHA-1 signatures are flagged separately

Building on this, the CapyToolkit Certificate Inspector displays only the SHA-256 fingerprint, consistent with current security practice. If a certificate's signature algorithm uses SHA-1 (separate from the fingerprint), the inspector flags it with a SHA-1 SIGNATURE badge, which is a different issue. The CA signed the certificate using the broken SHA-1 algorithm, and this is not a question of how you compute the fingerprint of the certificate bytes.

Using fingerprints for certificate verification and pinning

Verifying a certificate by its fingerprint is a practical step whenever you receive a certificate through an untrusted channel, such as a colleague sending a PEM file by chat or email. Compute the SHA-256 fingerprint of the received certificate and compare it against a fingerprint you obtained through a separate, trusted channel such as a vendor's documentation, an official changelog, or a direct conversation. If they match, the certificate has not been altered in transit. For application-level certificate pinning, store the expected SHA-256 fingerprint in your application configuration and compare it against the fingerprint of the certificate the TLS library presents during each connection. Yet certificate pinning requires careful operational discipline: you must update the pinned fingerprint every time you replace the certificate, including on short-lived renewal cycles, or your application will refuse to connect to the renewed certificate.

Certificate fingerprints in monitoring and audit workflows

Fingerprints appear throughout certificate monitoring and audit workflows because they provide a stable, human-verifiable identity for any certificate. When your monitoring system alerts on a certificate change, comparing the old and new fingerprints confirms whether the change is an expected renewal or an unexpected replacement. Furthermore, security audit logs that record the fingerprints of certificates presented to API clients create a tamper-evident record: if an attacker substitutes a certificate, the fingerprint in the log will not match the fingerprint of the certificate you authorized.

How fingerprints strengthen monitoring alerts

Building on this, certificate inventory tools typically index certificates by their SHA-256 fingerprint alongside the subject domain, because domains may have multiple certificates in rotation simultaneously and the fingerprint is the unambiguous key that distinguishes them. A monitoring system that records the fingerprint alongside the alert timestamp gives you a precise audit trail: you can see not only that a certificate changed but exactly which certificate replaced it, even when two certificates cover the same domain.

Why fingerprints matter in post-incident forensics

After a security incident, fingerprints let you reconstruct which certificates were presented during the affected window. By comparing the fingerprints recorded in your logs against the fingerprints of certificates you authorized, you can identify any unauthorized substitution, even if the attacker obtained a valid certificate from a trusted CA for the same domain. This detection works because the attacker cannot forge a certificate with the same SHA-256 fingerprint as your legitimate certificate, so any mismatch in the log is evidence of tampering.

For routine auditing, the simplest use is to record the fingerprint whenever a certificate is deployed and compare it on the next change. A renewal that keeps the same key produces a new fingerprint because the validity window changes, so expect the value to differ even on a normal rotation. The CapyToolkit Certificate Inspector displays the SHA-256 fingerprint in the General section, so you can copy it straight into your inventory or monitoring config without recomputing it by hand.

Try in the tool

RSA vs ECDSA Certificate Keys

RSA and ECDSA are the two dominant public key algorithms for TLS certificates, and choosing between them involves trade-offs in key size, handshake performance, compatibility, and operational complexity. RSA (Rivest-Shamir-Adleman) has been the default for over three decades; RSA 2048 is the current practical minimum for publicly trusted certificates, per the CA/Browser Forum Baseline Requirements.¹ ECDSA (Elliptic Curve Digital Signature Algorithm) uses elliptic curve mathematics to achieve equivalent security with dramatically smaller keys: a P-256 ECDSA key provides approximately 128 bits of security compared to RSA 2048's 112 bits, per NIST SP 800-57.² Consequently, ECDSA reduces TLS handshake payload size and speeds up signature generation. Yet RSA retains broader legacy client compatibility, making it the safer choice for environments that must support older devices and software.

What is RSA/ECDSA?

Key size and security strength compared

Security strength in asymmetric cryptography is measured in bits of equivalent symmetric key strength. RSA 2048-bit keys provide approximately 112 bits of security, meaning breaking the key requires roughly the same computational effort as exhaustively searching a 112-bit symmetric key space. ECDSA P-256 provides approximately 128 bits of security in a key that is 256 bits long, compared to RSA's 2048 bits for a weaker security level. Consequently, ECDSA achieves stronger security with a smaller key.

How key size translates to certificate and handshake size

The practical result is smaller certificates, faster signature generation, and smaller TLS handshake messages. An RSA 2048-bit public key alone occupies roughly 294 bytes in DER encoding, while an ECDSA P-256 public key occupies only 65 bytes before point compression. That difference compounds across the entire certificate structure, so an ECDSA certificate is typically 30 to 40 percent smaller than an RSA certificate at equivalent security strength.

Why RSA retains an edge in client compatibility

Yet RSA's advantage is its universal support: every TLS library and every CA issuing public certificates supports RSA 2048, while ECDSA support has been standard only since TLS 1.2 became universal around 2015. Some embedded devices, older Java runtimes, and legacy enterprise clients still lack ECDSA support, which makes RSA the safer choice when you cannot control the client software stack.

The right choice usually comes down to who connects to you. If every client is a current browser or a modern library, ECDSA pays off in smaller certificates and quicker handshakes across a busy fleet. When the client mix includes older appliances or custom runtimes, RSA avoids support tickets you cannot easily diagnose. The CapyToolkit Certificate Inspector shows the algorithm and key size for each certificate, so you can confirm the deployed choice matches the audience you actually serve.

Handshake performance and certificate size

ECDSA certificates are smaller than RSA certificates for equivalent or greater security strength. A P-256 ECDSA certificate is typically 800 to 900 bytes; an RSA 2048-bit certificate is typically 1200 to 1400 bytes. The difference matters for TLS handshake performance: smaller certificates fit more easily within a single TCP segment, reducing round-trip latency on high-latency connections. Signature operation speed also differs: ECDSA P-256 signature generation is faster than RSA 2048 signing, but RSA 2048 signature verification is faster than ECDSA P-256 verification on modern hardware, which matters for servers that verify many client certificates or tokens.⁵ Yet RSA encryption is typically faster than ECDSA for operations where the public key encrypts data directly, though modern TLS uses forward-secret ephemeral key exchange rather than RSA encryption for session keys, so this asymmetry is less relevant for TLS performance in practice.

Choosing between RSA and ECDSA for your use case

For new deployments where all clients run modern operating systems and browsers (post-2015), ECDSA P-256 is the better default. It delivers stronger security, smaller certificate size, and faster handshakes. For environments that must support older embedded systems, IoT devices, or legacy enterprise software that predates ECDSA support in TLS, RSA 2048 ensures compatibility.

How to decide between compatibility and performance

Furthermore, some CAs and hosting providers may only issue one algorithm type; verify that your CA supports the algorithm you want before designing your certificate management system around it. A practical approach is to issue both an RSA and an ECDSA certificate for the same domain and configure your web server to negotiate the algorithm based on client capabilities, giving modern clients the performance benefit of ECDSA while preserving access for older clients.

What the inspector reveals about algorithm and key size

Cloudflare's CSR tooling offers p256v1 as a NIST P-256 option alongside the default RSA 2048-bit key, reflecting the practical availability of both algorithms from a major infrastructure provider. The CapyToolkit Certificate Inspector displays the algorithm and key size for every certificate in the chain, so you can verify at a glance whether your deployment matches your intended algorithm choice and spot any unexpected downgrade to RSA in a fleet that should be running ECDSA.

Post-quantum cryptography and algorithm migration planning

Neither RSA nor ECDSA is resistant to attacks from sufficiently capable quantum computers. Shor's algorithm can solve both the integer factorization problem underlying RSA and the discrete logarithm problem underlying ECDSA in polynomial time on a sufficiently large quantum computer. NIST's post-quantum cryptography standardization process finalized algorithms including ML-KEM and ML-DSA in 2024 as replacements.⁶ Consequently, both RSA and ECDSA certificate deployments will require migration as quantum-resistant algorithms are adopted by CAs and browsers over the coming years. Building on this, knowing which algorithm each certificate in your inventory uses today, available instantly from the CapyToolkit Certificate Inspector, is the starting point for planning a migration to post-quantum algorithms when that transition becomes operationally necessary.

Try in the tool