CA/Forbidden or Problematic Practices

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.

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.