Reemplazo de un certificado TLS cuando el anterior está anclado (HPKP)

Question

Reemplazo de un certificado TLS cuando el anterior está anclado (HPKP)

#1 de Michał Staruch (3 votos)
#2 de Geremia (0 votos)

1

Supongamos que la antigüedad máxima de mis Claves Públicas es de 60 días. ¿Cuándo puedo desplegar un nuevo certificado? 60 días a partir de ahora? Pero, ¿qué pasa con los navegadores que se conectan por primera vez a mi sitio desde ahora y dentro de 60 días?

Este sitio dice :

Cuando GitHub [quien usa HPKP] quiere reemplazar su certificado TLS, el nuevo certificado debe estar firmado por DigiCert o Symantec; de lo contrario, ninguno de los hashes clave en la nueva cadena de certificados coincidirá con la política de HPKP existente, y su Se impediría a los usuarios acceder al sitio.

Por lo tanto, no puedo implementar un nuevo certificado firmado por una CA diferente (por ejemplo, Let's Encrypt) que el que puse originalmente (por ejemplo, Verisign).

¿Es por esto que se recomienda fijar un certificado de copia de seguridad de una CA diferente?
^{cf. pag. 315 de Bulletproof SSL and TLS de Ivan Ristić (2014)}

tls webserver letsencrypt apache hpkp

pregunta Geremia 13.10.2016 - 17:29

fuente

2 respuestas

0

Lo que tienes que hacer es agregar un hash SHA-256 del nuevo certificado y cadena, además de los que ya están allí. Luego, en 60 días, puede eliminar los hashes SHA-256 de los certificados antiguos.

respondido por el Geremia 13.10.2016 - 18:15

fuente

Lea otras preguntas en las etiquetas tls webserver letsencrypt apache hpkp

¿Cómo eliminar mi correo electrónico de las listas de spam / listas negras después de un problema de malware? ¿El reenvío de puertos no es seguro? [cerrado]

score 3 · Accepted Answer

SIEMPRE debería tener dos (o más) pines en sus encabezados: uno para su certificado actual y uno (o más) para el certificado (s) de respaldo (se mantiene separado del actual, mejor sin conexión).
Si su certificado actual no se vio comprometido, no necesita tocar los pines ni emitir un nuevo certificado, simplemente puede renovar el certificado existente (pida a CA que emita un nuevo CRT con el mismo CSR que anteriormente).
Si su sistema se vio comprometido, puede cambiar al certificado de copia de seguridad que ha tenido anclado (por lo menos durante la antigüedad máxima) CUALQUIER HORA: UA lo aceptará, porque el pin es válido (antes estaba en los encabezados).
Puede solicitar a cualquier CA que sea de confianza para el cliente que firme su CSR (actual o de respaldo).
Si desea agregar un nuevo pin, debe esperar el período de vigencia máxima (generalmente 60 días) antes de usar el certificado que corresponda, para eliminar el riesgo de que la UA rechace la conexión. Vea el siguiente escenario y observe las diferencias entre los clientes X e Y:
- día 1: configura el pin A + crt A, establece la edad máxima en 60 días,
- día 2: el cliente X se conecta y aprende que A es seguro durante 60 días,
- día 3: el cliente Y se conecta y aprende que A es seguro durante 60 días,
- día 20: agregas el pin B a los encabezados,
- día 21: el cliente X se conecta (confía en A) y descubre que tanto A como B son seguros durante 60 días,
- día 40: cambias a crt B,
- día 41: el cliente X se conecta (confía en A y B),
- día 42: el cliente Y rechaza la conexión; no logró aprender un nuevo pin de A confiable (como el cliente X), por lo que rechazará todo excepto A hasta el día 63.

Si aún tiene dudas, consulte la sección 2.6. Validación de conexiones ancladas y el Apéndice B. Guía de implementación en RFC 7469 .