Posso usar Public-Key-Pins com LetsEncrypt?

Question

Posso configurar Public-Key-Pins quando configuro um cronjob para renovar o certificado LetsEncrypt a cada 30 dias?

Se o certificado for renovado, o Public-Key-Pin também será renovado?

    

Answer 1

Algumas palavras de cautela para começar:

• Saiba o que você está fazendo, se estiver planejando implementar o HPKP.
• Se você não fizer isso certo ou "se coisas ruins acontecerem", que não estão sob seu controle, você pode inutilizar seu domínio.
• Certifique-se de testar sua configuração com um domínio que não é tão importante ou com um tempo de cache muito curto, como dez segundos, por exemplo.
• Pense em quais certs você gostaria de fixar: Root, intermediário, folha ...
• Pense se faz sentido fixar outra autoridade de certificação (de backup), seus certificados intermediários e seu certificado de folha.
• É melhor prevenir do que remediar: pense se faz sentido fixar outro CA / cert de backup, para ter dois.
• Se esses pontos e perguntas soarem "novos" para você: Leia sobre o que é o HPKP e as armadilhas e advertências comuns, antes de implementar isso.

Can I use Public-Key-Pins with LetsEncrypt?

• Sim.

If the certificate is renewed then the Public-Key-Pin is also renewed right?

• Isso depende do certificado ao qual você está se referindo e de quais certificados você está atribuindo.

Answer 2

Ecoaria tudo que gf_ disse.

No entanto, para responder à pergunta, sim, você pode.

Por padrão, Let's Encrypt recria a chave e o certificado na renovação. Isso dificulta a implementação do HPKP se você quiser fixar a folha, o que você provavelmente deve fazer no caso de alterações intermediárias ( como aconteceu em março de 2016 .

Então você tem várias opções em torno disso, se ainda quiser fazer o HPKP:

1. Use seu próprio CSR fixo, em vez do cliente padrão, que cria o CSR para você a cada vez, para que a chave da folha não seja alterada. Esta postagem no blog explica como fazer isso especificamente porque o autor usa o HPKP.
2. Use expirações curtas de HPKP e renove dentro desse prazo de validade e altere a política para ter chaves antigas e novas antes de realmente alterar o certificado, com tempo suficiente para que a nova política seja escolhida por qualquer visitante.
3. Afixe o código Vamos criptografar a raiz em vez da folha ou cert.

Answer 3

Acabei de implementar isso usando o cliente desidratado com a validação dns01. O gancho dns01 é certzure porque nosso DNS está hospedado no Azure.

Editar: quando eu falo sobre chaves privadas, obviamente eu sempre digo que você só transforma as partes da chave pública em alfinetes. As chaves privadas, como o nome sugere, devem sempre permanecerem privadas. Veja meu próprio gancho para detalhes de implementação.

Você precisa de substituição de chave privada para tornar isso possível. Ou seja, você sempre tem a chave privada atual (chame de A) e a chave privada futura (chame de B), para que você possa adicioná-las aos seus pinos. Então, neste ponto, seus pinos são A e B. Quando chega o dia da renovação do certificado, a chave privada A se torna obsoleta e B torna-se ativo. Ao mesmo tempo em que você recebe uma nova chave privada futura, chame-a de C. Você regenera sua lista de alfinetes de modo que agora ela contém B e C. Então é assim que você passa suas chaves privadas. desidratado suporta isso agora .

Além disso, você precisa de um gancho que é chamado toda vez que renovar seus certificados e, assim, passar as chaves privadas. Implementei este sozinho .

Finalmente, se eu acertar, você precisa ter certeza de que:

HPKP age x 2 < days between cert renewals

Por exemplo, se sua idade de HPKP for de 50 dias e você renovar certs a cada 30 dias, um cliente que visitou seu site no primeiro dia ficará preso às chaves privadas A e B e rolou para B e C no dia 31. Seu servidor tem B e C, o cliente tem A e B, há uma correspondência mesmo no dia 50 e o cliente abre o site corretamente.

MAS, vamos ver se a idade do HPKP é de 70 dias. Você renova certs a cada 30 dias, e o cliente visitou seu site no primeiro dia, então, novamente, ele tem apenas as chaves privadas A e B. Você rolou para B e C no dia 31 e rolou para C e D no dia 61 Seu servidor tem C e D, o cliente tem A e B, não há correspondência e o cliente recebe o dedo do meio do dia 61 até o dia 71, quando a política do HPKP expira.

Outra opção, provavelmente mais segura e certamente muito mais simples, é usar a mesma chave privada toda vez e gerar uma ou várias chaves privadas de backup, e então codificá-las em sua configuração do HPKP e concluir o processo.

Sim, é complicado e pode haver advertências que eu não pensei, mas vamos ver a longo prazo. Obviamente, eu o implantei em um subdomínio acrítico com a idade de HPKP curta (15 dias) para que ele não cause grandes problemas.

Editar: eu escrevi alguns scripts para ajudar você a configurar o HPKP com o Let's Encrypt e desidratado usando o Nginx:

HPKPinx