Certbot: Comment activer ACMEv2 et la récupération des certificats génériques ?

Vous devez utiliser le défi DNS-01 . Ce qui signifie que vous devez avoir un moyen de modifier et de publier et de mettre à jour la zone DNS depuis votre serveur.

Pourriez-vous s'il vous plaît me dire le drapeau pour cela?

Ce n'est pas seulement un drapeau, mais tout est disponible dans la doc. Ce sont des plugins pour plusieurs fournisseurs DNS répertoriés ici, si le vôtre n'est pas le vôtre, vous pouvez ouvrir une demande de fonctionnalité ici pour demander de l'aide (il y en a déjà des ouverts pour des choses comme Gandi par exemple, alors assurez-vous d'utiliser la recherche avant d'ouvrir un nouveau).

Hum non, vous avez besoin de certbot >= 0.22 en fait, désolé d'avoir raté ça dans votre premier post.

OK.... Comment dois-je procéder pour l'installer ? Dois-je compiler à partir des sources ?

Vous pouvez soit attendre qu'il soit publié dans le PPA , l'installer via pip ou quelque chose de similaire ou bien le créer à partir de la source.

Serais-je vous, je préfère attendre que le package officiel soit mis à jour. Cela vous laissera un peu de temps pour regarder correctement la configuration du défi DNS, que vous pouvez déjà essayer sans caractère générique juste pour vérifier que tout fonctionne, puis lorsque la mise à jour sera disponible (ce qui ne devrait pas prendre longtemps), vous serez prêt à obtenez votre certificat générique.

Oui, vous pouvez utiliser certbot à partir de sources

root<strong i="6">@cs12</strong>:~# git clone https://github.com/certbot/certbot
...
root<strong i="7">@cs12</strong>:~# DOMAIN=example.com
root<strong i="8">@cs12</strong>:~# cd certbot 
root<strong i="9">@cs12</strong>:~/certbot# ./certbot-auto certonly --manual -d *.$DOMAIN -d $DOMAIN --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
...
-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.example.com with the following value:

qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

Ajouter un enregistrement TXT, appuyez sur Entrée. Vous obtiendrez un autre enregistrement. Ajoutez-le aussi.

Vérifiez ensuite dans la deuxième fenêtre du terminal si des enregistrements ont été déployés :

root<strong i="15">@cs12</strong>:~# host -t txt _acme-challenge.example.com
_acme-challenge.example.com descriptive text "qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI"
_acme-challenge.example.com descriptive text "oMmMa-fDLlebdUhvhMD5MinJ2EeFpdP0F9lUPTShh4w"

Si tout va bien, revenez en arrière et appuyez sur Entrée

Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2018-06-11. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Mise à jour : consultez le guide complet

Merci d'avoir répondu si complètement @ArchangeGabriel ! Nous travaillons sur la mise à jour de nos packages pour Ubuntu, nous espérons qu'ils seront bientôt disponibles.

@ohemorange De rien ! Honnêtement, je craignais de voir un afflux de personnes essayant d'obtenir des certificats génériques sans avoir aucune idée de ce qu'est le défi DNS-01, mais apparemment, cela ne s'est pas produit (encore du moins).

Nice one @talyguryn , Comme suivi sur @talyguryn

Lors de la création d'un certificat sur apex avec un caractère générique, vous obtiendrez __deux__ défis.

En utilisant -d "example.com, *.example.com" _donnez-moi un certificat sur l'apex et un joker sur l'apex_

Vous serez défié _deux fois_, une fois pour example.com et encore pour *.example.com

Alors ne pensez pas que sur le deuxième défi, il a échoué.. et vous devez changer la valeur. ajoutez simplement le défi supplémentaire au DNS. Attendre la propagation et continuer,

Peut-être que la sortie devrait être modifiée pour qu'il soit plus facile de voir quel domaine est contesté ?

documents : https://sinkcup.github.io/letsencrypt-wildcard-certificate

@AubreyHewes , j'ai le même problème. Je ne sais pas comment émettre un seul certificat pour example.com et *.example.com . Malheureusement, certbot exige que je modifie l'enregistrement TXT deux fois. Cela provoque l'échec de la validation pour l'un des domaines. Y a-t-il un moyen de contourner ceci?

