Certificados comodín y su alcance

El comodín lleva un asterisco en la etiqueta de más a la izquierda del nombre. Las reglas de identidad de servicio de TLS lo limitan a una sola etiqueta: el patrón *.dominio.example cubre tienda.dominio.example, pero no cubre dominio.example (sin prefijo) ni api.tienda.dominio.example (dos niveles). Para esos hace falta otro certificado o un nombre adicional declarado en el mismo.

Así que un comodín no es «todo el dominio». Quien lo cree así descubre su límite cuando un servicio nuevo con dos niveles empieza a dar errores de nombre, y la tentación es entonces instalar la misma clave en más sitios.

En la revisión, la columna resultado_de_validacion compara el nombre que se visita con los nombres que declara el certificado (san_declarados en la tabla comodines). Un «el nombre no coincide» sobre un servicio publicado significa que algún cliente verá un error o, peor, que el equipo habrá aprendido a ignorarlo.

Mira la tabla hosts y la columna san_declarados: dos nombres fallan, y uno de ellos es el dominio sin prefijo. Busca el otro.

Un certificado comodín se instala con su clave privada en cada servidor que lo usa. Cada copia es otro sitio desde donde esa clave puede perderse. Lo que importa de un comodín no es tanto cuántos nombres cubre como en cuántos lugares está su clave y quién la administra: un servidor de pruebas, o uno que mantiene un tercero, suele estar menos protegido que el de producción.

Consulta la tabla claves y mira las columnas entorno y responsable del comodín de Internet.

Una copia más de una clave es un servidor más que se debe parchar, vigilar y, si algo falla, reemplazar. La cifra que describe el riesgo de un comodín es el número de servidores que tienen su clave, y lo que se hace con ella es compararlo con lo que el servicio necesita de verdad.

Filtra la tabla claves por el identificador del comodín de Internet y cuenta las filas.

Hay dos movimientos que reducen el riesgo de un comodín. El primero, sacar su clave de donde no debe estar. El segundo, no usarlo para lo más sensible: los servicios críticos, como un servicio de pagos, se benefician de un certificado propio, con su propia clave y su propio vencimiento, de modo que lo que le pase a otro nombre no lo arrastre. Y si la clave estuvo en un servidor que no controlas, se da por expuesta y se reemplaza.