Key Usage Decoder

Decode certificate key usage and extended key usage extensions

About Key Usage Extensions

Key Usage and Extended Key Usage are X.509 certificate extensions that define the cryptographic operations a certificate is authorized to perform. Key Usage specifies low-level operations like digital signatures and key encipherment, while Extended Key Usage defines higher-level purposes like server authentication, client authentication, or code signing. Our Key Usage Decoder fetches a server's certificate and displays both extensions in a human-readable format, helping you understand exactly what each certificate is allowed to do.

How to Use

Enter the domain name whose certificate key usage you want to decode.
Click Decode to fetch the certificate and parse its extensions.
Review the Key Usage and Extended Key Usage sections for permitted operations.
Check if the certificate is a CA certificate and its path length constraint.

Use Cases

Certificate Validation: Confirm that a certificate has the correct key usage extensions for its intended purpose.
Security Analysis: Identify certificates with overly permissive key usage that may pose security risks.
CA Certificate Review: Examine CA certificates to understand their issuing authority and path length constraints.
Compliance Checks: Verify that certificates meet organizational policies for key usage and extended key usage.

Frequently Asked Questions

Key Usage defines basic cryptographic operations like digitalSignature, keyEncipherment, and keyCertSign. Extended Key Usage defines more specific purposes like serverAuth (TLS web server), clientAuth (TLS client), and codeSigning. A certificate typically has both extensions to precisely define its allowed uses.

A typical TLS server certificate requires digitalSignature and keyEncipherment (or keyAgreement for ECDHE) in Key Usage, and serverAuth (1.3.6.1.5.5.7.3.1) in Extended Key Usage. Without these extensions, browsers may reject the connection as improperly configured.

Path length constraint is a property of CA certificates that limits how many intermediate CAs can exist below them in the certificate chain. A path length of 0 means the CA can only issue end-entity certificates, not subordinate CAs.

What a verifier will accept the key for. If a certificate declares only digital signature, using it for key encipherment should be rejected — the declaration is a promise the issuer makes about intent, and verifiers are meant to enforce it. In practice some systems check it strictly and others barely at all, so the practical value of getting it right is mostly in preventing a key from being used in a way its issuer did not authorise.

Different granularity and different history. Key usage is the older, finer-grained extension with individual bits for signature, encipherment, agreement and so on. Extended key usage is coarser and purpose-based, naming application roles like server authentication or code signing. A certificate can carry one, both or neither, and when both are present the more restrictive applies — which is why a mismatch between them is worth investigating.

The key is unconstrained: it may be used for anything. That is why a certificate without key usage is reported as a finding rather than a pass on some pages, because it signals either an unusual issuer or a manually constructed certificate. Modern public issuance sets the extensions by default, so absence usually points at a private CA that has not caught up rather than at anything malicious.

That the authority may sign end-entity certificates but no further intermediates beneath it. It exists to bound how far a compromised subordinate can be used to issue: a zero path length means compromising that authority gets you leaf certificates and nothing more. Higher values permit longer chains, which is why a path-length limit is one of the more useful constraints to check when assessing a private CA.

Technically yes if it carries both extended key usages, but good practice says no. Separating purposes means a compromise of the web-facing key does not hand an attacker the ability to sign software under your name. The platforms enforce what the certificate declares, so a mismatch is rejected — but the safer design is separate keys with separate certificates and separate access controls.

What The Extensions Declare

Key usage and extended key usage restrict what a certificate's key may be used for. This page decodes both and reports them as named booleans rather than raw bit strings.

1Decode key usage into its nine named bits — digital signature, key encipherment, key agreement, certificate signing, CRL signing and the rest. Each is reported present or absent, so a certificate usable only for signing is visible as such rather than as an opaque integer.
2Decode extended key usage, which restricts purpose more coarsely: server authentication, client authentication, code signing, email protection and so on. This is the extension that catches a TLS certificate being used where a different purpose is required.
3Read basic constraints for CA certificates, including any path-length limit, which caps how deep a chain may extend below that authority. A path-length of zero means it may sign leaves but no further intermediates.

Both counts are reported in the summary so an absent extension is distinguishable from one permitting everything. That difference decides whether a key is unconstrained or deliberately scoped.

Tips & Best Practices

•Configure appropriate key usage extensions for your certificate purpose
•Verify key usage matches your intended certificate application
•Use extended key usage for specific application requirements
•Monitor key usage compliance across your certificate infrastructure

Technical Details

Extensions: Key Usage and Extended Key Usage analysis
Purposes: Digital Signature, Key Encipherment, Code Signing, etc.
Validation: Key usage compatibility with certificate purpose
Output: Key usage assessment with recommendations