EvoACME est un ensemble de scripts qui facilite la création de certificats Let's Encrypt dans le contexte d'un serveur web Evolix (Apache + Evoadmin-web).
Il cherche les fichiers `/etc/apache2/sites-enabled/example.conf`, `/etc/nginx/sites-enabled/example.conf` et `/etc/nginx/sites-enabled/example` et utilise le premier trouvé.
La variable d'environnement `DRY_RUN=1` permet un mode « dry-run » en faisant l'ensemble du process sur l'API de production, mais sans générer le certificat final (attention, cela impacte quand même le quota d'utilisation de Let's Encrypt).
La variable d'environnement `TEST=1` permet de générer un certificat non valide mais sans décompter le quota d'utilisation de Let's Encrypt. En effet les actions sont limitées et pendant les tests de mise en place il vaut mieux ne utiliser l'API de production. À enlever bien sûr pour générer le certificat final.
La variable `VERBOSE=1` permet d'afficher de nombreux messages utiles pour comprendre ce qui se passe, surtout en cas d'erreur.
Le certificat sera généré dans le dossier ` /etc/letsencrypt/example/<TIMESTAMP>/` et un fichier de configuration est généré (ou mis à jour) dans `/etc/nginx/ssl/example.conf` (pour Nginx) :
Si vous avez une re-écriture http vers https, cela ne pose de problème (Let's Encrypt n'exige pas d'avoir un certificat valide pour sa vérification) MAIS il faut s'assurer de conserver l'URL.
Par exemple la ré-écriture suivante ne convient **pas** :
~~~
RewriteRule ^/(.*) https://example.com/ [L,R]
~~~
il faut avoir :
~~~
RewriteRule ^/(.*) https://example.com/$1 [L,R]
~~~
### Renommage des VirtualHosts
Attention, EvoACME s'appuie donc sur le nom du fichier de VirtualHost dans `/etc/apache2/sites-enabled/` ...attention en cas de renommage il faudra renommer également le .csr ! Notamment pour `000-default` si on le renomme en `zzz-default` par exemple.
Attention, EvoACME va créer une clé privée dans /etc/ssl/private en fonction du nom du VirtualHost : il faut s'assurer que cela ne va pas écraser une clé existante.