¿Puedo usar pines de clave pública con LetsEncrypt?

¿Puedo configurar Public-Key-Pins cuando configuro un cronjob para renovar el certificado LetsEncrypt cada 30 días?

Si se renueva el certificado, también se renueva el Public-Key-Pin, ¿verdad?

Algunas palabras de precaución para comenzar:

• Sepa lo que está haciendo, si planea implementar HPKP.
• Si no lo hace bien, o "si suceden cosas malas", que no están bajo su control, podría inutilizar su dominio.
• Asegúrese de probar su configuración con un dominio que no sea tan importante, o con un tiempo de caché muy corto, como diez segundos, por ejemplo.
• Piensa en los certificados que te gustaría fijar: raíz, intermedio, hoja ...
• Piense si tiene sentido fijar otra autoridad de certificación (de respaldo), son certificados intermedios y su certificado hoja.
• Mejor prevenir que curar: piense si tiene sentido anclar otra CA / cert de respaldo para tener dos.
• Si estos puntos y preguntas le parecen "nuevos": lea de qué se trata HPKP y las trampas y advertencias comunes, antes de implementar esto.

¿Puedo usar pines de clave pública con LetsEncrypt?

• Si.

Si se renueva el certificado, también se renueva el Public-Key-Pin, ¿verdad?

• Esto depende del certificado al que se refiera y de los certificados que fije.

Haría eco de todo lo que dijo gf_.

Sin embargo, para responder la pregunta, sí puedes.

De forma predeterminada, Let's Encrypt recrea la clave y el certificado en la renovación. Esto dificulta la implementación de HPKP si desea fijar en la hoja, lo que probablemente debería hacer en caso de cambios intermedios ( como lo hizo en marzo de 2016 ).

Entonces, tiene varias opciones en torno a esto si aún desea hacer HPKP:

1. Use su propia CSR fija en lugar del cliente estándar que crea la CSR para usted cada vez para que la clave de hoja no cambie. Esta publicación de blog explica cómo hacer esto específicamente porque el autor usa HPKP.
2. Use vencimientos cortos de HPKP y renueve dentro de ese tiempo de vencimiento y cambie la política para tener claves antiguas y nuevas antes de cambiar realmente el certificado, con tiempo suficiente para que cualquier visitante pueda recoger una nueva política.
3. Fije la raíz Let's Encrypt en lugar de la hoja o el certificado.

Acabo de implementar esto usando el cliente deshidratado con validación dns01. El enlace dns01 es certzure porque nuestro DNS está alojado en Azure.

Editar: cuando hablo de claves privadas, obviamente siempre quiero decir que solo conviertes las partes de la clave pública en pines. Las claves privadas, como su nombre indica, siempre deben permanecer privadas. Vea mi propio gancho para detalles de implementación.

Necesita una renovación de clave privada para que esto sea posible. Es decir, siempre tiene a mano la clave privada actual (llámela A) y la clave privada futura (llámela B), para que pueda agregarlas a sus pines. Entonces, en este punto, sus pines son A y B. Cuando llega el día de la renovación del certificado, la clave privada A se vuelve obsoleta y B se activa. Al mismo tiempo que obtiene una nueva clave privada futura, llámela C. Regenera su lista de pines para que ahora contenga B y C. Así es como se vuelcan sus claves privadas. deshidratado apoya esto ahora .

Además, necesita un gancho que se llama cada vez que renueva sus certificados y, por lo tanto, pasa sobre sus claves privadas. Implementé esto por mi cuenta .

Finalmente, si hago esto bien, debes asegurarte de que:

HPKP age x 2 < days between cert renewals

Por ejemplo, si su edad de HPKP es de 50 días y renueva certificados cada 30 días, un cliente que visitó su sitio el primer día se quedará con las claves privadas A y B, y usted pasará a B y C el día 31. Su el servidor tiene B y C, el cliente tiene A y B, hay una coincidencia incluso en el día 50 y el cliente abre el sitio correctamente.

PERO veamos si la edad de HPKP es de 70 días. Renuevas los certificados cada 30 días, y el cliente visitó tu sitio el primer día, así que nuevamente, solo tiene las claves privadas A y B. Pasaste a B y C el día 31, y pasaste a C y D el día 61 Su servidor tiene C y D, el cliente tiene A y B, no hay coincidencia y el cliente recibe el dedo medio desde el día 61 hasta el día 71, cuando expira su política de HPKP.

Otra opción, probablemente más segura y ciertamente mucho más simple, es usar la misma clave privada cada vez y generar una o varias claves privadas de respaldo, luego codificarlas en su configuración HPKP y terminar con eso.

Sí, es complicado y puede haber advertencias en las que no he pensado, pero a la larga veremos. Obviamente lo implementé en un subdominio acrítico con una corta (15 días) de edad de HPKP para que no cause grandes problemas.

Editar: he escrito algunos scripts para ayudarlo a configurar HPKP con Let's Encrypt y deshidratarlo usando Nginx:

HPKPinx