Re: Conseils sur l'utilisation de certificats Letsencrypt
Bonjour Stéphane, Stéphane Rivière a écrit : > 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 Ce projet semble fort intéressant en effet, je vais l'étudier de près. Merci pour ce retour. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Conseils sur l'utilisation de certificats Letsencrypt
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
Re: Conseils sur l'utilisation de certificats Letsencrypt
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 ?
Re: Conseils sur l'utilisation de certificats Letsencrypt
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
Re: Conseils sur l'utilisation de certificats Letsencrypt
Le 26/11/20 à 11h07, raphael.poite...@gmail.com (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)
Re: Conseils sur l'utilisation de certificats Letsencrypt
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.
Re: Conseils sur l'utilisation de certificats Letsencrypt
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, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Conseils sur l'utilisation de certificats Letsencrypt
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
Re: Conseils sur l'utilisation de certificats Letsencrypt [RESOLU]
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.
Re: Conseils sur l'utilisation de certificats Letsencrypt
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, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Conseils sur l'utilisation de certificats Letsencrypt
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
Conseils sur l'utilisation de certificats Letsencrypt
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
