Lo que hacen los navegadores está sujeto a cambios en los caprichos de quien los mantiene, y lo hacen sin la documentación adecuada.
El tratamiento de los caracteres comodín en las entradas dNSName en los certificados se define formalmente en RFC 2818 , que implicaría que, por ejemplo, *.*.example.com coincidiría con un nombre de subdominio que tiene dos niveles por debajo de example.com ; también dice que f*.com realmente coincidirá con foo.com pero no con bar.com .
Resultó que los navegadores no siguen estas reglas, por una variedad de razones que nunca se han documentado completamente, pero que se dividen principalmente en dos categorías:
- "Razones de seguridad"
- pereza
"Seguridad" aquí significa "nos encontramos con algunos abusos y cambiar las reglas sobre la marcha parecía una buena idea en ese momento". Por ejemplo, una vez que alguien produjo un certificado *.com , alguien se dio cuenta de que no era una buena idea y consideró conveniente prohibirlo simplemente en el código del navegador. Un punto importante a considerar aquí es que los proveedores de navegadores y las CA comerciales no son las mismas personas; Desde el punto de vista de un mantenedor del navegador, si hay que hacer algo rápidamente (por ejemplo, dentro de las 24 horas, no en los 24 meses), debe hacerse en el propio navegador. Los problemas de seguridad relacionados con los navegadores tienden a ser muy publicitados y bastante dañinos para la imagen del navegador, por lo que este llamado a una reacción inmediata, que generalmente (y desafortunadamente) excluye la buena documentación.
La pereza es probablemente culpable por la falta de soporte de "comodines dobles" como *.*.example.com . En general, si desea implementar soporte para expresiones con varios comodines, debe hacerlo con bucles anidados (para explorar todas las posibles combinaciones de coincidencia). La restricción de comodines a un solo " * ", además al comienzo del nombre, hace que la implementación sea mucho más sencilla.
Un hecho adicional a tener en cuenta es la propiedad paralizante de "seguridad". Cuando se ha hecho algo, o parece haberse hecho, en nombre de "seguridad", muchos desarrolladores pierden toda iniciativa y son extremadamente reacios a modificarlo, porque saben que cualquier contratiempo relacionado con la seguridad conlleva toda la culpa.
RFC 6125 trató de documentar la práctica existente, aunque varía mucho dependiendo del navegador (y sistema operativo, ya que algunos navegadores delegan la validación y el procesamiento de certificados al sistema operativo). Tenga en cuenta que RFC 6125 no realmente prohíbe más de un * en un nombre; de hecho, se ha enviado una errata al respecto, y el editor lo puso bajo el estado " mantenido para la actualización del documento ", que realmente significa" buen punto, lo arreglaremos en un RFC posterior ".
Mientras que RFC 6125 enumera los requisitos en el lado del navegador (consumidor de certificados), el CA / browser forum también considera el lado de CA (productor de certificados). Los Requisitos de referencia parecen implicar que solo un * puede aparece, y solo a la izquierda de un nombre (pero esto no está muy claramente establecido).
Si bien hay mucho más en la validación de certificados que en el procesamiento de nombres de comodines, todo el negocio relacionado con el carácter * ilustra bastante bien que no hay nada documentado con firmeza, y los proveedores de navegadores ya han tomado el hábito de hacer las cosas primero y documentar las cosas solo mucho más tarde (si las hay).