CA/Forbidden or Problematic Practices: Difference between revisions

From MozillaWiki
< CA
Jump to navigation Jump to search
 
(25 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Potentially problematic CA practices ==
This page contains comments about various CA practices that have been the subject of discussion in past CA evaluations. Some of these practices are addressed by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and are forbidden. They are listed here because they are things CAs often get wrong. Others, we do not necessarily consider security risks, but we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Additional practices may be addressed in future versions of the policy.


This page contains draft comments about various CA practices that have been the subject of discussion in past CA evaluations. In general these practices are not explicitly addressed by the [http://www.mozilla.org/projects/security/certs/policy Mozilla CA certificate policy], and we do not necessarily consider them security risks. However we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Some of these practices may be addressed in future versions of the policy.
== Forbidden Practices ==


=== Long-lived DV certificates ===
=== Long-lived Certificates ===


A domain-validated SSL certificate attests only to ownership and control of a domain name, and the owner of a domain name may have acquired it from others. It is therefore possible for the previous owner of the domain to have a still-valid DV certificate for the domain. If such a valid certificate (and associated private key) were to be used in conjunction with a DNS spoofing attack it would allow a malicious site to masquerade as a legitimate site and bypass the protection afforded by SSL.
Section 6.3.2 of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] states: "Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and '''MUST NOT have a Validity Period greater than 398 days'''."


Some CAs issue DV SSL certificates that have expiration times several years in the future. This increases the time during which the possibility of such an attack exists.
=== Non-Standard Email Address Prefixes for Domain Ownership Validation ===


'''Important:''' According to section 6 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla CA Certificate Inclusion Policy] CAs who issue long-lived SSL certs must "verify that all of the information that is included in SSL certificates remains current and correct at time intervals of thirty-nine months or less"
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] requires CAs to conform to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements (BRs)] in the issuance and management of publicly trusted TLS server certificates. This includes the BR restrictions on the use of email as a way of validating that the certificate subscriber owns or controls the domain name to be included in the certificate. CAs are expected to conform to BR section 3.2.2.4, which allows email to the "Domain Contact", defined as the "Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS
SOA record, or as obtained through direct contact with the Domain Name Registrar." (BR § 3.2.2.4.2); a selected whitelist of constructed addresses, which are limited to local-parts of "admin", "administrator", "webmaster", "hostmaster", and "postmaster" followed by the "at" sign ("@") and the domain name in question (read BR § 3.2.2.4.4 for specifics); or using email addresses found in DNS (BR § 3.2.2.4.13 and BR § 3.2.2.4.14).


=== Wildcard DV SSL certificates ===
A CA that authorizes certificate subscribers by contacting any other email addresses may be found non-compliant with Mozilla's Root Store Policy and in violation of the Baseline Requirements, and may have action taken against it. CAs are also reminded that Mozilla's Root Store Policy and the Baseline Requirements extend to any CA certificates that are technically capable of issuing TLS server certificates, and subordinate CAs that fail to follow these requirements put the root CA in jeopardy of removal from Mozilla's root store.


Some CAs issue domain-validated SSL certificates that can function as wildcard certificates, e.g., a certificate for *.example.com where the CA verifies only ownership and control of the example.com domain, and the certificate subscriber can then use the certificate with any site foo.example.com, bar.example.com, etc. This means that a subscriber could establish malicious SSL-protected web site that are deliberately named in imitation of legitimate sites, e.g., paypal.example.com, without knowledge of the CA. Concerns have been expressed that wildcard SSL certificates should not be issued except to subscribers whose actual identity has been validated with organizational validation (OV). (There are no EV wildcard certificates.)
=== Issuing End Entity Certificates Directly From Roots ===


=== Email Address Prefixes for DV Certs ===
This is forbidden by section 6.1.7 of the Baseline Requirements.
* '''DRAFT''' Re-Write under discussion in mozilla.dev.security.policy


[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] requires CAs to conform to the [[CA:BaselineRequirements|Baseline Requirements]] (BRs) in the issuance and management of publicly trusted SSL certificates. This includes the BR restrictions on the use of email as a way of validating that the certificate subscriber owns or controls the domain name to be included in the certificate. CAs are expected to conform to BR Section 11.1.1 (section 3.2.2.4 in BR version 1.3), which restricts the email addresses that may be used to authenticate the subscriber to information listed in the "registrant", "technical", or "administrative" WHOIS records and a selected whitelist of local addresses, which are limited to local-parts of "admin", "administrator", "webmaster", "hostmaster", and "postmaster".
=== Distributing Generated Private Keys in PKCS#12 Files ===


