Logo GNT
Actualités Tests & Guides Bons Plans
Prime Day iPhone 16 Copilot PS5 Pro Xiaomi 15 ChatGPT Tesla
Entraide Linux Autres OS Linux Debian Conseils sur l'utilisation de certificats Letsencrypt

Conseils sur l'utilisation de certificats Letsencrypt

11 réponses
Avatar
Olivier
--00000000000014e14f05b4f11068
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bonjour,

Je viens d'obtenir avec certbot mon premier certificat Letsencrypt via le
challenge DNS-01 (cf [1]).
C'est l'occasion pour moi de d̓©finir ma fa̓§on de g̓©rer ces certificats.

Pour diff̓©rentes raisons (parmi elles, celle qui consiste ̓  ̓©viter
d'installer Certbot et des identifiants sensibles sur de multiples
machines), j'imagine centraliser la gestion (cr̓©ation, renouvellement,
suppression) des certificats sur une machine unique et de m̓©caniser, si
possible, la copie de ces certificats sur les machines o̓¹ ils sont
n̓©cessaires.

Si j'ai bien compris, le fichier /etc/crond.d/certbot renouvelle tous les
certificats toutes les 12 heures:
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system &&
perl -e 'sleep int(rand(43200))' && certbot -q renew

Pourtant lors de sa cr̓©ation, mon certificat est annonc̓© comme valide
jusqu'au 2021-02-23


1. Que pensez-vous de centraliser la gestion des certificats ?
2. Que conseillez-vous pour la fr̓©quence de renouvellement ?
3. Est-il possible de disposer simultan̓©ment d'un certificat wildcard
*.mondomaine.tld et d'un autre foo.mondomaine.tld ?
4. Quels usages l̓©gitimes pour un certificat wildcard, quand on peut cr̓©er
rapidement un nouveau certificat et qu'on veut pouvoir les r̓©pudier au cas
par cas ?
5. Comment sauvegarder la machine avec laquelle on g̓¨re ses certificats ?

[1] https://buzut.net/certbot-challenge-dns-ovh-wildcard/

Slts

--00000000000014e14f05b4f11068
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div>Bonjour,</div><div><br></div><div>Je viens d&#39;obtenir avec certbot mon premier certificat Letsencrypt via le challenge DNS-01 (cf [1]).</div><div>C&#39;est l&#39;occasion pour moi de d̓©finir ma fa̓§on de g̓©rer ces certificats.</div><div><br></div><div>Pour diff̓©rentes raisons (parmi elles, celle qui consiste ̓  ̓©viter d&#39;installer Certbot et des identifiants sensibles sur de multiples machines), j&#39;imagine centraliser la gestion (cr̓©ation, renouvellement, suppression) des certificats sur une machine unique et de m̓©caniser, si possible, la copie de ces certificats sur les machines o̓¹ ils sont n̓©cessaires.</div><div><br></div><div>Si j&#39;ai bien compris, le fichier /etc/crond.d/certbot renouvelle tous les certificats toutes les 12 heures:</div><div>0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system &amp;&amp; perl -e &#39;sleep int(rand(43200))&#39; &amp;&amp; certbot -q renew</div><div><br></div><div>Pourtant lors de sa cr̓©ation, mon certificat est annonc̓© comme valide jusqu&#39;au 2021-02-23</div><div><br></div><div><br></div><div>1. Que pensez-vous de centraliser la gestion des certificats ?</div><div>2. Que conseillez-vous pour la fr̓©quence de renouvellement ?</div><div>3. Est-il possible de disposer simultan̓©ment d&#39;un certificat wildcard *.mondomaine.tld et d&#39;un autre foo.mondomaine.tld ?</div><div>4. Quels usages l̓©gitimes pour un certificat wildcard, quand on peut cr̓©er rapidement un nouveau certificat et qu&#39;on veut pouvoir les r̓©pudier au cas par cas ?</div><div>5. Comment sauvegarder la machine avec laquelle on g̓¨re ses certificats ?<br></div><div><br></div><div>[1] <a href="https://buzut.net/certbot-challenge-dns-ovh-wildcard/">https://buzut.net/certbot-challenge-dns-ovh-wildcard/</a></div><div><br></div><div>Slts<br></div></div>

