Root cert carece de CN

0

La CA interna de una empresa ha emitido un certificado de firmante raíz (no hay un certificado intermedio que actúa como firmante) en el que el DN solo contiene los campos C = US y O = company_name y ningún otro DN.

El certificado firmado por esta raíz se usa para una instancia de IBM MQ, por lo que las cosas que se conectan a él no están comparando el CN con el URI. El único valor de SAN presente coincide con la etiqueta de certificado en el almacén de claves, que IBM toma como valor predeterminado ibmwebspheremq[qmgrname] , por lo que la SAN no coincidirá con el URI, el nombre de QMgr o cualquier otra cosa que un solicitante de conexión esperaría.

  • Las aplicaciones JEE que se conectan a este servidor mediante una variedad de proveedores de JEES no se quejan.
  • La validación de OpenSSL usando s_client es exitosa.
  • IBM GSKit no puede validar el certificado personal en el KDB local (formato de almacén de claves de IBM) usando este firmante. El error cita a An invalid basic constraint extension was found con el GSKM_VALIDATIONFAIL_SUBJECT citando el Nombre del Emisor y el Emisor, pero los muestra con valores idénticos.

Me pregunto si este DN, en particular el CN faltante, se considera no conforme. O, más concretamente, obviamente funciona con algunos proveedores de criptografía, pero ¿debería esperar que falle con cualquiera que valide de forma más estricta?

    
pregunta T.Rob 25.10.2018 - 18:55
fuente

1 respuesta

3
  

Me pregunto si este DN, en particular el CN faltante, se considera no conforme.

¿No cumple con respecto a qué? Echemos un vistazo a algunas cosas que pueden o no cumplir.

X.509

Cumple con la especificación X.509: de RFC 5280 sección 4.2.1.6 Asunto ( cursiva mia):

  

Si el sujeto es un CA (por ejemplo, la extensión de las restricciones básicas, como se explica en la Sección 4.2.1.9, está presente y el valor de cA es VERDADERO), el campo del sujeto DEBE rellenarse con un [X.500] nombre distinguido [DN] que coincide con el contenido del campo del emisor.

y O=company_name,C=US es un X.500 DN válido, por lo que no hay incumplimiento.

TLS 1.2

No estoy familiarizado con RFC 5246 , pero parece indicar que el servidor Los certificados deben ser validados por el cliente, pero lo deja completamente en manos del proveedor para decidir cómo hacerlo. Así que tampoco hay incumplimiento allí.

CA / Foro del navegador

Los Requisitos de referencia de CA / B proporcionan los criterios para que los certificados sean aceptables para un navegador web sin arrojar errores.

No citaré directamente porque es un documento extenso con muchas referencias a atributos de Sujeto y SAN, pero esto coincide con su entendimiento de que el nombre de dominio completo (FQDN) debe estar en el DN o en un SAN. . ¡Así que hemos encontrado algo con lo que su certificado de IBM no cumple!

Resumen: Si intentó conectarse a una página HTTPS protegida por ese certificado, su navegador arrojaría correctamente una gran cantidad de errores porque ese certificado no cumple con los requisitos de referencia de CA / B.

Para cualquier otro uso de TLS, está totalmente bien. De hecho, si el propósito es certificar que se trata de un servidor de IBM operado por company_name , entonces la verificación de la CA raíz y una SAN específica de IBM parece ser una forma adecuada de hacerlo. (Con ese objetivo, ¿importa cuál es el nombre de host del cuadro o la URL que usaste para acceder a él?)

    
respondido por el Mike Ounsworth 25.10.2018 - 19:25
fuente

Lea otras preguntas en las etiquetas