TLS límite de certificado de 39 meses y el error NET :: ERR_CERT_VALIDITY_TOO_LONG de Chrome

8

A finales del año pasado, el CA / Browser Forum decidió limitar el término válido máximo de certificados TLS / SSL emitidos después del 1 de abril de 2015. Después de este tiempo, como lineamientos oficiales ponlo ...

  

Las entidades emisoras de certificados NO DEBEN emitir certificados con períodos de validez superiores a 39 meses.

Recientemente he recibido (re) un certificado con un período de validez de 2015-04-07 08:57:25 GMT a 2018-07-09 07:00:18 GMT . Esto se parece mucho a 39 meses y 2 días para mí, pero cada single SSL checker I've used dice que es totalmente válido. También funciona bien en Firefox 37.0.1 e Internet Explorer 11.0.9600.

El problema es que Chrome me da un error NET::ERR_CERT_VALIDITY_TOO_LONG , un punto con el que tiendo a estar de acuerdo. Esto ocurre en las versiones 42.0.2311.68 my 44.0.2360.0 canary (64 bits).

¿Se trata de un problema con el certificado o un error en Chrome?

Más específicamente, ¿cómo se supone que se calculen los "meses" a los fines de los certificados TLS / SSL?

Tenga en cuenta que esto no debería estar relacionado con la puesta de sol de los certificados firmados SHA-1 que ocurrieron en Chrome 42 , el nuevo certificado está definitivamente firmado con SHA256.

    
pregunta Molomby 09.04.2015 - 06:08
fuente

1 respuesta

4

Debe tenerse en cuenta que no hay nada malo con los certificados desde un punto de vista TLS o x509. El foro CA / Browser se aplica a las CA que emiten certificados de confianza pública que se suscriben a esas pautas. No todos los casos de uso TLS o x509 involucran la confianza pública.

Un gobierno interno o una CA empresarial, por ejemplo, podría elegir razonablemente ignorar completamente estas pautas. De hecho, si Chrome está aplicando esas reglas estrictamente a certificados no públicos, es algo contradictorio con x509v3:

  

En algunas situaciones, a los dispositivos se les otorgan certificados para los que no funcionan.   Se puede asignar fecha de vencimiento. Por ejemplo, un dispositivo podría ser   emitió un certificado que vincula su modelo y número de serie a su   Llave pública; Dicho certificado está destinado a ser utilizado para toda la   vida útil del dispositivo.

Obviamente, Chrome no tiene la obligación de aceptar tales certificados, pero de todos modos son un tipo legítimo de certificado. Un usuario de la intranet que quiera confiar en su propia CA de la intranet (por ejemplo, Active Directory) puede encontrar que Chrome les impide hacerlo, en función de los requisitos que son irrelevantes para ellos porque no se suscriben al foro CA / Browser.

Es incorrecto decir que un certificado x509v3 no es válido porque tiene una fecha de caducidad larga en el caso general .

Es correcto decir que un certificado x509v3 no es válido porque tiene una fecha de caducidad larga cuando está siendo emitido por una ca que se espera que cumpla con los requisitos del CAB y que sea consumida por un agente de usuario que espera cumplir. a los requisitos del CAB.

Por lo tanto, es importante reconocer que no existe un mecanismo técnico intrínseco para determinar si una CA debe ser compatible con CAB o no. Por lo tanto, los navegadores se dejan a cualquiera:

a) Supongamos que las CA suscritas a CA / Browser Forum se están ajustando adecuadamente y aceptan falsos positivos si la CA no lo hace, por cualquier motivo.

b) Rechazar agresivamente los certificados que no se ajustan a los requisitos en todos los casos, independientemente de quién sea la entidad emisora de certificados, imponiendo requisitos de estilo CAB incluso cuando puedan ser activamente dañinos.

Ninguno de los dos está mal, creo ( a menos que exista un poco del CAB que impone una obligación en el navegador, no puedo afirmar que he memorizado toda la palabra palabra por palabra (véase el apéndice)) . Lo que es correcto es que los comprobadores de SSL que ha utilizado no rechazan los certificados como intrínsecamente inválidos. Sin ningún contexto, sería incorrecto decir que no eran válidos.

Los resultados que has descrito, entonces, son exactamente lo que uno podría esperar de estos requisitos y la respuesta a la pregunta "¿Es esto un problema con el certificado o un error en Chrome?" es, en mi opinión, el certificado , ya que fue emitido por una CA suscrita por CAB-forum que no implementó sus obligaciones de manera no ambigua, lo que obligó a los navegadores a tomar su propia decisión sobre si hacer cumplir esas obligaciones por veto o no.

Addendum :

  

Los requisitos no son obligatorios para las autoridades de certificación   a menos y hasta que sean adoptados y ejecutados por parte de confianza   Proveedores de software de aplicación.

Chrome (una aplicación que confía en la aplicación Sof zzzz) lo ha adoptado y lo está aplicando, por lo que, según la ley, podemos afirmar que es obligatorio para las CA que se ocupan de certificados de confianza pública y están suscritas a los requisitos del Foro CAB para crear certificados que cumplan con estos requisitos.

(A menos que estemos siendo hiper pedantes, en cuyo caso es un plural y realmente necesitaríamos más de 2 navegadores para implementarlo porque, de lo contrario, Chrome es solo un proveedor de software de aplicaciones de terceros confiables, no un proveedor .)

Creo que es divertido que las obligaciones de las CA estén realmente sujetas a cambios dependiendo de los detalles de implementación individuales en cada proveedor. En cualquier momento en que un navegador web o cualquier software asociado con el CAB en cualquier parte del mundo se actualice de forma repentina, es posible que una CA tenga que implementar un requisito que antes no tenía.

Por lo tanto, hasta que falló en Chrome, la CA no tenía la obligación de cumplir. En el momento en que Chrome fue parcheado para comenzar a cometer este error, la AC estaba incumpliendo sus obligaciones. ¡Sorpresa, MF!

    
respondido por el Rushyo 10.04.2015 - 12:23
fuente

Lea otras preguntas en las etiquetas