--00000000000014e14f05b4f11068--
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Daniel Caillibaud
Le 25/11/20 Í  17h38, Olivier a écrit :
Bonjour,
Je viens d'obtenir avec certbot mon premier certificat Letsencrypt via le
challenge DNS-01 (cf [1]).
C'est l'occasion pour moi de définir ma façon de gérer ces certificats.
Pour différentes raisons (parmi elles, celle qui consiste Í  éviter
d'installer Certbot et des identifiants sensibles sur de multiples
machines),

Il n'y a rien de sensible sur la machine qui lance certbot.
J'utilise certbot sur chaque frontal https, lorque je veux ajouter un vhost
foo.mondomaine.tld
- j'ajoute foo dans le dns de mondomaine.tld (seulement une entrée A, pour
pointer sur le bon frontal web)
- je génère le premier certificat manuellement (sur le frontal concerné)
avec la commande
certbot certonly --rsa-key-size 4096 --webroot -w /var/www/certbot -d
foo.mondomaine.tld
(plusieurs -d possibles)
- je crée la conf nginx du vhost avec ce certif
et ensuite ça roule tout seul…
J'ai juste ajouté un override systemd pour ne faire le check qu'une fois par nuit
et pour appeler un hook maison afin d'être prévenu Í  chaque renouvellement.
Pour que ça fonctionne, j'ai une règle nginx sur le http_default (le vhost
est pas encore créé car j'ai pas encore le certif)
location ~ ^/.well-known/acme-challenge {
root /var/www/certbot;
}
(le user qui lance la commande certbot doit avoir les droits d'écriture sur
/var/www/certbot, pour que LE retrouve ses petits dans ce dossier lorsqu'il
fait sa vérif)
j'imagine centraliser la gestion (création, renouvellement,
suppression) des certificats sur une machine unique et de mécaniser, si
possible, la copie de ces certificats sur les machines o͹ ils sont
nécessaires.
Si j'ai bien compris, le fichier /etc/crond.d/certbot renouvelle tous les
certificats toutes les 12 heures:
0 */12 * * * root test -x /usr/bin/certbot -a ! -d /run/systemd/system &&
perl -e 'sleep int(rand(43200))' && certbot -q renew

non, il regarde toutes les 12 heures s'il faut le renouveler.
Pourtant lors de sa création, mon certificat est annoncé comme valide
jusqu'au 2021-02-23

Oui, c'est 3 mois, et certbot va le renouveler 20j avant l'échéance.
1. Que pensez-vous de centraliser la gestion des certificats ?

Pas très bien compris, amha c'est plus compliqué.
2. Que conseillez-vous pour la fréquence de renouvellement ?

Ça c'est pas toi qui choisit, c'est LE qui impose 3 mois de validité.
3. Est-il possible de disposer simultanément d'un certificat wildcard
*.mondomaine.tld et d'un autre foo.mondomaine.tld ?

Je crois pas que LE propose de wildcard, mais tu peux lister autant de
domaines que tu veux dans le même certif (pas forcément tous des sous-domaines
du même domaine).
4. Quels usages légitimes pour un certificat wildcard, quand on peut créer
rapidement un nouveau certificat et qu'on veut pouvoir les répudier au cas
par cas ?

Pas bien compris, j'utilise toujours un certif par sous-domaine et j'en ai
jamais répudié, mais je suppose que tu répudie le certif global et que tu
en recrée un nouveau avec la même chose sauf ce que tu veux répudier.
5. Comment sauvegarder la machine avec laquelle on gère ses certificats ?

Comme n'importe quelle autre machine, mais j'ai probablement pas compris la question.
[1] https://buzut.net/certbot-challenge-dns-ovh-wildcard/

Ça me paraÍ®t bien compliqué, pour ma part j'installe le paquet debian certbot et
rien d'autre, et c'est hors de question de lui filer un droit de modif sur mes dns
ou ma conf nginx.
--
Daniel
Plus je grossis, plus je m'aigris.
Philippe Geluck, Le chat
Avatar
Sébastien Dinot
Olivier a écrit :
Si j'ai bien compris, le fichier /etc/crond.d/certbot renouvelle tous
les certificats toutes les 12 heures:

