¿Se puede confiar en una CA intermedia como una CA raíz autofirmada?

Una raíz CA es en realidad una ilusión. En X.509 , hay anclajes de confianza . Un ancla de confianza es, en su mayoría, un nombre y una clave pública, que conoce a priori y en los que confía. La representación de ese nombre y esa clave pública como un "archivo de certificado" (tradicionalmente autofirmado) es solo una forma conveniente de mantener el ancla de confianza como un conjunto de bytes.

Según X.509, una CA es "intermedia" solo si no confía en ella a priori; no es una propiedad intrínseca de la CA. Lo que debe hacer es convencer a su software para que considere a la AC como un ancla de confianza. Un posible truco es volver a codificar los datos relevantes (el nombre de la CA y la clave pública) como un certificado autofirmado (supuestamente). Tenga en cuenta que la autofirma es sólo una tradición; está allí principalmente porque el formato de archivo para un certificado tiene un campo obligatorio para una firma. Para una CA "raíz", esta firma no tiene importancia (no tiene mucho sentido verificarla, ya que no le ofrecería ninguna seguridad). Por lo tanto, las aplicaciones que utilizan certificados de CA raíz rara vez verifican que la firma sea "propia".

Por lo tanto, puede crear un certificado personalizado "autofirmado" con el nombre de su "CA intermedia" como SubjectDN y IssuerDN . Para la firma, solo coloque bytes aleatorios no deseados de aproximadamente el tamaño correcto (256 bytes para una firma de 2048 bits). Luego, intente establecer este certificado pseudo-autofirmado como una raíz: es probable que funcione con su VPN. Alternativamente, cree su propia CA raíz y emita un certificado adicional para la CA intermedia (no necesita la cooperación de la CA intermedia para eso, solo necesita su nombre y clave pública, y tiene estos, en el certificado de la CA intermedia) ).

De acuerdo con el RFC sobre validación de certificados - RFC 3280 - Sección 6.2:

  

La selección de una o más CA confiables es una decisión local. UNA      El sistema puede proporcionar cualquiera de sus CA de confianza como el ancla de confianza para      Un camino particular. Las entradas al algoritmo de validación de ruta pueden      Ser diferente para cada camino. Las entradas utilizadas para procesar una ruta pueden      reflejar los requisitos o limitaciones específicos de la aplicación en la confianza      concedido un ancla de confianza particular. Por ejemplo, una CA de confianza puede      Sólo se puede confiar en una política de certificado particular. Esta      La restricción se puede expresar a través de las entradas al camino.      procedimiento de validación.

Sin embargo, es posible que termine con un dolor severo; por ejemplo, si las extensiones de la política en el certificado de CA indican que debe ser verificada por CRL o OSCP, entonces es posible que tenga un bloqueo legítimo en su aplicación cuando no se puede encontrar la CA raíz para verificar partes de este proceso; por ejemplo, las CRL pueden estar firmadas por la CA raíz, por lo que si la CA raíz no está disponible en el almacén de confianza, es posible que la aplicación no pueda manejar la situación.

Parece que, de acuerdo con el RFC, debería poder configurar un certificado de CA intermedio que puede actuar como un ancla de confianza y debería poder crear un conjunto de configuraciones de políticas que funcionen. Sin embargo, puedo decir por experiencia que ha entrado en el dudoso reino de "tal vez". Está proponiendo una configuración no estándar aquí que no es la típica. La mayoría de las veces, la CA raíz se usa aquí porque es la cosa de mayor nivel que existe y, a largo plazo, el aprovisionamiento del ancla de confianza suele ser lo suficientemente velludo como para que la gente esté feliz de contar con el poder más confiable y evitar la necesidad de agregar nuevos CAs a la aplicación con el tiempo. El dominio de configurar correctamente las extensiones de políticas y hacer que la aplicación funcione es Advanced PKI Vodoo: los mensajes de error son a menudo absurdos, el soporte técnico es mínimo y puede llevar bastante tiempo lograr que funcione correctamente.

Es probable que se trate de un defecto de implementación, en lugar de una decisión de diseño deliberada.

Conceptualmente, si agrega el certificado de CA intermedio a su conjunto de anclajes de confianza (CA en los que confía y, por lo tanto, aceptará el material firmado por ellos), el cliente debe estar dispuesto a aceptar otros certificados firmados por ese CA, incluso si que CA no es la raíz en la cadena. Esa sería una manera eminentemente razonable para que un cliente se comporte. Sin embargo, este puede ser un caso de uso que no es muy común y que los desarrolladores de aplicaciones no consideraron, por lo que su código podría no admitirlo. C'est la vie.

El sistema está funcionando como estaba previsto. Por definición, un certificado intermedio es emitido por, y se basa en la relación de confianza que le otorga la confianza entre el cliente y el certificado de la entidad emisora raíz. La CA raíz es autofirmada y es de confianza para el cliente, la CA intermedia está firmada por la CA raíz.

En términos simples, la CA intermedia dice "hey, soy una CA, puedes confiar en mí porque estoy firmada por la CA raíz en la que ya confías". Luego, el cliente ve si realmente confía en la CA raíz y si se ha establecido esa relación de confianza, se valida la jerarquía de certificados (cadena de certificados) y se puede utilizar el certificado.

Al usar ciertos campos y métodos (plantillas de certificado, OID, campo de Uso mejorado de clave, etc.) puede especificar para qué sirve un certificado determinado, pero todo el esquema se basa en que el cliente confíe en la raíz de la cadena de certificados.