Problema con OpenSSL rechazando CA posiblemente debido a un número de serie de 12 dígitos

1

Trabajo como probador en una compañía de software de VoIP. Hemos tenido problemas con el uso de TLS para comunicarnos con ciertos teléfonos. Los teléfonos son de diferentes fabricantes pero ambos presentan el mismo problema. Para resumir lo más sucintamente posible, el teléfono rechaza el certificado provisto durante el protocolo de enlace SSL con "CA desconocido".

Los teléfonos usan versiones de OpenSSL en su firmware, pero no sé qué versión.

He verificado de todas las formas posibles que el certificado de CA de confianza proporcionado al teléfono durante el aprovisionamiento y el certificado que se proporcionó al teléfono durante el protocolo de enlace son los mismos y coinciden. Todo DEBE ser dorado, sin embargo no lo es.

Lo que he encontrado es que en un sistema donde todo funciona correctamente, el certificado CA proporcionado tiene un número de serie de 10 dígitos y en el sistema donde todo no funciona, el certificado CA tiene un número de serie de 12 dígitos.

Parece una cosa tan arbitraria como la causa del rechazo del certificado, pero esa es, literalmente, la ÚNICA diferencia que puedo encontrar al comparar los sistemas que funcionan y los que no funcionan y sus certificados.

¿Esto suena como algo que alguien ha escuchado antes? ¿Me estoy volviendo loco? Cualquier y toda ayuda apreciada.

--Editar--  Nuestro PBX usa un certificado CA autofirmado de forma predeterminada. A continuación, utiliza ese certificado para firmar un certificado de línea (certificado de servidor) y también firma certificados utilizados por los teléfonos (certificado de cliente). Lo que parece estar sucediendo es que cuando se generan nuevos certificados de servidor, lo están haciendo con una serie de 10 dígitos.

Tengo la capacidad de usar certificados generados previamente (generados usando la misma metodología) que tienen publicaciones seriadas de 12 dígitos. Cuando se utiliza el certificado de servidor de 12 dígitos para completar el protocolo de enlace TLS, los teléfonos aceptan el certificado de CA de 12 dígitos. Cuando se utiliza el certificado de servidor de 10 dígitos, los teléfonos rechazan la CA de 12 dígitos como "CA desconocida". Esto parece ... completamente arbitrario e incorrecto, pero es lo que tengo.

Los nuevos certificados de 10 dígitos se generan utilizando OpenSSL 1.0.1i. Los certificados de 12 dígitos se estaban generando usando una versión anterior (0.9.7e, creo). Dudo que eso importe mucho. Un fabricante de teléfonos usa OpenSSL 0.9.7e y el otro usa OpenSSL 1.0.1c-fips

    
pregunta Dan Gentry 29.08.2014 - 21:40
fuente

2 respuestas

1

Se agregó como una respuesta al menos parcial para que pueda formatear:

Esos archivos (en el comentario a @Steffen) tienen una diferencia de codificación.

ServerGroupCertificate.cer tiene un Asunto que contiene Org y OrgUnit como PrintableString y CommonName como T61String, también conocido como TeletexString, y 12-Digit-Working.cer tiene el mismo Emisor, pero 10-Digit-Broken.cer (que también es client_cert.pem ) tiene el Emisor todo UTF8String. Si su CA (PBX) simplemente está copiando los valores de caracteres de padres a hijos, confiando en openssl para (re) calcular el tipo, ese cambió en 1.0.1h ( no se indica en CAMBIOS, lo que provocó un debate en la lista de maillist). La línea de comandos de openssl copia toda la pila de AVA, lo que preserva los tipos. También me doy cuenta de que sus certificados secundarios son la versión 3, aunque no tienen extensiones; esto es legal pero no es lo que normalmente hace la línea de comandos de openssl, lo que nuevamente sugiere un código personalizado.

Un teléfono que usa 0.9.7e probablemente también sea relevante. No tengo versiones tan antiguas para probar, pero el archivo CHANGES es acumulativo y contiene una entrada para 0.9.7f con fecha 22 de marzo de 2005:

  

*) Realice algunas comparaciones de caracteres de diferentes tipos en X509_NAME_cmp:        esto es necesario para algunos certificados que vuelven a codificar los DN en UTF8Strings        (en violación de RFC3280) y no puedo o no emitir transferencia de nombre        certificados        [Steve Henson]

Esto sugiere fuertemente que hace 10 años se conocieron casos de mal comportamiento de las AC y una versión confiable que usa 0.9.7e o anterior no pudo manejarlos. A pesar de que 3280 permitió ser más confiable para usar las reglas de concordancia más holgadas de X.500, que aparentemente sí permiten cambios de codificación, simplemente no permitía que una CA dependiera de que los rezagados lo hicieran.

Además, una herramienta confiable que utiliza el método "CAdir" de openssl puede haber tenido problemas incluso más tiempo, porque los cambios para 1.0.0 con fecha del 29 de marzo de 2010 incluyen:

  

*) Mejora el formato de hash utilizado para los enlaces de directorio de certificados. los   nuevo        La forma utiliza la codificación canónica (lo que significa que los nombres equivalentes funcionarán        incluso si no son idénticos) y usa SHA1 en lugar de MD5. Esta forma        es incompatible con el formato anterior y, como resultado, c_rehash debería        ser utilizado para reconstruir enlaces simbólicos.        [Steve Henson]

Por lo tanto, te sugiero que necesites que tus CA (s) dejen de cambiar las codificaciones de cadena en certificados de niños; o reemplace su (s) certificado (s) de CA por uno (s) cuyos campos de nombre ya sean UTF8 para comenzar, en cuyo caso, presumiblemente, la CA lo mantendrá; u obtenga los reliers (teléfonos) hasta 0.9.7f para "CAfile" o cualquier cosa que rellene de forma similar los certs en la tienda en memoria, y probablemente 1.0.0 para "CAdir" o cualquier cosa que similarmente obtenga dinámicamente los padres.

HTH.

    
respondido por el dave_thompson_085 06.09.2014 - 15:27
fuente
0

Hay muchas cosas extrañas que las personas hacen mal al usar SSL. Y aunque no lo he visto, podría ser que intenten usar el número de serie como de 32 bits, lo que significa un valor máximo de 4294967296 (o 2147483648 si se usa con signo int). Esto cabría en su descripción donde 10 dígitos están bien (al menos si está por debajo de 4294967296), pero 12 dígitos no.

Pero, sin tener más detalles sobre los certificados involucrados, esto es solo una suposición descabellada sobre lo que podría hacerse mal.

    
respondido por el Steffen Ullrich 30.08.2014 - 07:04
fuente

Lea otras preguntas en las etiquetas