Posso usar pinos de chave pública com LetsEncrypt?

Posso configurar Pinos de Chave Pública 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, certo?

Algumas palavras de cautela para começar:

• Saiba o que você está fazendo, se planeja implementar o HPKP.
• Se você não fizer isso corretamente, ou "se coisas ruins acontecerem", que não estão sob seu controle, você poderá tornar seu domínio inutilizável.
• Teste 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 materiais você gostaria de fixar: raiz, intermediário, folha ...
• Pense se faz sentido fixar outra autoridade de certificação (de backup), são certificados intermediários e seu certificado em folha.
• Melhor prevenir do que remediar: pense se faz sentido fixar outra CA / cert de backup, para ter duas.
• Se esses pontos e perguntas parecerem "novos" para você: Leia sobre o que é o HPKP e as armadilhas e advertências comuns, antes de implementar isso.

Posso usar pinos de chave pública com LetsEncrypt?

• Sim.

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

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

Ecoaria tudo o que gf_ disse.

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

Por padrão, 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 provavelmente deve ser feito em caso de alterações intermediárias ( como ocorreu em março de 2016 ).

Então, você tem várias opções para resolver isso, se ainda deseja 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 do blog explica como fazer isso especificamente porque o autor usa o HPKP.
2. Use expirações curtas do HPKP e renove dentro desse prazo de validade e altere a política para ter chaves antigas e novas antes de alterar o certificado, com tempo suficiente para que a nova política seja escolhida por qualquer visitante.
3. Pin a raiz Vamos criptografar em vez da folha ou cert.

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

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

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

Além disso, você precisa de um gancho chamado sempre que renovar seus certificados e, assim, rolar suas chaves privadas. Eu implementei isso sozinho .

Finalmente, se eu entendi direito, você deve se certificar de que:

HPKP age x 2 < days between cert renewals

Por exemplo, se sua idade de HPKP for 50 dias e você renovar certificados a cada 30 dias, um cliente que visitou seu site no primeiro dia ficará com as chaves privadas A e B e você passou para B e C no dia 31. Seu o servidor tem B e C, o cliente tem A e B, existe uma correspondência até 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; portanto, novamente, ele só possui as chaves privadas A e B. Você passou para B e C no dia 31 e depois 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 sua política de HPKP expira.

Outra opção, provavelmente mais segura e certamente muito mais simples, é usar sempre a mesma chave privada e gerar uma ou várias chaves privadas de backup, codificando-as na sua configuração do HPKP e pronto.

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

Edit: Escrevi alguns scripts para ajudá-lo a configurar o HPKP com Let's Encrypt e desidratado usando o Nginx:

HPKPinx