¿Se puede emitir un certificado SSL comodín para un dominio de segundo nivel?

Sí, puede ser emitido.

Afortunadamente, los navegadores comunes no aceptan certificados comodín para TLD.

Código fuente de Chromium :

// Do not allow wildcards for public/ICANN registry controlled domains -
// that is, prevent *.com or *.co.uk as valid presented names, but do not
// prevent *.appspot.com (a private registry controlled domain).
// In addition, unknown top-level domains (such as 'intranet' domains or
// new TLDs/gTLDs not yet added to the registry controlled domain dataset)
// are also implicitly prevented.
// Because |reference_domain| must contain at least one name component that
// is not registry controlled, this ensures that all reference domains
// contain at least three domain components when using wildcards.
size_t registry_length =
    registry_controlled_domains::GetCanonicalHostRegistryLength(
        reference_name,
        registry_controlled_domains::INCLUDE_UNKNOWN_REGISTRIES,
        registry_controlled_domains::EXCLUDE_PRIVATE_REGISTRIES);

// ... [SNIP]

// Account for the leading dot in |reference_domain|.
bool is_registry_controlled =
    registry_length != 0 &&
    registry_length == (reference_domain.size() - 1);

// Additionally, do not attempt wildcard matching for purely numeric
// hostnames.
allow_wildcards =
    !is_registry_controlled &&
    reference_name.find_first_not_of("0123456789.") != std::string::npos;
}

La lista completa de dominios que Google no permite está en net/base/registry_controlled_domains/effective_tld_names.dat

Otros navegadores también hacen esto, incluidos IE y Firefox.

En la lista de certificados falsos emitidos por DigiNotar , hay " *. *. com ". Esto es obviamente un intento de sortear la restricción.

Para la parte de emisión , todo se puede poner en un certificado. Que un nombre sea "comodín" no tiene un significado especial para la AC. La CA coloca una cadena como dNSName en una extensión Subject Alt Name , y eso es todo. Si esta cadena contiene caracteres " * " o no, no afectará el comportamiento de CA.

Lo que importa es lo que clientes SSL aceptará como un "certificado válido", es decir, un certificado que incluya un nombre que "coincida" con el nombre del servidor deseado (el que se incluye en la URL). Esto se especifica nominalmente en RFC 2818, sección 3.1 , y permite muchos tipos de nombres de caracteres comodín, incluidas las cosas como " www.*.*c* ", haciendo coincidir (teóricamente) cualquier nombre de servidor que contenga tres componentes, el primero es " www " y el tercero contiene al menos un " c ". Los proveedores de navegadores web pronto consideraron que esta especificación:

• permite nombres de comodines realmente amplios;
• fue relativamente complejo de implementar adecuadamente;
• era poco probable que se implementara correctamente por los otros proveedores de navegadores y por CA (aunque la CA no se ve afectada por el contenido del nombre, aún es responsable por el contenido del certificado, y los proveedores de navegadores adivinaron correctamente que habría CA que, de mala gana, emitiría certificados de comodín demasiado amplios);
• era un RFC "informativo" de todos modos, no un "estándar propuesto", por lo que las mentes inclinadas a los abogados podrían argumentar que podría ignorarse.

Los proveedores de navegadores hicieron sus propios esquemas y restricciones. Mucho más tarde, se publicó un nuevo RFC (6125, de marzo de 2011), con sección 6.4.3 dedicado al procesamiento de nombres de comodines en certificados. Lo que RFC 6125 describe está más en sintonía con la realidad, y es un "estándar propuesto", por lo que hay al menos algo de voluntad, en algún nivel, para que esto suceda. Sin embargo, nada en RFC 6125 obliga a rechazar *.com ; sin embargo, los navegadores do lo rechazan.

He probado esto en navegadores comunes, los tres grandes (en Windows de todos modos) no aceptan esto. Lo que no he hecho es intentarlo en las plataformas móviles, que son el verdadero objetivo de este ataque. Como iOS no tiene una forma de revocar certificados, hay millones de i-dispositivos que son vulnerables hasta que Apple libera un parche y lo aplican.

Lugares obvios para probar esto con alto impacto: ActiveSync para intercambiar, clientes VPN ssl, safari en dispositivos, navegador de stock en androides.