¿Existen certificados SSL a pedido?

No hay nada tecnológicamente difícil en la emisión de certificados. Es solo un poco de codificación, y una firma; una PC básica puede hacer eso mil veces por segundo . Si bien CA normalmente no se entrega a la emisión de certificados a pedido, no existe una barrera técnica ineludible para ello.

La explicación más plausible es que actualmente se está conectando a través de un proxy que hace un man-in-the -mediar "ataque" y realmente genera un certificado falso a pedido. No es un ataque real en el sentido de algún estafador que intenta atacarte; más un ataque "institucional" por parte del administrador del sistema local, ejecutando un producto como ese . Esto se está volviendo popular en los entornos corporativos.

Para verificar si esto ocurre, un truco simple es cambiar la fecha del sistema . De hecho, un enigma de los proxies MitM es que deben generar un certificado que será aceptado por el cliente, lo que, en particular, implica que el certificado debe ser tal que la hora actual, como se cree que sea por el cliente , cae dentro del rango de validez. Una propiedad a menudo pasada por alto de SSL es que tanto el cliente como el servidor se comunican su propia noción de la hora actual, en el primeras etapas del procedimiento de apretón de manos. Esto permite al servidor saber cómo está configurado el reloj del cliente. Si cambia su fecha y hora actuales a, digamos, la semana pasada, y el certificado del servidor sigue ese cambio (cierre todas las ventanas del navegador y reinícielo para asegurarse de que se use una nueva sesión SSL), entonces el certificado del servidor fue definitivamente se produce a pedido, porque no hay otra manera de que el certificado se ajuste a un reloj del cliente fuera de lugar.

También querrá ver en qué ancla de confianza (también conocido como "certificado raíz") aumenta la cadena de servidores. Si una MitM institucional está vigente en su sistema, entonces la cadena subirá a una CA raíz "pícara" correspondiente. Lo que debería ocurrir con los certificados de GoDaddy se describe aquí (por supuesto, el MitM puede teóricamente modifique esa página también, como lo ve, pero si hay una discrepancia entre lo que dice GoDaddy y lo que observa, entonces se comprueba que hay un juego sucio en curso).

La emisión de certificados SSL bajo demanda es posible , pero poco común en el uso en el mundo real. GoDaddy y algunas otras compañías están en una posición única para emitir certificados a pedido, ya que ellos mismos pueden firmar el certificado.

Pero vale la pena señalar que no hay una razón comercial importante para hacerlo, pero que habría un costo significativo tanto en términos de seguridad como de confiabilidad. Simplemente no está hecho. De hecho, los certificados SSL de GoDaddy que veo en este momento en su página de inicio se emitieron en 2012.

Por otra parte, los certificados SSL bajo demanda se emiten en casos reales mediante servidores proxy que realizan la intercepción de tráfico SSL en el medio. Básicamente, cada vez que visita un sitio, crean un nuevo certificado que se asigna al sitio que desea visitar. El nombre del certificado coincide con la URL de su navegador, por lo que el certificado se acepta aunque no sea el que envía el servidor de destino.

Estos proxies deben tener su propio certificado de firma instalado en su computadora, de lo contrario, todo el esquema no funcionará.

Es poco probable que una CA como GoDaddy le emita un certificado SSL "a pedido cada vez que se cargue el sitio SSL". Esto significaría que el sitio en cuestión tiene la clave privada de CA (para firmar su certificado), otros escenarios incurrirían en una demora excesiva al establecer la sesión SSL.

Técnicamente es posible generar un certificado SSL cuando se inicia una nueva sesión SSL, esto se realiza mediante el Webscarab herramienta al enviar peticiones SSL. Para que el explorador confíe en este certificado generado sobre la marcha, debe agregar el certificado de CA de Webscarab a su lista de CA de confianza.

En su caso, es probable que sea una coincidencia que el administrador del sistema haya actualizado el certificado justo antes de abrirlo. Cuando el reloj no está sincronizado, el tiempo de validez "No antes" puede golpearlo. Por esta razón, la CA que uso establece el tiempo ligeramente en el pasado. ¿Has comprobado si tu reloj es correcto? Quizás necesite una nueva batería RTC y tenga que habilitar NTP.

Otra explicación es que la clave (CA) (sub) se comprometió y que alguien está abusando de esto para realizar un ataque MitM.