A CA that authorizes certificate subscribers by contacting any other email addresses is deemed to be non-compliant with Mozilla's CA Certificate Inclusion Policy and non-conforming to the Baseline Requirements, and may have action taken upon it as described in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla's CA Certificate Enforcement Policy]. CAs are also reminded that Mozilla's CA Certificate Policy and the Baseline Requirements extend to any certificates that are technically capable of issuing SSL certificates, and subordinate CAs that fail to follow these requirements reflect upon the issuing CA that certified it.
Section 5.2 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] states: "CA operators MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage, unless the certificate is being issued to the CA itself."


=== Delegation of Domain / Email validation to third parties ===
In other words, CAs must note generate key pairs for TLS server certificates, except for their own use (e.g. certificates for the test websites required by BR section 2.2). CAs may only generate the key pairs for S/MIME certificates. Distribution or transfer of S/MIME certificates in unprotected PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then:
 
* The storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal)
Domain and Email validation are core-requirements of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Policy] and should always be incorporated into the issuing CAs procedures whenever possible. Registration Authorities (RA) or other third parties performing such functions must provide attestations about their procedures and/or should be audited together with the issuing CA. The CA must demonstrate clear and efficient controls attesting the performance of its RAs. Delegation of domain/email validation to third parties should generally be avoided.
 
=== Issuing end entity certificates directly from roots ===
 
Some CAs issue end entity certificates directly from the root (i.e., signed using the root CA private key). This is not as secure as using an offline root and issuing certificates using a subordinate CA.
 
=== Allowing external entities to operate subordinate CAs ===
 
Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. This raises concerns relating to whether or not such external entities are audited in a manner equivalent to the root CA, as well as what legal and technical arrangements constrain the external entities.
 
Where a root from a CA signs an intermediate certificate used by an external CA to then sign subsidiary intermediate certificates or subscriber certificates, that situation needs to be disclosed.  That disclosure should include documentation of what requirements are imposed by the CA owning the root upon the operations of external CAs.  Further, the public audit report for the CA owning the root must indicate how and when the operations of the external CAs have been reviewed for compliance with those documented requirements.
 
You must provide a clear description of the subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with Mozilla's CA Certificate Policy requirements as per the [https://wiki.mozilla.org/CA:SubordinateCA_checklist Subordinate CA Checklist.]
 
=== Distributing generated private keys in PKCS#12 files ===
 
It is reported that some CAs generate the key pairs for their subscribers,
rather than having the subscribers generate their own key pairs, and once generated, those CAs distribute the private key, together with the issued public key certificate and its chain, to the subscriber in a PKCS#12 file.
The issues include:
* The user doesn't know or control who else possesses and can use his private key (decrypt his private messages or forge his signature), and
* The distribution channels used (e.g. unencrypted email) may not be adequately secured.
 
CAs must never generate the key pairs for signer or SSL certificates. CAs may only generate the key pairs for SMIME encryption certificates. Distribution or transfer of certificates in PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then
* The storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal)
* The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the storage.
* The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the storage.


=== Certificates referencing hostnames or private IP addresses ===
=== Certificates Referencing Local Names or Private IP Addresses ===


The standard model for SSL on the web assumes that an SSL certificate references a domain name that is resolvable using the public DNS infrastructure (e.g., "www.example.com") or an IP address that is reachable from the public Internet. However it is also possible to include in a certificate a hostname not resolvable through the public DNS (e.g., "home") or a private IP address (e.g., 192.168.1.101); for example, this might be done for a corporate intranet with SSL-enabled servers behind a firewall and employees who don't want to enter fully-qualified domain names.  
A Subject Alternative Name (SAN) with an internal or local name or with a reserved or private IP address is forbidden by section 7.1.4.2.1 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements].  


