Técnicamente, el uso de comodines se define en RFC 2818 , que sí permite nombres como " *.*.example.com " o " foo.*.bar.*.example.com " o incluso " *.*.* ". Sin embargo, entre la teoría y la práctica, puede haber, digamos, diferencias prácticas (la teoría y la práctica coinciden perfectamente solo en la teoría, no en la práctica). Los navegadores web han implementado reglas más estrictas, porque:
- La implementación de la coincidencia de comodines de varios niveles toma unos cinco minutos más que la implementación de la coincidencia de nombres con un solo comodín.
- Los proveedores de navegadores no confiaban en la CA existente para nunca emitir un certificado "
*.*.com ".
- Los desarrolladores son seres humanos, por lo tanto, son muy buenos para no ver lo que no pueden imaginar, por lo que las personas que no se dieron cuenta de que eran posibles no implementaron los nombres de comodines múltiples.
Por lo tanto, los navegadores web aplicarán restricciones, que RFC 6125 intentan al menos documentar. La mayoría de los RFC son pragmáticos: si la realidad no coincide con la especificación, modifique la especificación, no la realidad. Tenga en cuenta que los navegadores también aplicarán reglas adicionales, como prohibir " *.co.uk " (aunque no todos los navegadores usan las mismas reglas, y tampoco están documentados).
Las CA profesionales también entran al baile con sus propias limitaciones, como las pruebas de verificación de identidad antes de emitir certificados, o simplemente la falta de voluntad para emitir certificados comodín demasiado amplios: el negocio principal de una CA profesional es vender muchos certificados, y los certificados de comodín no ayudan para eso. Todo lo contrario, de hecho. La gente quiere comprar certificados comodín precisamente para evitar comprar muchos certificados individuales.
Otra teoría que no logró ponerlo en práctica es Name Constraints . Con esta extensión X.509, sería posible que una CA emita un certificado a una sub-CA, restringiendo esa sub-CA para que pueda emitir certificados de servidor solo en un árbol de dominio dado. Una extensión Name Constraints con un "subárbol explícito" de valor " .example.com " permitiría www.example.com y foo.bar.example.com . En ese modelo, el propietario del dominio example.com ejecutaría su propia CA, restringida por su über-CA a solo nombres en el subárbol example.com . Eso estaría bien y elegante.
Desafortunadamente, todo lo que haga con los certificados X.509 no tiene ningún valor si las implementaciones implementadas (es decir, los navegadores web) no lo admiten, y los navegadores existentes no admiten restricciones de nombre. No lo hacen, porque no hay un certificado con restricciones de nombre para procesar (por lo que sería un código inútil), y no hay tal certificado porque los navegadores web no podrían procesarlos de todos modos. Para arrancar las cosas, alguien debe iniciar el ciclo, pero los proveedores de navegadores esperan después de una CA profesional, y la CA profesional no está dispuesta a admitir restricciones de nombre, por las mismas razones que antes (todo lo cual se reduce a dinero, en a largo plazo).