CA/Forbidden or Problematic Practices
Potentially problematic CA practices
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 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.
Long-lived DV 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.
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.
Wildcard DV SSL certificates
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 SSL Certificates for Internal Domains
There are various problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks. 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 owns/controls the domain to be referenced in the certificate. However, there still are CAs who issue SSL/TLS certificates with domain names referencing hostnames, non-valid TLDs and (internal) IP addresses. In the future Mozilla may elect to update the CA Certificate Policy to add more specifically disallow internal domain names in SSL certificates.
If you issue certificates for internal domains within your CA hierarchy, Mozilla requests that you take the following actions:
- 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:
Mozilla also recommends that you
- Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates.
- Track the ICANN list of TLDs and update your procedures as necessary when new TLDs are approved.
Delegation of Domain / Email validation to third parties
Domain and Email validation are core-requirements of the 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 unconstrained 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.
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.
Certificates referencing hostnames 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.
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.)
It is also a problematic practice to issue a certificate with non resolvable DNS or private IP and resolvable DNS adresses together.
OCSP Responses signed by a certificate under a different root
CAs are not required to use OCSP. However, 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.
At least one CA has issued certificates with OCSP URLs that reference OCSP responders that do not serve queries from the general public, and/or send out responses that are signed with a certificate that is
- not the certificate of the CA that issued the certificate in question; and
- not issued by the CA that issued the certificate in question.
When an OCSP responder URL is included in end-entity certificates, Firefox 3 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.
CRL with critical CIDP Extension
Currently Firefox handles "full" CRLs, but not "partitioned" CRLs. Partitioned CRLs are identified by the presence of a CRL Issuing Distribution Point (CIDP) extension flagged as critical. Firefox is not presently able to load CRLs with critical CIDP extensions. When attempting to load a CRL with a critical CIDP extension, Firefox will return the error code ffffe095, which is equivalent to the negative decimal number -8043. According to the NSS Error Codes this error corresponds to SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION.
The NSS team hopes to eventually implement partitioned CRLs, and when that work is done, Firefox should allow CRLs with critical CIDP extensions. However, even when that is done, older versions of Firefox will still not be able to load CRLs with critical CIDP extensions.
Our recommendation is to not put critical CIDP extensions into full CRLs, and to make full CRLs available for download when practical.
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.
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.
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.
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.