Confirmed users, Administrators
5,526
edits
CA/Forbidden or Problematic Practices: Difference between revisions
Jump to navigation
Jump to search
CA/Forbidden or Problematic Practices (view source)
Revision as of 18:51, 23 November 2009
, 23 November 2009→Issuing SSL Certificates for Internal Domains
| Line 43: | Line 43: | ||
=== Issuing SSL Certificates for Internal Domains === | === Issuing SSL Certificates for Internal Domains === | ||
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. | |||
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. | |||
If you have issued certificates for internal domains within your CA hierarchy, Mozilla requests that you take the following actions: | If you have issued certificates for internal domains within your CA hierarchy, Mozilla requests that you take the following actions: | ||
| Line 53: | Line 55: | ||
Mozilla also recommends that you | 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. | # 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 === | === OCSP Responses signed by a certificate under a different root === | ||