Non, il vérifie toutes les 12 heures si ces certificats doivent être
renouvelés. Les certificats générés par Let's Encrypt ont une durée de
validité de 3 mois, mais Certbot les renouvèle au bout de 2 mois (Í 
moins qu'on ne réduise le paramètre renew_before_expiry et qu'on ramène
le délai par exemple Í  7 jours).
Pourtant lors de sa création, mon certificat est annoncé comme valide
jusqu'au 2021-02-23

C'est normal pour un certificat créé le 2020-11-23.
1. Que pensez-vous de centraliser la gestion des certificats ?

Bof, beaucoup de complications pour rien. Le seul cas de figure o͹ la
chose est intéressante, c'est lorsqu'on veut confier Í  Let's Encrypt la
création de certificats pour des machines qui ne sont pas exposées (seul
leur nom étant alors publié dans la zone DNS publique). Le «Â proxy »
public dialogue alors avec les serveurs de Let's Encrypt et un outil
maison distribue ensuite les certificats sur les machines qui en ont
besoin en interne (et bien évidemment, dans ce cas, la résolution DNS
interne ne donne pas le même résultat que la résolution DNS externe).
2. Que conseillez-vous pour la fréquence de renouvellement ?

Ils ne sont valides que 3 mois et il me semble inutile de vouloir les
renouveler toutes les semaines. Pour ma part, je ramène juste le délai
de renouvèlement avant échéance de 30 Í  7 jours.
3. Est-il possible de disposer simultanément d'un certificat wildcard
*.mondomaine.tld et d'un autre foo.mondomaine.tld ?

Je n'ai jamais essayé, mais je pense que Certbot braille dans ce cas.
4. Quels usages légitimes pour un certificat wildcard, quand on peut
créer rapidement un nouveau certificat et qu'on veut pouvoir les
répudier au cas par cas ?

Dans les infrastructures cloud élastiques, pour lesquelles on ne connait
pas Í  l'avance le nombre de serveurs et la ventilation des services.
Mais dans ce cas, on réserve souvent le wildcard Í  un sous domaine. Par
exemple :
www.domain.tld
gitlab.domain.tld
*.cloud.domain.tld
(et non *.domain.tld)
5. Comment sauvegarder la machine avec laquelle on gère ses
certificats ?

Comme toute autre machine, en n'oubliant pas de sauvegarder le
répertoire /etc/letsencrypt. ;)
Sébastien
--
Sébastien Dinot,
http://www.palabritudes.net/
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Avatar
Olivier
--000000000000af893a05b4fd8408
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Merci ̓  tous pour ces pr̓©cieux ̓©l̓©ments de r̓©ponse.
Je n'avais visiblement pas compris le r̓´le de /etc/cron.d/certbot: c'est
compris maintenant.
Pour la centralisation de la gestion, je me rends compte qu'elle est
probablement handicapante pour une machine publique dont le certificat est
renouvelable par le challenge HTTP-01.
Encore merci.
--000000000000af893a05b4fd8408
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote">Merci ̓  tous pour ces pr̓©cieux ̓©l̓©ments de r̓©ponse.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Je n&#39;avais visiblement pas compris le r̓´le de /etc/cron.d/certbot: c&#39;est compris maintenant.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Pour la centralisation de la gestion, je me rends compte qu&#39;elle est probablement handicapante pour une machine publique dont le certificat est renouvelable par le challenge HTTP-01.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Encore merci.<br></div></div>
--000000000000af893a05b4fd8408--
Avatar
raphael.poitevin
Bonjour,
Sébastien Dinot writes:
Bof, beaucoup de complications pour rien. Le seul cas de figure o͹ la
chose est intéressante, c'est lorsqu'on veut confier Í  Let's Encrypt la
création de certificats pour des machines qui ne sont pas exposées (seul
leur nom étant alors publié dans la zone DNS publique). Le «Â proxy »
public dialogue alors avec les serveurs de Let's Encrypt et un outil
maison distribue ensuite les certificats sur les machines qui en ont
besoin en interne (et bien évidemment, dans ce cas, la résolution DNS
interne ne donne pas le même résultat que la résolution DNS externe).

