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 21:26, 9 April 2010
, 9 April 2010→Wildcard DV SSL certificates
| Line 12: | Line 12: | ||
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.) | 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.) | ||
=== Email Address Prefixes for DV Certs === | |||
For domain-validated SSL certificates, some CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. | |||
Offering too many options for the email address prefix increases the risk of issuing a certificate to a subscriber who does not own/control the domain. Therefore, the list of email address prefixes should be limited. | |||
Our recommendation is to limit the set of email address prefixes to those that RFC 2142 suggests: | |||
* hostmaster | |||
* postmaster | |||
* webmaster | |||
* The following email address prefixes may also be OK | |||
** root (Unix,Linux) | |||
** administrator (Windows) | |||
** abuse (is a required mail account) | |||
=== Delegation of Domain / Email validation to third parties === | === Delegation of Domain / Email validation to third parties === | ||