Puis-je utiliser des clés publiques avec LetsEncrypt?

Puis-je configurer Public-Key-Pins lorsque je configure un cronjob pour renouveler le certificat LetsEncrypt tous les 30 jours?

Si le certificat est renouvelé, la clé publique est également renouvelée, n'est-ce pas?

Quelques mots de prudence pour commencer:

• Sachez ce que vous faites, si vous prévoyez de mettre en œuvre HPKP.
• Si vous ne le faites pas correctement ou "si de mauvaises choses se produisent", qui ne sont pas sous votre contrôle, vous risquez de rendre votre domaine inutilisable.
• Assurez-vous de tester votre configuration avec un domaine qui n'est pas si important, ou avec un temps de cache très court, comme dix secondes par exemple.
• Pensez aux certificats que vous souhaitez épingler: racine, intermédiaire, feuille ...
• Réfléchissez s'il est logique d'épingler une autre autorité de certification (de sauvegarde), ce sont des certificats intermédiaires et votre certificat feuille.
• Mieux vaut prévenir que guérir: pensez s'il est logique d'épingler une autre autorité de certification / certification de sauvegarde, pour en avoir deux.
• Si ces points et ces questions vous paraissent «nouveaux»: lisez en quoi consiste HPKP et les pièges et avertissements courants avant de les mettre en œuvre.

Puis-je utiliser des clés publiques avec LetsEncrypt?

• Oui.

Si le certificat est renouvelé, la clé publique est également renouvelée, n'est-ce pas?

• Cela dépend du certificat auquel vous faites référence et du ou des certificats que vous épinglez.

Serait l'écho de tout ce que gf_ a dit.

Cependant, pour répondre à la question, oui, vous le pouvez.

Par défaut, Let's Encrypt recrée la clé et le certificat au renouvellement. Cela rend la mise en œuvre de HPKP difficile si vous souhaitez épingler la feuille, ce que vous devriez probablement faire en cas de changements intermédiaires ( comme ce fut le cas en mars 2016 ).

Vous avez donc plusieurs options à ce sujet si vous voulez toujours faire HPKP:

1. Utilisez votre propre CSR fixe plutôt que le client standard qui crée le CSR pour vous à chaque fois afin que la clé feuille ne change pas. Ce billet de blog explique comment procéder spécifiquement parce que l'auteur utilise HPKP.
2. Utilisez des expirations HPKP courtes et renouvelez dans ce délai d'expiration et modifiez la politique pour avoir à la fois les anciennes et les nouvelles clés avant de changer le certificat, avec suffisamment de temps pour que la nouvelle politique soit récupérée par les visiteurs.
3. Épinglez la racine Let's Encrypt au lieu de la feuille ou du certificat.

Je viens de l'implémenter en utilisant le client déshydraté avec validation dns01. Le hook dns01 est certzure car notre DNS est hébergé dans Azure.

Edit: quand je parle de clés privées, évidemment, je veux toujours dire que vous ne transformez que les parties de clé publique en broches. Les clés privées, comme son nom l'indique, doivent toujours rester privées. Voir mon propre crochet pour les détails d'implémentation.

Vous avez besoin d'un roulement de clé privée pour rendre cela possible. Autrement dit, vous avez toujours la clé privée actuelle (appelez-la A) et la future clé privée (appelez-la B) à portée de main, afin que vous puissiez les ajouter à vos épingles. Donc, à ce stade, vos broches sont A et B. Lorsque le jour du renouvellement du certificat arrive, la clé privée A devient obsolète et B devient active. En même temps, vous obtenez une nouvelle future clé privée, appelez-la C. Vous régénérez votre liste de broches alors maintenant elle contient B et C. C'est donc comme ça que vous faites rouler vos clés privées. déshydraté le supporte maintenant .

De plus, vous avez besoin d'un hook qui est appelé à chaque fois que vous renouvelez vos certificats et que vous retrouvez ainsi vos clés privées. Je l'ai implémenté par moi-même .

Enfin, si je comprends bien, vous devez vous assurer que:

HPKP age x 2 < days between cert renewals

Par exemple, si votre âge HPKP est de 50 jours et que vous renouvelez les certificats tous les 30 jours, un client qui a visité votre site le premier jour sera bloqué avec les clés privées A et B, et vous êtes passé à B et C au 31e jour. le serveur a B et C, le client a A et B, il y a une correspondance même le jour 50 et le client ouvre correctement le site.

MAIS voyons si l'âge HPKP est de 70 jours. Vous renouvelez les certificats tous les 30 jours et le client a visité votre site le premier jour. Encore une fois, il n'a que les clés privées A et B. Votre serveur a C et D, le client a A et B, il n'y a pas de correspondance et le client reçoit le majeur du jour 61 au jour 71, lorsque sa politique HPKP expire.

Une autre option, probablement plus sûre et certainement beaucoup plus simple, consiste à utiliser la même clé privée à chaque fois et à générer une ou plusieurs clés privées de sauvegarde, puis à les coder en dur dans votre configuration HPKP et à en finir avec.

Oui, c'est délicat et il pourrait y avoir des mises en garde auxquelles je n'ai pas pensé, mais nous verrons à long terme. Évidemment, je l'ai déployé sur un sous-domaine non critique avec un âge HPKP court (15 jours) afin qu'il ne cause pas d'énormes problèmes.

Edit: J'ai écrit quelques scripts pour vous aider à configurer HPKP avec Let's Encrypt et déshydraté à l'aide de Nginx:

HPKPinx