Petite question ͠ ce sujet : est-ce que le reverse proxy en front auquel
on accède en https renvoie bien les informations chiffrées Í  la machine
cible, sur la quelle je n’ai pas installé le certificat ?
Dans mon nginx, j’ai par exemple :
upstream sous-domaine.example.fr {
server 192.168.x.x;
}
et bien sÍ»r le bloc habituel pour écouter sur le 443 et rediriger.
En résumé, est-ce que si on sniffe dans mon réseau interne on verra en
clair ?
C’est juste pour ma gouverne. Tout seul Í  la maison je ne risque pas
grand chose, surtout avec ce que je fais. :-)
Cordialement,
--
Raphaël
www.leclavierquibave.fr
Avatar
Sébastien Dinot
Raphaël POITEVIN a écrit :
Sébastien Dinot writes:
Bof, beaucoup de complications pour rien. Le seul cas de figure o͹
la chose est intéressante, c'est lorsqu'on veut confier Í  Let's
Encrypt la création de certificats pour des machines qui ne sont pas
exposées (seul leur nom étant alors publié dans la zone DNS
publique). Le «Â proxy » public dialogue alors avec les serveurs de
Let's Encrypt et un outil maison distribue ensuite les certificats
sur les machines qui en ont besoin en interne (et bien évidemment,
dans ce cas, la résolution DNS interne ne donne pas le même résultat
que la résolution DNS externe).

Petite question ͠ ce sujet : est-ce que le reverse proxy en front
auquel on accède en https renvoie bien les informations chiffrées Í  la
machine cible, sur la quelle je n’ai pas installé le certificat ?

J'ai peur de ne pas avoir compris la question ou de m'être mal expliqué
dans mon message initial. Il ne s'agit pas ici de mettre en place un
(reverse) proxy. Mais seulement une machine mandataire, exposée
publiquement et dont la seule fonction est le renouvèlement des
certificats. Ces certificats sont ensuite distribués aux machines qui en
ont besoin sur le réseau interne. Une rapide recherche sur Internet
vient de me montrer qu'il existe pas mal d'articles sur le sujet sur le
net, de qualité inégale. Celui-ci me semble pas mal :
https://geontech.com/using-letsencrypt-ssl-internally/
J'ai évoqué cette solution car, par design, Let's Encrypt ne peut pas
être utilié pour gérer les certificats d'un réseau interne.
Sébastien
--
Sébastien Dinot,
http://www.palabritudes.net/
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Avatar
raphael.poitevin
Sébastien Dinot writes:
J'ai peur de ne pas avoir compris la question ou de m'être mal expliqué
dans mon message initial. Il ne s'agit pas ici de mettre en place un
(reverse) proxy. Mais seulement une machine mandataire, exposée
publiquement et dont la seule fonction est le renouvèlement des
certificats. Ces certificats sont ensuite distribués aux machines qui en
ont besoin sur le réseau interne. Une rapide recherche sur Internet

ah oui d’accord, j’ai compris.
vient de me montrer qu'il existe pas mal d'articles sur le sujet sur le
net, de qualité inégale. Celui-ci me semble pas mal :
https://geontech.com/using-letsencrypt-ssl-internally/

Merci.
J'ai évoqué cette solution car, par design, Let's Encrypt ne peut pas
être utilié pour gérer les certificats d'un réseau interne.

En effet.
Avatar
Daniel Caillibaud
Le 26/11/20 Í  11h07, (Raphaël POITEVIN) a écrit :
Petite question ͠ ce sujet : est-ce que le reverse proxy en front auquel
on accède en https renvoie bien les informations chiffrées Í  la machine
cible, sur la quelle je n’ai pas installé le certificat ?

Non
Dans mon nginx, j’ai par exemple :
upstream sous-domaine.example.fr {
server 192.168.x.x;
}
et bien sÍ»r le bloc habituel pour écouter sur le 443 et rediriger.
En résumé, est-ce que si on sniffe dans mon réseau interne on verra en
clair ?

Oui
--
Daniel
Nous n'héritons pas la terre de nos ancêtres,
nous l'empruntons Í  nos enfants.
Seattle (chef indien)
Avatar
raphael.poitevin
Daniel Caillibaud writes:
En résumé, est-ce que si on sniffe dans mon réseau interne on verra en
clair ?

Oui

