¿Existe alguna razón de seguridad para no utilizar un certificado comodín que no sea la capacidad de administración y la explotación si se usa en varios servidores?

¿Existe alguna razón de seguridad para no utilizar un certificado comodín que no sea la capacidad de administración y la explotación si se usa en varios servidores?

Tengo un asesor de seguridad que me dice que no podemos utilizar certificados SSL comodín por razones de seguridad. Para ser claro, prefiero usar certificados únicos o certificados multidominio (SAN). Sin embargo, necesitamos que el servidor (plesk) sirva cientos de subdominios.

Según mi investigación, la razón principal por la que las personas en el sitio no usan comodines es la siguiente, que parece provenir de Verisign:

  • Seguridad: si un servidor o subdominio se ve comprometido, todos los subdominios pueden verse comprometidos.
  • Gestión: si es necesario revocar el certificado comodín, todos los subdominios necesitarán un nuevo certificado.
  • Compatibilidad: Es posible que los certificados comodín no funcionen perfectamente con
    configuraciones de servidor-cliente más antiguas.
  • Protección: Los certificados SSL VeriSign Wildcard no están protegidos por la garantía extendida de NetSure.

Dado que la clave privada, el certificado y el subdominio existirán en el mismo servidor... el reemplazo sería tan simple como reemplazar este certificado y afectar a la misma cantidad de usuarios. Por lo tanto, ¿existe otra razón para no utilizar un certificado comodín?

Respuesta1

El único otro problema que conozco es queLos certificados de Validación Extendida no se pueden emitir con un comodín, por lo que no es una opción si opta por un certificado EV.

En términos de seguridad, ha dado en el clavo: una única clave privada protege todos los dominios que están bajo el comodín. Entonces, por ejemplo, si tenía un certificado SAN multidominio que cubría www.example.comy something.example.comestaba comprometido, solo esos dos dominios están en riesgo de sufrir un ataque con la clave comprometida.

Sin embargo, si ese mismo sistema estuviera ejecutando un *.example.comcertificado para manejar el tráfico SSL para wwwy somethingsubdominios y estuviera comprometido, entonces todo lo cubierto por ese comodín estaría potencialmente en riesgo, incluso los servicios que no estén alojados directamente en ese servidor, por ejemplo, webmail.example.com.

Respuesta2

Seguridad: si un servidor o subdominio se ve comprometido, todos los subdominios pueden verse comprometidos.

Si está utilizando un único servidor web para sus cientos de hosts virtuales, todas las claves privadas deberán ser legibles para ese proceso del servidor web. Si una persona puede comprometer el sistema hasta un punto en el que pueda leer una clave/certificado, entonces probablemente ya haya comprometido el sistema hasta un punto en el que pueda obtener todas las claves/certificados privados utilizados por ese servidor web.

Las claves generalmente se almacenan en el sistema de archivos con privilegios que solo permitirán que root acceda a ellas. Entonces, si su sistema está rooteado, probablemente lo haya perdido todo. Realmente no importa si tiene un solo certificado o muchos.

Gestión: si es necesario revocar el certificado comodín, todos los subdominios necesitarán un nuevo certificado.

Si está utilizando un comodín para *.example.org, entonces solo necesitará reemplazar un único certificado. Si tiene un certificado para one.example.org, two.example.org y three.example.org, deberá reemplazar 3 certificados. Entonces el certificado comodín requiere menos trabajo. Entonces sí, ese certificado sería revocado y reemplazado, pero como solo hay que reemplazar uno en lugar de cientos, debería ser muy fácil.

Compatibilidad: Es posible que los certificados comodín no funcionen perfectamente con configuraciones de servidor-cliente más antiguas.

Es casi seguro que esos sistemas deben actualizarse. Es casi seguro que tienen muchas otras vulnerabilidades.

información relacionada