@nathan-alden Vous devez définir les deux enregistrements TXT en même temps. Ne supprimez pas le premier lors de l'ajout du second.

@nathan-alden
Vous obtenez deux défis. Ce _semble_ comme certbot veut que vous modifiiez à nouveau le même TXT. Mais la deuxième valeur est pour le deuxième domaine, donc ajoutez un nouvel enregistrement TXT pour le deuxième domaine.

c'est à dire
Si vous utilisez -d "example.com,*.example.com" le premier défi est pour example.com alors ajoutez un TXT pour cela. Continuer après la propagation.
Le deuxième défi est pour *.example.com alors ajoutez un TXT pour cela. Continuer après la propagation.

J'ai eu une bonne expérience avec la version docker. En remarque, assurez-vous de régler le TTL pour l'entrée TXT à quelque chose comme 1 minute afin que vous n'ayez pas à attendre une heure pour que la 2ème entrée se propage.

docker run -it --name certbot \
  -v <certs>:/etc/letsencrypt \
  -v <logs>:/var/lib/letsencrypt \
  certbot/certbot certonly --manual \ 
  -d *.<domain.com> -d <domain.com> \
  --agree-tos \
  --manual-public-ip-logging-ok \ 
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory

Se demandant. Pourquoi avons-nous besoin de dns-01 . Ne pouvez-vous pas simplement créer un serveur sur le port 80 (toute forme de défi http ) et sonder que je possède le domaine générique en générant N sous-domaines aléatoires et en vous connectant ?

@AubreyHewes , j'ai découvert que vous n'avez besoin que d'un seul défi/enregistrement dans DNS - il suffit de deviner le bon.

J'ai un certificat pour quatre domaines et leurs jokers. Chaque domaine n'a qu'un seul TXT _acme-challenge. C'est assez incohérent car trois domaines fonctionnent avec le premier défi dans la sortie de certbot et les valeurs semblent être les mêmes à chaque fois que je l'exécute.

Le quatrième domaine ne fonctionne pas avec le premier enregistrement en sortie mais fonctionne avec le second et celui-ci semble changer à chaque fois que je lance le certbot.

J'utilise cette commande :

/usr/bin/certbot --renew-by-default certonly --manual --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns-01 -w /usr/share/nginx/letsencrypt-root/ -d *.domain1.sk -d domain1.sk -d *.domain2.sk -d domain2.sk -d *.domain3.sk -d domain3.sk -d *.domain4.sk -d domain4.sk

Je l'ai fait par essais et erreurs - je ne savais tout simplement pas que vous pouviez avoir deux mêmes enregistrements DNS avec des valeurs différentes :-) La prochaine fois, j'essaierai cela.

@robertvalik Il n'est pas possible d'utiliser la même valeur d'enregistrement TXT pour deux validations différentes, y compris example.com et *.example.com .

Let's Encrypt permet de réutiliser une autorisation pendant un certain temps, actuellement 30 jours. Si votre compte a validé quelque chose récemment, il peut émettre plus de certificats sans valider à nouveau. Cependant, en raison des limitations de Certbot (#5342), Certbot vous demande de redéfinir le même enregistrement TXT , même s'il ne sera plus vérifié.

Donc, ce qui a dû se passer, c'est qu'il y avait déjà une autorisation valide pour l'un des noms, donc le fait que l'enregistrement DNS nécessaire n'existait plus n'avait plus d'importance.

@francoism90 On pourrait vouloir un domaine générique pour plusieurs raisons, on pourrait servir quelques sous-domaines statiques, d'autres, servir des sous-domaines potentiellement infinis (par exemple un logiciel en tant que service). Dans ce dernier cas (mon cas), on a déjà un caractère générique dans le fichier DNS, et en fait, tout sous-domaine aléatoire devrait être correctement résolu. Je me demande si une forme de défi http pourrait être fournie pour ce scénario. Merci pour tout votre travail acharné!

J'ai réussi à générer un certificat en émettant

./certbot-auto certonly --manual -d *.example.com -d example.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Maintenant, je me demande comment puis-je renouveler les certificats

<> certbot renew
<> certbot-renew
<> certbot-auto renew

Je suis confus, j'ai essayé ./certbot-auto renew car j'ai utilisé la même commande lors de la demande, mais je veux juste m'assurer que c'est la bonne façon.

Peut-on automatiser la certification wildcard ?