Merci, je m’en doutais un peu.
--
Raphaël
www.leclavierquibave.fr
Avatar
fra-duf-no-spam
Le 18591ième jour après Epoch,
Olivier écrivait:
Bonjour,
Je viens d'obtenir avec certbot mon premier certificat Letsencrypt via le
challenge DNS-01 (cf [1]).

Bravo !
Pour différentes raisons (parmi elles, celle qui consiste Í  éviter
d'installer Certbot et des identifiants sensibles sur de multiples
machines),

certbot n'est pas gourmand en mémoire et CPU, et il n'y a pas
d'identifiants particuliers qui lui sont associés.
Si j'ai bien compris, le fichier /etc/crond.d/certbot renouvelle tous les
certificats toutes les 12 heures:
0 */12 * * * root test -x /usr/bin/certbot -a ! -d /run/systemd/system &&
perl -e 'sleep int(rand(43200))' && certbot -q renew

Non, il vérifie si ça doit ou non être renouvellé. Tu peux (mais est-ce
nécessaire) modifier cette fréquence pour le faire tous les mois si tu
veux, Í  condition que ta machine soit active Í  ce moment-lÍ .
1. Que pensez-vous de centraliser la gestion des certificats ?

C'est un choix personnel. Je suis plutÍ´t dans la politique "chacun sa
merde", et ça m'évite un SPOF sur la machine qui renouvelle.
2. Que conseillez-vous pour la fréquence de renouvellement ?

Le out-of-the-box est très bien, non?
3. Est-il possible de disposer simultanément d'un certificat wildcard
*.mondomaine.tld et d'un autre foo.mondomaine.tld ?
4. Quels usages légitimes pour un certificat wildcard, quand on peut créer
rapidement un nouveau certificat et qu'on veut pouvoir les répudier au cas
par cas ?

Jamais joué avec les wildcards pour le moment, et jamais eu besoin de
répudier un certif.
5. Comment sauvegarder la machine avec laquelle on gère ses
certificats ?

Euh ... Pareil que pour le serveur postgreSQL ou nginx ? Ou bien un truc
m'échappe ?
Avatar
Stéphane Rivière
Bonjour Sébastien,
J'arrive certainement après la bataille mais acmemgr.sh, compagnon de
acme.sh pourrait répondre Í  ta demande... En tout cas, chez nous, c'est
ainsi qu'on l'utilise... et ce pourquoi il a été conçu. La doc et les
diagrammes sont assez explicites mais tu peux toujours demander des
précisions par [MP]...
https://github.com/sowebio/acmemgr.sh
Le 26/11/2020 Í  12:13, Sébastien Dinot a écrit :
Raphaël POITEVIN a écrit :
Sébastien Dinot writes:
Bof, beaucoup de complications pour rien. Le seul cas de figure o͹
la chose est intéressante, c'est lorsqu'on veut confier Í  Let's
Encrypt la création de certificats pour des machines qui ne sont pas
exposées (seul leur nom étant alors publié dans la zone DNS
publique). Le «Â proxy » public dialogue alors avec les serveurs de
Let's Encrypt et un outil maison distribue ensuite les certificats
sur les machines qui en ont besoin en interne (et bien évidemment,
dans ce cas, la résolution DNS interne ne donne pas le même résultat
que la résolution DNS externe).

Petite question ͠ ce sujet : est-ce que le reverse proxy en front
auquel on accède en https renvoie bien les informations chiffrées Í  la
machine cible, sur la quelle je n’ai pas installé le certificat ?

J'ai peur de ne pas avoir compris la question ou de m'être mal expliqué
dans mon message initial. Il ne s'agit pas ici de mettre en place un
(reverse) proxy. Mais seulement une machine mandataire, exposée
publiquement et dont la seule fonction est le renouvèlement des
certificats. Ces certificats sont ensuite distribués aux machines qui en
ont besoin sur le réseau interne. Une rapide recherche sur Internet
vient de me montrer qu'il existe pas mal d'articles sur le sujet sur le
net, de qualité inégale. Celui-ci me semble pas mal :
https://geontech.com/using-letsencrypt-ssl-internally/
J'ai évoqué cette solution car, par design, Let's Encrypt ne peut pas
être utilié pour gérer les certificats d'un réseau interne.
Sébastien

--
Stéphane Rivière
Ile d'Oléron - France
1 2