Cert Policy Decoder

Decode certificate policy identifier extensions

About Certificate Policy Extensions

Certificate policy extensions define the policies under which a certificate was issued and how it should be validated. These extensions include Certificate Policy (CP) identifiers, Certification Practice Statement (CPS) URIs, and policy mappings. Our Cert Policy Decoder retrieves and parses these extensions from any TLS certificate, making it easy to understand the issuance policies and practices behind a certificate.

How to Use

Enter the domain name whose certificate policies you want to decode.
Adjust the port number if needed (default is 443).
Click Check to fetch and decode the certificate policy extensions.
Review the decoded policy OIDs, descriptions, CPS URIs, and any policy mappings.

Use Cases

Compliance Verification: Verify that a certificate's policies match your organization's requirements.
CA Due Diligence: Examine the certification practices of a Certificate Authority before trusting their certificates.
Certificate Research: Study the policy extensions used by different CAs and certificate profiles.
Security Auditing: Include policy validation in your certificate chain audit workflow.

Frequently Asked Questions

A Certificate Policy OID (Object Identifier) is a unique identifier that references a specific set of rules under which a certificate was issued. Each CA defines their own policies, and the OID helps relying parties look up the corresponding Certification Practice Statement.

A CPS (Certification Practice Statement) URI is a link to the document that describes the CA's practices for issuing, managing, and revoking certificates. It provides transparency into the operational procedures of the Certificate Authority.

Policy extensions help relying parties determine if a certificate is suitable for a particular purpose. For example, code signing certificates have different policy requirements than SSL/TLS server certificates. Decoding these policies helps ensure certificates are used appropriately.

How thoroughly the issuer checked the applicant's right to the name. Domain validation confirms control of a domain and nothing more. Organisation validation additionally confirms the organisation's legal existence and that it is entitled to the domain. Extended validation adds verification against official records, and is the basis of the organisation and country fields in the browser's address bar. Each level is a distinct identifier in the policy extension.

Because it is the CA/Browser Forum's registered identifier for organisation-validated certificates. Policy identifiers are OIDs, so nothing readable appears in the certificate itself until something resolves them — which is what this page does. Auditors read that resolved name to establish the assurance level actually claimed, rather than inferring it from the subject fields alone.

In the qualifiers, most often as a pointer to the CA's Certification Practice Statement. That document states what the issuer actually does: how it validates, how long certificates live, how revocation works. This page surfaces the pointer; the CPS page on this site explains what to read once you have it, since the document itself is prose no checker can grade.

Yes, and authorities routinely issue several — a public TLS policy plus an internal one, or multiple levels for the same key. Each is listed separately with its own qualifiers. When reading them, the most specific policy matching the intended use is what governs, so a certificate listing both an OV and an EV policy should be read according to how it was issued, not assumed to be the higher one.

Both are reported rather than smoothed over. A certificate with no policy extension is unusual for a publicly trusted one, and an identifier with no known mapping could be a private policy or something newer than the mapping. In either case the honest answer is unknown — inferring a familiar policy name would be worse than useless when an auditor is checking what was actually claimed.

What the Decoder Reads

Certificate policies are the rules an issuer works under, encoded in the certificate under numeric identifiers. This page resolves those identifiers into the names they represent.

1Read the policy extension and map each object identifier to its human-readable policy name. Those names carry real meaning: a branch-validated organisation policy is a materially higher assurance than domain validation, and the difference is exactly what auditors and users care about.
2Read the qualifiers, which say where the full policy text lives — usually a CPS URI, sometimes a user notice. That pointer is the link between the certificate and the legal document that governs it.
3Read basic constraints too, including whether the certificate may act as a CA and any path-length limit. That belongs alongside the policy because both constrain what the certificate is permitted to do.

An identifier with no mapping is reported as unrecognised rather than guessed at, since a fabricated policy name in a compliance context is worse than an honest gap.

Tips & Best Practices

•Focus on validation procedures and liability terms when evaluating CAs
•Compare CP/CPS summaries across CAs to make informed decisions
•Check for recent updates to CP/CPS documents as they reflect current practices
•Keep decoded summaries for compliance audit evidence

Technical Details

Documents: Certificate Policy (CP) and Certification Practice Statement (CPS)
Extracts: Validation procedures, key management, revocation policies, liability
Output: Plain-language summary with categorized findings
Formats: PDF, HTML, and plain text CP/CPS document formats