This commit is contained in:
parent
58ff9a3edf
commit
ba95104a4e
64
content/posts/tls/dehydrated-to-certbot.md
Normal file
64
content/posts/tls/dehydrated-to-certbot.md
Normal file
|
@ -0,0 +1,64 @@
|
|||
---
|
||||
title: "De Dehydrated à Certbot"
|
||||
date: 2023-04-22T23:52:19+02:00
|
||||
draft: true
|
||||
---
|
||||
|
||||
## Le commencement
|
||||
|
||||
J'utilisais pour générer mes certificats `x509` la solution [dehydrated](https://github.com/dehydrated-io/dehydrated) dès le premier jour ou presque de mon usage avec let's encrypt.
|
||||
Du bash hyper simple pour faire le sucre nécessaire à l'obtention de certificats letsencrypt ou respectant les challenges **acme**. C'était très bien.
|
||||
|
||||
Le client officiel était quant à lui lourd peu modulaire avec peu d'extension. L'idée initial car nouveauté était :
|
||||
|
||||
> je fais tout pour toi
|
||||
|
||||
Je suis pas fan. Sérieusement, modifier les vhosts de mon serveur web, c'est un grand non.
|
||||
Les temps ont changés, des options moins intrusive éxistent et dorénavant j'utilise la rfc2136 pour obtenir mon wildcard plutôt qu'un gros `INSERT` dans ma base PostgreSQL.
|
||||
|
||||
J'ai du louper des choses car régulièrement ça ne fonctionne pas bien, surement des échappements ou autre.
|
||||
|
||||
Je pense qu'en insistant plus j'aurais fini par trouver la solution.
|
||||
Mais pourquoi ne pas essayer autre chose et (re)voir le client officiel **certbot** ?
|
||||
|
||||
## Certbot
|
||||
|
||||
La [documentation](https://eff-certbot.readthedocs.io/en/stable/using.html) utilisateur est de qualité. Passons donc à l'install.
|
||||
|
||||
### Install
|
||||
|
||||
Le client officiel *letsencrypt/acme* est en python, disponible sur PyPi. J'ai aussi besoin du plugin rfc2136, allons-y donc :
|
||||
|
||||
```bash
|
||||
pip install certbot certbot-dns-rfc2136
|
||||
```
|
||||
|
||||
Une liste plus grande des plugins disponibles via <https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins>
|
||||
|
||||
## Migration dehydrated→certbot
|
||||
|
||||
Mais pourquoi migrer ? hop on part from scratch !
|
||||
Oui mais alors non.
|
||||
Si vous n'utilisez pas `DANE-EE` mais plutôt `PKIX-EE`, OUI ne rien migrer est une bonne idée. Bon évidemment moi j'utilise `DANE-EE` car je ne souhaite pas distribuer de manière automatique la clé privée. Peut-être un jour une autre façon de faire.
|
||||
|
||||
A voir
|
||||
|
||||
### Réimport
|
||||
|
||||
Les fichiers de `dehydrated` comportent des sauts de lignes que certbot ne sait pas lire.
|
||||
Fixons cela:
|
||||
|
||||
```bash
|
||||
find . -type f -name '*.pem' | xargs sed -i '/^$/d'
|
||||
```
|
||||
|
||||
Il y a aussi une problématique sur les noms des fichiers. Il faut que ça respecte la nomenclature à savoir \<filename>XXX.\<extension> ou XXX est un chiffre.
|
||||
|
||||
Si vos certificats utilisent une clé ECDSA il faut spécifier ceci dans `cli.ini`
|
||||
|
||||
```ini
|
||||
# Use ECC for the private key
|
||||
key-type = ecdsa
|
||||
elliptic-curve = secp384r1
|
||||
```
|
||||
Et voilà
|
Loading…
Reference in a new issue