@ ufo911 Bien sûr. Par exemple, en utilisant le plugin RFC 2136 de Certbot :

certbot certonly \
  --dns-rfc2136 \
  --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

Ou le crochet d'authentification manuel acme-dns :

certbot certonly \
  --debug-challenges \
  --manual \
  --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

https://certbot.eff.org/docs/using.html
https://community.letsencrypt.org/t/getting-wildcard-certificates-with-certbot/56285

Si vous avez besoin d'aide, vous pouvez poster un sujet sur le forum Let's Encrypt .

@mnordhoff
est-il nécessaire que l'enregistrement DNS TXT soit actif à chaque renouvellement ?

@ ufo911 Bien sûr, un renouvellement n'est qu'une demande de certificat réutilisant les paramètres précédents.

@ArchangeGabriel Stange, il me dit qu'il me dit de définir de nouveaux enregistrements TXT :

#!/bin/bash
certbot certonly \
  --manual \
  --agree-tos \
  --manual-public-ip-logging-ok \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d domain.tld \
  -d "*.domain.tld"

Est-ce normal? Pourquoi de nouveaux jetons sont-ils générés ?

Désolé si je n'ai pas été clair, oui il y a un nouvel enregistrement TXT sur chaque demande. Parce qu'il s'agit d'une validation défi-réponse, et réutiliser le défi serait une très mauvaise idée.

En fait, vous pouvez supprimer l'enregistrement TXT dès que vous avez obtenu le certificat, mais il y a un nouvel enregistrement TXT à publier (et à supprimer une fois réussi) à chaque renouvellement.

@ArchangeGabriel Hmm, ne pense pas que ce soit une option pour moi. La création d'un nouvel enregistrement TXT peut prendre 24h et si quelque chose ne va pas, vous vous retrouverez avec beaucoup de temps d'arrêt.

J'utiliserai plutôt la méthode générale. :)

Bien sûr, le défi DNS n'est pas le plus simple. Mais pour le joker, il n'y a pas d'autre possibilité, du moins actuellement. Je ne sais pas si, par exemple, cela pourrait être remplacé en envoyant le défi à un nom de sous-domaine aléatoire dans l'espace générique (par exemple, si vous demandez *.domain.com , il essaierait de lire la réponse au défi à somerandomstring.domain.com pour vérifier que vous avez bien le contrôle sur tout l'espace *.domain.com ). De cette façon, avoir votre redirection générique dans DNS serait suffisant.

@ArchangeGabriel Ce serait une bonne option, mais la vérification DNS serait-elle toujours nécessaire dans ce cas ? Offre-t-il quelque chose de nécessaire pour une configuration générique sécurisée ?

Non, mon idée serait de proposer une alternative au défi DNS.

Pour une configuration générique, vous devez prouver le contrôle de tous les sous-domaines. Le seul moyen évident de le faire est de prouver la propriété technique de la zone DNS correspondante.

Maintenant, je me demande s'il pourrait y avoir un autre moyen plus semblable aux autres types de défis. Demander un sous-domaine aléatoire prouverait que vous avez le contrôle sur une redirection générique. Je ne sais pas si cela suffirait pour l'IETF, je suppose qu'ils y ont pensé et qu'il doit y avoir des problèmes.

Par exemple, je me demande si ce cas est possible :
– somespecificsub.domain.com pointe vers une IP donnée;
– *.domain.com et domain.com pointe vers une autre IP.

Dans ce cas, vous pouvez répondre aux demandes du domaine principal et de tout sous-domaine à l'exception de somespecificsub.domain.com. Et je pense qu'il ne serait pas juste de vous fournir un certificat *.domain.com. Donc, si cela est possible, nous aurions besoin d'une configuration supplémentaire. Comme un enregistrement TXT permanent indiquant qu'il est autorisé à effectuer une vérification de sous-domaine aléatoire pour la réponse au défi générique. De cette façon, la configuration DNS serait simplement infaillible et vous pourriez plus facilement valider un caractère générique.

Quoi qu'il en soit, je ne sais pas avec qui cela devrait être discuté et à quel moment ils ont envisagé cette configuration, ni quels sont les critères exacts requis pour délivrer un joker en toute sécurité. Je suppose que je devrais juste lire la RFC pour ça, mais je n'ai pas le temps pour ça.