I'm curious what threshold is used for CAs to issue / deny issuance / revoke TLS certificates.

As far as I understand they are essentially identity guarantees, so if JunkCorp can't prove they are who they say they are, then they won't get a certificate. Or if JunkCorp's website is hacked, then perhaps their certificate will be revoked.

Are there other aspects that are taken into account? (illegal/malicious activities)

1 Answer 1


While each CA does have their own policies and procedures they follow regarding when to issue and revoke certificates, there is a common set of Baseline Requirements which all publicly trusted Certificate Authorities are required (by browser vendors) to follow.

The Baseline Requirements specify the following list of conditions under which a CA must revoke a certificate: Reasons for Revoking a Subscriber Certificate

The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:

  1. The Subscriber requests in writing that the CA revoke the Certificate;
  2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
  3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Sections 6.1.5 and 6.1.6;
  4. The CA obtains evidence that the Certificate was misused;
  5. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
  6. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);
  7. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
  8. The CA is made aware of a material change in the information contained in the Certificate;
  9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;
  10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
  11. The CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
  12. The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
  13. The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate;
  14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
  15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

Source: Version 1.4.9 of the CAB Baseline Requirements.

Be aware that these requirements only say when a CA must revoke a certificate. They do not restrict CAs from revoking certificates for reasons not in this list. Individual CAs may have their own policies which specify other conditions under which they may revoke a certificate.

As for when a CA will refuse to issue a certificate, that question is much more complicated to answer. The main reason why a CA would be required to refuse to issue a cert would be when the person or organization requesting the certificate cannot prove they are who they say they are. The details of what sort of identity proofs are required, and other conditions under which a CA must refuse to issue a certificate are, again, specified in the Baseline Requirements.

As far as I am aware, the Baseline Requirements do not require CAs to monitor whether the people or organizations they are issuing certs to are using them for illegal activities. Law enforcement is not within the scope of a CA's responsibilities.

  • OK thanks. I guess the down side of the push for TLS/HTTPS is that we get these websites labeled "Secure", and we are lulled into a sense of security, but that doesn't mean they belong to websites that are safe.
    – Jason S
    Sep 7, 2017 at 20:19
  • 1
    @JasonS Yes, that's why browser vendors are pushing to remove the "Secure" label from HTTPS sites and instead just mark all HTTP sites as "Not secure". chromium.org/Home/chromium-security/marking-http-as-non-secure
    – Ajedi32
    Sep 7, 2017 at 20:22
  • They should use a term like "Verified" instead.
    – Jason S
    Sep 7, 2017 at 21:28
  • Extended Validation, covered by a separate CABforum document, requires more robust proof of identity -- but still no proof of honesty or competence. See near-dupe security.stackexchange.com/questions/117087/… Sep 8, 2017 at 3:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .