¿Importa el orden del nombre alternativo del sujeto para los certificados TLS?

1

Hoy me encontré con un problema y me interesa saber si el comportamiento observado es estándar o no estándar.

Tenemos varios servidores que están expuestos a través de un equilibrador de carga que atiende solicitudes https. Estos servidores utilizan certificados TLS con tres entradas de Nombre alternativo del sujeto.

Por ejemplo:

  1. myservice.mycompany.int
  2. dc1.myservice.int
  3. dc2.myservice.int

Hicimos reconstruir uno de los servidores y desplegamos un nuevo certificado en ese servidor. Las entradas de Nombre alternativo del sujeto en el nuevo certificado tenían las mismas entradas que se muestran arriba, pero en un orden diferente.

Tuvimos un sistema cliente que tuvo problemas después de que este servidor entró en el equilibrador de carga donde se producían los siguientes errores:

Caused by: javax.net.ssl.SSLHandshakeException: server certificate change is restricted during renegotiation

Llegué a la conclusión de que esto se debía al orden de las entradas de SAN cuando el sistema cliente estaba realizando una renegociación de sesión SSL y obtuvo un certificado con las entradas de SAN en un orden diferente.

¿Se supone que el orden de las entradas SAN es significativo al determinar si un certificado es equivalente para los fines de la renegociación TLS?

    
pregunta conorgriffin 18.09.2016 - 15:50
fuente

1 respuesta

4

El orden de los nombres alternativos del sujeto no es importante. El cliente se está quejando sobre un cambio del certificado durante la renegociación dentro de una sesión SSL existente. No importa cuál es el cambio, es decir, es suficiente que el número de serie haya sido cambiado.

Aparte de eso, podría ser un error en el cliente. Consulte ¿Qué significa “javax.net.ssl.SSLHandshakeException: el cambio de certificado del servidor está restringido durante la renegociación” y cómo evitarlo? donde la respuesta señala un error en Java7 y Java8 introducido al intentar mitigar POODLE . Según esta publicación, el error se corrigió en Java 7u85 y 8u60.

    
respondido por el Steffen Ullrich 18.09.2016 - 16:01
fuente

Lea otras preguntas en las etiquetas