We consider this a problematic practice for a public CA because a subscriber who obtains a certificate of this type could in theory use it in contexts other than the one for which the certificate was obtained, and in particular could use it to help enable an SSL MITM attack on users in other organizations who are using the same hostname or IP address for their own SSL-enabled servers. (Depending on the hostnames and private IP addresses used, this vulnerability might also affect users of home networks with SSL-enabled home gateway devices.)
=== OCSP Responses Signed by a Certificate Under a Different Root ===


[http://www.globalsign.com/resources/white-paper-internal-server-names-ip-address-requirements.pdf Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses]
CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 6960, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.


[http://www.cabforum.org/documents.html CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates], BR 9.2.1 (section 7.1.4.2.1 in BR version 1.3): “As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName (SAN) extension or Subject Common Name field containing a Reserved IP Address or Internal Server Name, the CA shall notify the Applicant that the '''use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016'''. Also as of the Effective Date, the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with a SAN or Subject Common Name field containing a Reserved IP Address or Internal Server Name. As from 1 October 2016, CAs shall revoke all unexpired Certificates.”
RFC 6960, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.


It is also a problematic practice to issue a certificate with non resolvable DNS or private IP and resolvable DNS adresses together.
For a detailed explanation about why an OCSP responder should not use a self-signed OCSP responder certificate and depend on Trusted Responder Mode within the Firefox browser, see: [[CA:OCSP-TrustedResponder|Details about OCSP Trusted Responder Mode.]]


It is not standards compliant for printable ASCII representations of IP addresses to be placed in any certificate field that is intended to hold DNS names, including the subject common name and the DNSName field of the Subject Alternative Names extension. There is a place in a certificate specifically intended to be where IP (v4 or v6) addresses may be placed. It is in the Subject Alternative Names extension.  The SubjectAltNames extension has places for both additional DNS names and for IP addresses. The place for IP addresses takes them in binary form, not in printable ASCII (e.g. dotted decimal) form.  See {{bug|553754}}.
Please test your OCSP responder within the Firefox browser by enforcing OCSP as per our [[CA:Recommended_Practices#OCSP|CA Recommended Practices for OCSP.]]


=== Issuing SSL Certificates for Internal Domains ===
=== Issuance of SHA-1 Certificates ===


It has come to our attention that some Certification Authorities may have mistakenly issued SSL certificates to non-existent .int domain names. This appears to have happened because the .int domain may have been confused with internal domain names, and not all of the CAs and RAs may be aware that .int is an ICANN approved TLD.  
Issuance of SHA-1 subordinate CA certificates, end entity certificates, or OCSP responder certificates is forbidden by [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#51-algorithms section 5.1 of Mozilla's Root Store Policy] and section 7.1.3.2.1 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements]. Other uses of SHA-1 are also being phased out. See [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#513-sha-1 MRSP § 5.1.3].


Section 7 of Mozilla’s CA Certificate Policy states that CAs need to take “reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate.” There are different interpretations as to what this means in regards to internal domain names such as non-valid TLDs, hostnames, and IP addresses. However, there is consensus that there are problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks.  Mozilla is currently discussing whether the CA Certificate Policy should be updated to add more explicit requirements on this practice, or even to disallow it altogether.
=== Delegation of Domain / Email Validation to Third Parties ===


If you have issued certificates for internal domains within your CA hierarchy, Mozilla requests that you take the following actions:
Section 1.3.2 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements] forbids delegating domain validation to third parties.
# Perform an internal audit to look for certificates that have been issued within your CA hierarchy which have .int domain names in the Common Name and/or as DNS Names in the subjectAlternativeName. For each of these certificates, check to see if the certificate subscriber owns/controls that domain name, and revoke the certificate if they do not own/control that domain name.
# Review your controls/procedures (both internally and your RAs) for correct identification of internal and external domain names and verification that subscribers own/control the domain name to be included in their certificate. Please refer to these documents:
#* Section 7 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla’s CA Certificate Policy]
#* [[CA:Recommended_Practices|Recommended practices for CAs]]


Mozilla also recommends that you
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Section 2.2 of Mozilla's Root Store Policy] says: "The CA operator SHALL NOT delegate validation of the domain portion of an email address."
# Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates.
# Maintain your own list of ICANN approved TLDs that are eligible to be used for domains in certificates issued within your CA hierarchy. If a new TLD is created by [http://www.icann.org/en/registries/top-level-domains.htm IANA], make an explicit decision whether or not to add the new TLD to your list.


=== OCSP Responses signed by a certificate under a different root ===
Domain and Email validation are core requirements of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] and should always be incorporated into the issuing CA's procedures. Delegating this function to third parties is not permitted.


CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 2560, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.
== Potentially Problematic Practices ==


RFC 2560, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain.  NSS enforces these requirements exactly.
=== Allowing External Entities to Operate Subordinate CAs ===


When an OCSP responder URL is included in end-entity certificates, Firefox will by default attempt to check the certificate's status via OCSP. If the OCSP signer certificate is not the certificate of the CA that issued the certificate in question and is not issued by the CA that issued the certificate in question, the OCSP check will fail with an NSS error code for OCSP, such as SEC_ERROR_OCSP_UNAUTHORIZED_REQUEST or SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE.
Some root CA operators authorize external entities to operate their own CAs as subordinate CAs under the root. In considering a root certificate for inclusion in NSS, Mozilla will evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. This evaluation includes a review of the CA's approval criteria, as well as the documentation and auditing-of-operations requirements that the operator of the root CA places on such relationships.


For a detailed explanation about why an OCSP responder should not use a self-signed OCSP responder certificate and depend on Trusted Responder Mode within the Firefox browser, see: [[CA:OCSP-TrustedResponder|Details about OCSP Trusted Responder Mode.]]
In order to best ensure the safety and security of Mozilla users, Mozilla has a [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ single consistent policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of TLS server certificate or email certificate issuance.


Please test your OCSP responder within the Firefox browser by enforcing OCSP as per our [[CA:Recommended_Practices#OCSP|CA Recommended Practices for OCSP.]]
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas Section 8.4 of the Mozilla Root Store Policy] requires that externally operated CAs undergo public discussion unless they meet one of the enumerated exceptions (e.g. they are already in the root store with the ability to issue the same type of certificate that they were already approved for).  See [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas MRSP § 8.4] and [https://wiki.mozilla.org/CA/External_Sub_CAs#Process_for_non-Technically-Constrained_Subordinate_CAs Process for non-Technically-Constrained Subordinate CAs] for details.


=== SHA-1 Certificates ===
During the root inclusion/change process, CAs must provide a clear description of any subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with CA/Browser Forum and Mozilla's CA Certificate Policy requirements as per the [https://wiki.mozilla.org/CA:SubordinateCA_checklist Subordinate CA Checklist].  
SHA-1 certificates may be compromised when attackers can create a fake cert that hashes to the same value as one with a legitimate signature, and is hence trusted. Mozilla can mitigate this potential vulnerability by turning off support for SHA-1 based signatures. The SHA-1 root certificates don’t necessarily need to be removed from NSS, because the signatures of root certificates are not validated (roots are self-signed). Disabling SHA-1 will impact intermediate and end entity certificates, where the signatures are validated.


There are still many end entity certificates that would be impacted if support for SHA-1 based signatures was turned off. Therefore, we are hoping to give CAs time to react, and are planning to turn off support for SHA-1 based signatures in 2017. Note that Mozilla will take this action earlier if needed to keep our users safe.
CAs must disclose their internally and externally operated subordinate CAs in the [https://www.ccadb.org/policy CCADB], and maintain annual updates to the corresponding CP/CPS documents and audit statements. If CP/CPS or audit documents for a particular subordinate CA are different than that of the root CA, then such different documents also need to be reflected in the [https://www.ccadb.org/cas/intermediates CCADB].
* CAs should not be issuing new SHA-1 certificates, and should be migrating their customers off of SHA-1 intermediate and end-entity certificates.
* If a CA still needs to issue SHA-1 certificates for compatibility reasons, then those SHA-1 certificates should expire before 2017.
* If you aren't sure whether or not your site is using SHA-1, please see https://shaaaaaaaaaaaaa.com/.
* [https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ Security Blog Post Regarding SHA-1 Based Signature Algorithms]


=== Generic names for CAs ===
=== Generic Names for CAs ===


In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases CA names are very generic, e.g., "Secure Server CA"; this makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.
In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases, CA names are too generic, e.g. "Secure Server CA", which makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.


Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA.
Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA.


Additionally, the issuer and subject information in the root certificate should provide clear indication about who owns or operates the certificate. Generic issuer and subject information inhibits the users' ability to establish a chain of trust, and to pursue complaints when appropriate. For instance, the following issuer information would not be acceptable in a root certificate to be included in NSS.
Additionally, the issuer and subject information in the root certificate should provide clear indication about who owns or operates the CA. Generic issuer and subject information inhibits the users' ability to establish a chain of trust, and to pursue complaints when appropriate. For instance, the following issuer information would be totally unacceptable in a root certificate to be included in NSS.
* CN = Root CA
* CN = Root CA
* OU = Certification Authorities
* OU = Services
* O = admin
* O = admin
There is no information in this issuer that can be linked back to any particular CA. There is no distinguishable company name or brand name. All of the information in this issuer is too generic to do a search on and hope to find the CA.
There is no information in this issuer that can be linked back to any particular CA operator. There is no distinguishable company name or brand name. All information in this issuer is too generic to do a search on and hope to find the responsible CA operator. (Moreover, it lacks the two‐letter ISO 3166‐1 country code, which is required by section 7.1.4.3 of the Baseline Requirements.)


'''Important:''' Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable to have the O be a generic term such as "Admin" because it could mislead users that rely on the issuer details, such as when you hover your mouse over the domain or organization section in the address bar.
'''Important:''' Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable for the O not to identify the CA operator and a generic term such as "Admin" will mislead users, who rely on the issuer details, when they hover their mouse over the lock icon in the address bar.
 
Also, please refer to sections 7.1.4.1 Name Encoding and 7.1.4.3 Subject Information - Root Certificates and Subordinate CA Certificates in the Baseline Requirements.


=== Lack of Communication With End Users ===
=== Lack of Communication With End Users ===


CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA.
CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA. See [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements], section 4.9.3, "The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports. The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS."
 
===Backdating the notBefore date===
 
Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not.
 
== Other considerations when updating the CA Certificate Policy ==
 
Many of the descriptions of the practices above will provide food for thought when and if we are making further updates to the CA Certificate Policy. Other issues which might be considered at that time include:
 
=== Root Count Restrictions ===
 
It has been suggested that, when the CA cert policy is revised, we restrict the
number of roots any one CA may have to e.g. 3. This is because more roots
increases the download size of the product.
 
=== Restrict government roots to their TLDs ===
 
A suggestion for a future revision of the policy is: we should restrict
government run/sponsored roots to only issuing certificates for the
corresponding TLD.
 
There are, of course, questions such as:
 
* What defines a government root
* What if they have all the necessary audits anyway
 
and so on. These would need to be discussed.
 
=== Minimum Key Sizes ===
 
One suggestion for a future revision of the CA Cert Policy is that we should
specify minimum key sizes, either just for roots or for roots, intermediates
and end entity certificates.
 
The exact restrictions would need to be discussed, but doubtless we would take
into account the views of our crypto team and advice from places like NIST.
 
[[CA:MD5and1024|Dates for Phasing out MD5-based signatures and 1024-bit moduli]]
 
=== Max Time Between Audits ===
 
It has been suggested that, when the CA cert policy is revised, we specify the
maximum period allowed between audits. WebTrust currently specifies 12 months,
and the same is (I understand) recommended for ETSI audits.
 
=== Actual Paperwork ===
 
It has been suggested that CAs should submit some paperwork by postal mail as
well as electronically. A formal inclusion request and general details from the
CA in question might help Mozilla in the case of legal problems in the future.
 
Apparently Apple and Microsoft do require physical paperwork.
 
=== Improve definition of "independent"; add idea of "trustworthy" ===
 
Currently, the guidelines talk about an auditor having to be both "independent"
and "competent". It has been suggested that the definition of independent
should be changed to be more like that the inverse of the MPL's definition of
You:
 
"For legal entities, "You" includes any entity which controls, is controlled
by, or is under common control with You. For purposes of this definition,
"control" means (a) the power, direct or indirect, to cause the direction or
management of such entity, whether by contract or otherwise, or (b) ownership
of more than fifty percent (50%) of the outstanding shares or beneficial
ownership of such entity."
 
Additionally, a new "trustworthiness" requirement would be added, which would
address some of the issues currently listed under "independent", such as being
bound to render a true judgement. This is because one could imagine an auditor
who was (under the above definition) independent and also competent, but may
nevertheless always provide "the right result" on payment of a fee.
 
=== Validate all Data included in Certificates ===
 
Only data that has been verified to be correct should be included in a certificate. All information that is supplied by the requester must be verified to be correct before it may be included in the certificate. For example, for SSL certificates, alternative names need to be validated just as well as the subject. And for email certificates, if only the email address of the certificate subscriber is verified, then the CN should not include any unverified element that the subscriber supplied.


=== DNS names in SANs ===
=== Backdating the notBefore Date ===


It would be appropriate for Mozilla CA policy to mandate that CAs put all DNS names for a cert into SANs. It would not be necessary to go beyond that and disallow CAs to ALSO ADDITIONALLY put one DNS name in the subject common name for the benefit of VERY old (more than 12 year old) browsers that don't recognize SANs. It is only necessary to make it clear that ALL the DNS names (not all but one) must go into the SAN.
Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline, prohibition, or code-enforced restriction is not.


Some CAs mistakenly believe that one primary DNS name should go into the Subject Common Name and all the others into the SAN.  That's wrong.  ALL should go into the SAN.
=== Issuer Encoding in CRL ===


Then, modern browsers should stop paying attention to Subject common names ({{bug|552346}}). Doesn't matter what CAs put there as long as browsers don't look there.
The encoding of the Issuer field in the CRL should be byte-for-byte equivalent with the encoding of the Issuer in the certificate; that is, using the exact same string types and field contents. The specs ([https://www.ietf.org/rfc/rfc2459.txt RFC 2459], [https://www.ietf.org/rfc/rfc3280.txt RFC 3280], [https://tools.ietf.org/html/rfc5280#section-7 RFC 5280]) permit them to mismatch, but that causes compatibility issues with various clients -- in such cases client software might not find the entry for the revoked certificate in the CRL.

Latest revision as of 16:16, 23 January 2024

This page contains comments about various CA practices that have been the subject of discussion in past CA evaluations. Some of these practices are addressed by the Mozilla Root Store Policy and are forbidden. They are listed here because they are things CAs often get wrong. Others, we do not necessarily consider security risks, but we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Additional practices may be addressed in future versions of the policy.

Forbidden Practices

Long-lived Certificates

Section 6.3.2 of the CA/Browser Forum's Baseline Requirements states: "Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days."

Non-Standard Email Address Prefixes for Domain Ownership Validation

Mozilla's Root Store Policy requires CAs to conform to the CA/Browser Forum Baseline Requirements (BRs) in the issuance and management of publicly trusted TLS server certificates. This includes the BR restrictions on the use of email as a way of validating that the certificate subscriber owns or controls the domain name to be included in the certificate. CAs are expected to conform to BR section 3.2.2.4, which allows email to the "Domain Contact", defined as the "Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar." (BR § 3.2.2.4.2); a selected whitelist of constructed addresses, which are limited to local-parts of "admin", "administrator", "webmaster", "hostmaster", and "postmaster" followed by the "at" sign ("@") and the domain name in question (read BR § 3.2.2.4.4 for specifics); or using email addresses found in DNS (BR § 3.2.2.4.13 and BR § 3.2.2.4.14).

A CA that authorizes certificate subscribers by contacting any other email addresses may be found non-compliant with Mozilla's Root Store Policy and in violation of the Baseline Requirements, and may have action taken against it. CAs are also reminded that Mozilla's Root Store Policy and the Baseline Requirements extend to any CA certificates that are technically capable of issuing TLS server certificates, and subordinate CAs that fail to follow these requirements put the root CA in jeopardy of removal from Mozilla's root store.

Issuing End Entity Certificates Directly From Roots

This is forbidden by section 6.1.7 of the Baseline Requirements.

Distributing Generated Private Keys in PKCS#12 Files

Section 5.2 of Mozilla's Root Store Policy states: "CA operators MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage, unless the certificate is being issued to the CA itself."

In other words, CAs must note generate key pairs for TLS server certificates, except for their own use (e.g. certificates for the test websites required by BR section 2.2). CAs may only generate the key pairs for S/MIME certificates. Distribution or transfer of S/MIME certificates in unprotected PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then:

  • The storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal)
  • The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the storage.

Certificates Referencing Local Names or Private IP Addresses

A Subject Alternative Name (SAN) with an internal or local name or with a reserved or private IP address is forbidden by section 7.1.4.2.1 of the Baseline Requirements.

OCSP Responses Signed by a Certificate Under a Different Root

CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 6960, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.

RFC 6960, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.

For a detailed explanation about why an OCSP responder should not use a self-signed OCSP responder certificate and depend on Trusted Responder Mode within the Firefox browser, see: Details about OCSP Trusted Responder Mode.

Please test your OCSP responder within the Firefox browser by enforcing OCSP as per our CA Recommended Practices for OCSP.

Issuance of SHA-1 Certificates

Issuance of SHA-1 subordinate CA certificates, end entity certificates, or OCSP responder certificates is forbidden by section 5.1 of Mozilla's Root Store Policy and section 7.1.3.2.1 of the Baseline Requirements. Other uses of SHA-1 are also being phased out. See MRSP § 5.1.3.

Delegation of Domain / Email Validation to Third Parties

Section 1.3.2 of the Baseline Requirements forbids delegating domain validation to third parties.

Section 2.2 of Mozilla's Root Store Policy says: "The CA operator SHALL NOT delegate validation of the domain portion of an email address."

Domain and Email validation are core requirements of Mozilla's Root Store Policy and should always be incorporated into the issuing CA's procedures. Delegating this function to third parties is not permitted.

Potentially Problematic Practices

Allowing External Entities to Operate Subordinate CAs

Some root CA operators authorize external entities to operate their own CAs as subordinate CAs under the root. In considering a root certificate for inclusion in NSS, Mozilla will evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. This evaluation includes a review of the CA's approval criteria, as well as the documentation and auditing-of-operations requirements that the operator of the root CA places on such relationships.

In order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent policy that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of TLS server certificate or email certificate issuance.

Section 8.4 of the Mozilla Root Store Policy requires that externally operated CAs undergo public discussion unless they meet one of the enumerated exceptions (e.g. they are already in the root store with the ability to issue the same type of certificate that they were already approved for). See MRSP § 8.4 and Process for non-Technically-Constrained Subordinate CAs for details.

During the root inclusion/change process, CAs must provide a clear description of any subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with CA/Browser Forum and Mozilla's CA Certificate Policy requirements as per the Subordinate CA Checklist.

CAs must disclose their internally and externally operated subordinate CAs in the CCADB, and maintain annual updates to the corresponding CP/CPS documents and audit statements. If CP/CPS or audit documents for a particular subordinate CA are different than that of the root CA, then such different documents also need to be reflected in the CCADB.

Generic Names for CAs

In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases, CA names are too generic, e.g. "Secure Server CA", which makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.

Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA.

Additionally, the issuer and subject information in the root certificate should provide clear indication about who owns or operates the CA. Generic issuer and subject information inhibits the users' ability to establish a chain of trust, and to pursue complaints when appropriate. For instance, the following issuer information would be totally unacceptable in a root certificate to be included in NSS.

  • CN = Root CA
  • O = admin

There is no information in this issuer that can be linked back to any particular CA operator. There is no distinguishable company name or brand name. All information in this issuer is too generic to do a search on and hope to find the responsible CA operator. (Moreover, it lacks the two‐letter ISO 3166‐1 country code, which is required by section 7.1.4.3 of the Baseline Requirements.)

Important: Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable for the O not to identify the CA operator and a generic term such as "Admin" will mislead users, who rely on the issuer details, when they hover their mouse over the lock icon in the address bar.

Also, please refer to sections 7.1.4.1 Name Encoding and 7.1.4.3 Subject Information - Root Certificates and Subordinate CA Certificates in the Baseline Requirements.

Lack of Communication With End Users

CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA. See Baseline Requirements, section 4.9.3, "The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports. The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS."

Backdating the notBefore Date

Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline, prohibition, or code-enforced restriction is not.

Issuer Encoding in CRL

The encoding of the Issuer field in the CRL should be byte-for-byte equivalent with the encoding of the Issuer in the certificate; that is, using the exact same string types and field contents. The specs (RFC 2459, RFC 3280, RFC 5280) permit them to mismatch, but that causes compatibility issues with various clients -- in such cases client software might not find the entry for the revoked certificate in the CRL.

Retrieved from "https://wiki.allizom.org/index.php?title=CA/Forbidden_or_Problematic_Practices&oldid=1249756"