When a client such as a web browser accesses a resource using HTTPS, which subsequently uses SSL or TLS for encryption and authentication, the client is supposed to verify the certificate provided by the server. In particular, the client verifies that the certificate was issued by a root certificate authority (CA) that is trusted. This trust relationship relies upon the belief that the root certificate authorities have sufficiently verified that the individual requesting a certificate is doing so on behalf of the domain owner.

Many root CAs use the concept of "domain-authenticated" or similarly-named SSL certificates. These certificates may be issued with minimal proof of domain ownership. In some cases, an SSL certificate is provided simply based on the ability to use certain email addresses at the domain in question. According to RFC2142, the email address that should be used for DNS-related services should be hostmaster. According to the Mozilla CA Certificate Inclusion Policy as well as the CA/Browser Forum baseline requirements documents, the control of the addresses admin, administrator, webmaster, hostmaster, and postmaster can be used to prove domain ownership. However, some root CAs allow other email addresses to serve as proof of domain ownership. For example, a user who operates the email address ssladministrator@example.com may be able to obtain an SSL certificate for example.com.

Aside from EV certificates, the browser displays no difference between domain-authenticated certificates and certificates that were obtained through additional validation. For example, GeoCerts offers both domain-authenticated certificates and fully-authenticated certificates. However, from a client (e.g. web browser) perspective, there is no difference at all between the two certificates.

Domains of sites that are used for email purposes are at increased risk. If a user can register the email address of any one of the available addresses accepted by a single root CA for the purpose of domain-authenticated SSL certificates, then that user may be able to purchase a valid SSL certificate for that domain. We are unaware of a comprehensive list of email addresses accepted for domain-authenticated SSL certificates, but here is the policy used by Comodo. SSL resellers such as BuyHTTP list additional email addresses that can be used for email authentication for SSL certificate purchases.

Update: Upon further investigation, it appears that the SSL resellers that list email addresses outside of the five addresses listed in the CA/Browser BR document may be listing out-of-date guidance. In particular, that those email aliases may have been accepted by their upstream root CAs in the past for issuing certificates. However, we cannot rule out the possibilities that an attacker has used such an email to obtain a fraudulent certificate in the past using such an email address, or that there is at least one root CA that will currently accept a non-whitelisted email address as domain ownership validation.

An attacker may be able to obtain a certificate for a domain that somebody else owns. With such a certificate, the attacker can spoof HTTPS sites and intercept HTTPS traffic without triggering client certificate warnings.

The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workarounds:

Block access to sensitive accounts

Sites that provide email accounts to users should restrict the ability to create email accounts that are trusted by root CAs. At the very least, users should not be able to create the email addresses for admin, administrator, webmaster, hostmaster, and postmaster. BuyHTTP lists those addresses as well as root, ssladmin, sysadmin, info, is, it, mis, ssladministrator, and sslwebmaster. If users have already created accounts that match up to these special names, those accounts should be disabled. Failure to do so can result in a user being able to obtain an SSL certificate for the domain in question.

Note that the above list of email addresses is not necessarily comprehensive. There may be at least one root CA that supports at least one additional email address as proof of domain ownership.

The vendors listed as "affected" here are CAs that provide email-authenticated domain-validated SSL certificates. Although the CA/Browser Forum baseline requirements documents list email authentication using predefined aliases as a valid form of domain validation (section 11.1.1), CERT's stance is that such email authentication is not sufficient proof of domain ownership. Email providers that may be affected by fraudulent acquisition of SSL certificates by email are not listed here.