¿Cómo puedo demostrar que 3 CA raíz independientes validaron mi dominio?

No hay una manera estándar de hacer lo que imaginas y no tengo conocimiento de ninguna propuesta relevante. La estructura PKI establecida actualmente permite solo una única cadena de certificados (es decir, un solo emisor para un certificado) y el protocolo TLS utilizado permite solo un certificado de una sola hoja. En teoría, se podría crear un certificado con varios emisores utilizando extensiones de certificado y en teoría se podría extender el proceso de validación en TLS para verificar si hay varios emisores. Pero una vez más, no estoy al tanto de ninguna propuesta seria en esta área.

Servir certificados diferentes a través de múltiples solicitudes HTTPS también requiere algún tipo de extensiones o hacks, porque el servidor necesita saber cuál de los certificados debe enviar. Con las nuevas extensiones TLS, el cliente podría solicitar un certificado específico. Sin el cliente, podría reutilizar las extensiones existentes como SNI para un propósito diferente, es decir, dar nombres de host de destino ligeramente diferentes. O uno podría proporcionar diferentes direcciones IP en el DNS y cada servidor de direcciones IP con un certificado diferente. O uno podría rotar los certificados al azar. En todos estos casos, el cliente debe tener en cuenta que debe intentar obtener varios certificados y la cantidad de certificados que debe obtener y cómo combinar la información. Esto significa que se necesita algún conocimiento sobre el servidor que está codificado en cada certificado (es decir, la extensión del certificado) o que el cliente obtuvo del recurso externo de forma segura.

Debido a que no hay un estándar o incluso un estándar propuesto para hacer esto, usted necesita inventar el suyo o intentar obtener lo mejor de los estándares actuales. Dado que la piratería de una CA raíz es su principal preocupación, es probable que ya esté lo suficientemente protegido con el estándar existente HPKP , es decir, la fijación de certificados en el primer uso. De esta manera, ninguna CA comprometida puede crear un certificado utilizable en su nombre que sea aceptado por los navegadores que ya lo visitaron, ya que el atacante necesitaría su clave privada para hacer un mal uso del certificado. Y si HPKP no es suficiente, puede solicitar que su clave pública se incluya en el navegador a medida que se envía. Y esta fijación de clave pública no está restringida a una CA específica, sino solo a su par de claves, lo que significa que la clave y, por lo tanto, la información de HPKP permanecen igual si usa la misma clave en otro certificado firmado por una CA diferente. Por lo tanto, puede cambiar fácilmente la CA si el navegador desconfía de uno. Actualmente, no todos los navegadores son compatibles con HPKP pero se mejora . Entonces, esto es probablemente lo mejor que podría obtener sin intentar establecer otro estándar o crear una extensión de navegador poco utilizada. Si HPKP no es una opción para usted, puede agregar los motivos de esto a su pregunta.