Our Certificate Policy (CP) Checker evaluates SSL/TLS certificates against established policy standards including CAB Forum Baseline Requirements, WebTrust, and ETSI. Enter any domain to verify that its certificate's policy identifiers, key usage, extended key usage, and other attributes comply with industry requirements.
How to Use
1Enter the domain name whose certificate policy you want to check.
2Click Run to analyze the certificate's policy compliance.
3Review compliance results showing policy identifiers, key usage, and industry standard adherence.
Use Cases
•Verify certificates meet CAB Forum Baseline Requirements for browser trust
•Check certificate policy identifiers match expected assurance levels
•Audit certificate compliance for regulatory and industry standards
Frequently Asked Questions
A Certificate Policy (CP) defines the rules and procedures for issuing and managing certificates under a specific policy. It covers certificate enrollment, validation, issuance, revocation, and renewal procedures.
Non-compliant certificates may not be trusted by browsers and operating systems. Policy compliance ensures your certificates are recognized as valid and trustworthy by all major platforms and applications.
The checker validates against CAB Forum Baseline Requirements, WebTrust for CAs, ETSI EN 319 411 standards, and RFC 5280 for X.509 certificate profiles and policy identifier formats.
It is three parts added together: 30 points for serving a certificate over a real connection, 30 for sending a Strict-Transport-Security header, and a 40-point base for being reachable at all. A score of 100 means all three held. Anything lower tells you which part failed, and the details line next to the score names it directly rather than leaving you to guess.
Because the 40 is the base for a host that was attempted, not a verdict that anything passed. When the connection itself fails there is no certificate to confirm and no page to fetch a header from, so both 30-point parts stay at zero. Treat a bare 40 as a connectivity finding: check the hostname, the port and whether anything is listening before reading anything into the policy side.
No, and that is deliberate rather than an omission. CAA lives in DNS, not in the TLS handshake, so checking it needs a DNS lookup rather than a connection, and it has its own dedicated checker on this site. If an audit asks about CAA, run that page. A policy page that claimed to check DNS records it never fetched would be inventing results.
Because the other half of the score is the certificate side. The header check fetches your front page, which can succeed while the TLS side fails, for example when the handshake breaks for some clients or no certificate is served on the tested port. Read the details line: if it confirms the header but not the certificate, the work is on the TLS configuration, not on the header you already set.
Send the Strict-Transport-Security header on every HTTPS response, starting with a short max-age while you confirm nothing breaks, then raise it and add includeSubDomains once all subdomains serve HTTPS. Preload submission comes last and is effectively irreversible, so only request it when you are certain. Re-run this check after each step, since each one is exactly what one part of the score looks for.
What the Policy Check Measures
A certificate can be perfectly valid while the deployment around it is not. This check looks past the certificate at two things organisations get asked about in audits: whether the server actually serves a certificate over a real connection, and whether it sends the HSTS header that keeps browsers on HTTPS.
1Open a real TLS connection to the host and confirm a certificate is served. This is the part of the score worth 30 points, and it fails when the port is closed or the handshake itself breaks.
2Fetch the site's front page over HTTPS and read the Strict-Transport-Security response header. A present header is worth the other 30 points; an absent one is the most common finding on this page.
3Add the 40-point base for a reachable host, giving a maximum of 100. A host that cannot be reached at all still shows 40, which is why a middling score with a connection note means the network failed, not the policy.
Two things this check does not probe are CAA records and the wider security-header set. CAA has its own dedicated checker on this site, and headers beyond HSTS belong to the header analyzer. Keeping each check to what it actually fetches is what keeps the results honest.
Tips & Best Practices
•Review Certificate Policy documents for CA evaluation
•Understand certificate lifecycle requirements from CP documents
•Compare CP documents across CAs for selection decisions
•Keep CP documentation for compliance audit evidence
