Adivinanzas: no funcionaría. Lo mismo cuando algunas CA intentaron usar un esquema de redacción no estándar. - Que es solo una variante específica de enviar un certificado mientras se emite otro. Esto fue detectado por los navegadores que realmente se molestan en comprobar. - > Mi sitio tiene el certificado Transparencia habilitado pero Chrome sigue mostrando NET :: ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

- La aplicación de CT depende del navegador. Y AFAIK solo es requerido por Chrome para certificados de Symantec. Pero el requisito de CT-todo está en el horizonte de Chrome para octubre de 2017. Consulte: enlace

Edición 1: ¿Para qué sirve la TC?

Usted escribió:

  

El objetivo mismo de CT es evitar que las CA emitan certificados por lo que no deberían.

No lo es. El objetivo no es la prevención sino la rendición de cuentas. Una CA puede emitir un certificado para cualquier dominio en cualquier momento. Esa parte NO es cambiada por CT.

Lo que cambia el juego es que cuando se emite un certificado deshonesto puede suceder una de dos cosas:

• Si la CA no se envía a CT en absoluto o se envía con un nombre de host diferente, entonces (tan pronto como los navegadores lo apliquen) el navegador rechazará el certificado. Y el rogue cert será inútil.
• Si la CA se envía a CT con el nombre de host correcto, el certificado será público. Y el propietario de un dominio a quien le importa puede colocar un trabajo de vigilancia automática para todos sus nombres de dominio en los registros de CT. ( Facebook ofrece este servicio de forma gratuita .)

En sus propias palabras:

  

La transparencia del certificado permite detectar certificados SSL que hayan sido emitidos por error por una autoridad de certificación o que hayan sido adquiridos de manera malintencionada por una autoridad de certificación que de otra manera sería impensable. También permite identificar a las autoridades de certificación que se han vuelto falsas y que emiten certificados de manera maliciosa.

Sí, es posible detectar el escenario que describiste.

Esto es posible porque toda la cadena de certificados se almacena en el registro. Las preguntas entonces son "¿Qué parte tiene la responsabilidad de hacer esto?" y "¿cómo lo hacen?"

Me parece que la responsabilidad primordial es con el cliente, como la parte que confía (mi interpretación, no se establece en la norma), para verificar adecuadamente antes de confiar en algo.

Mi reconstrucción (¿interpretación?) de cómo sucede, según el RFC 6962 document :

1. Los Certificados (precertificado y el actual) se registran y emiten como usted describe.
2. Durante el protocolo de enlace TLS, el cliente incluye una extensión de ClientHello "signed_certificate_timestamp" con extension_data como vacío.
3. El servidor devuelve SCT (múltiples, de múltiples proveedores de registro, si corresponde) en extensión_data con el tipo "signed_certificate_timestamp".
4. El cliente recupera la cadena de certificados de un / el Registro y realiza 4 verificaciones en cualquier orden.
5. (3a) ¿Las firmas de certificados coinciden entre el certificado proporcionado por el servidor y el certificado proporcionado por el registro?
6. (3b) ¿Los certificados SCT coinciden? (la recuperación parece ser por LogID, por lo que me imagino que esta verificación es obligatoria)
7. (3c) ¿Se verifica la integridad del certificado? Esto ya forma parte de los cheques que ya están en boga.
8. (3d) ¿El nombre del servidor coincide con una de las entradas SNI / SN en el certificado? Esto también es parte de los cheques actualmente en boga.

Espero que si los clientes hacen 3a & 3b, el fraude será atrapado. La función de CT Logs y SCT se detiene al hacer que la información esté disponible para los clientes (incluidos los propietarios de certificados y los auditores de CT), de modo que dicho fraude se pueda detectar a la brevedad.

Si el propietario del certificado no es cómplice en el escenario que describió, el problema se detectaría tan pronto como el certificado se entregue al propietario y el propietario envíe el certificado al registro de CT. Habría una falta de coincidencia de firma en el certificado.

Incluso si el propietario del certificado es cómplice, cuando un navegador (cliente) compatible realiza esta comprobación, se detectaría en 3a o 3b, según cómo se modificaron los datos en el certificado.