J'ai récemment (et je pense que c'était sur ServerFault, StackOverflow, ou un autre forum StackExchange) découvert que les piles Bitnami fournissent un outil pour utiliser Let's Encrypt, un outil qui apparemment utilise autre chose que certbot (quelque chose appelé "lego", n'est-ce pas ?).
Nous avons une pile Bitnami Trac/SVN fonctionnant sur une instance AWS EC2 (Amazon Linux d'origine). Je remarque qu'il y a apparemment deux instances httpd distinctes présentes sur la boîte ; celle de la pile Bitnami est la plus active, hébergeant Trac et SVN. (Je pense avoir démarré l'autre, il y a quelques mois, en rapport avec une tentative ratée de faire fonctionner certbot, et l'avoir peut-être laissée en place, mais elle ne fait pas grand-chose en réalité).
Le httpd Bitnami est configuré pour HTTP sur le port 81 (qui n'est pas actuellement accessible de l'extérieur), et HTTPS sur le port 8000 (qui est accessible), et utilise actuellement un certificat de Comodo, qui expire en juillet.
Et je ne me souviens pas de la configuration initiale du port "tel que livré" pour le httpd dans la pile Bitnami.
J'ai lu les instructions de ce "bncert-tool", et je me demande s'il va fonctionner avec notre configuration. D'après mes expériences ratées avec certbot, j'avais l'impression que Let's Encrypt s'attendait à trouver http ouvert sur 80.
Quelqu'un peut-il m'éclairer à ce sujet ?
Mise à jour du 18 mai
Je me suis enfin souvenu de ce projet à un moment où je pouvais réellement y consacrer du temps. J'ai cloné l'instance vers une instance Spot, puis (1) j'ai désactivé le httpd "stock" fourni avec Linux, et (2) j'ai modifié le httpd de la pile Bitnami pour qu'il écoute sur 80. Lorsque j'ai lancé bncert-tool, j'ai obtenu ceci :
Une erreur s'est produite lors de la création de certificats avec Let's Encrypt :
acme: Error -> One or more domains had a problem:
[test.wintouch.net] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized
:: Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge, url:Et maintenant ?
(J'ai sauvegardé le fichier journal).
Mise à jour du 22 mai
Il m'est apparu que, tel que le serveur est actuellement configuré, il est impossible d'accéder à tout ce qui est sans mot de passe.
Alors, j'ai essayé une autre instance ponctuelle. Après quelques manipulations, je l'ai configurée pour qu'elle écoute sur 80, sans mot de passe, et qu'elle serve une page statique sur ce port, situé loin des données SVN et Trac.
Mais les résultats étaient exactement les mêmes qu'avant. Comme avant, j'ai a mis fin à la demande ponctuelle et a supprimé l'enregistrement de la Route 53 A dans le cadre du nettoyage.
Après l'expérience de la journée, j'ai cherché à configurer mon instance Spot à partir de ce que j'avais utilisé lors de la configuration initiale, et j'ai découvert quelque chose de plutôt étrange : toutes les AMI Bitnami SVN et Trac que j'ai pu voir sont soit Debian, soit Ubuntu. Mais este est sur Amazon Linux (original, pas Amazon Linux 2). Donc, soit il s'agit d'une AMI qui n'existe plus, soit j'ai lancé l'instance à partir d'une AMI Amazon Linux "vanille", puis j'ai installé la pile SVN/Trac de Bitnami dessus.
Je noterai que la pile, y compris bncert-tool, ne no vivent dans /opt/bitnami, mais dans /opt/trac-1.2.3-11
Alors, comme je n'arrivais pas à inspecter une configuration "telle que livrée", j'ai regardé autour de moi, en me demandant ce que bncert-tool utilise pour trouver la pile, et j'ai fini par trouver /opt/trac-1.2.3-11/properties.ini
hostname=
[Support]
installed_components=apache
apache_logs=apache{,2}/logs/error*log logs/error_log
apache_conf=apache{,2}/conf/{*.conf,bitnami/*.conf} etc/httpd.conf apps/*/conf/ht*.conf
apache_acl=apache apache2
[Apache]
apache_server_port=81
apache_user=daemon
apache_group=daemon
apache_server_ssl_port=443
apache_root_directory=/opt/trac-1.2.3-11/apache2
apache_htdocs_directory=/opt/trac-1.2.3-11/apache2/htdocs
apache_domainname=ip-172-31-8-195.us-east-2.compute.internal
apache_configuration_directory=/opt/trac-1.2.3-11/apache2/conf
apache_version=2.4.39
[Subversion]
subversion_port=3690
subversion_root_directory=/opt/trac-1.2.3-11/subversionqui semble inchangé depuis l'installation (tout ce qui se trouve dans /opt/trac-1.2.3-11 a un datestamp du 6 juin 2019).
Se pourrait-il que bncert-tool utilise ce fichier de configuration, et que l'est déjà en disant à Let's Encrypt d'utiliser le port 81 au lieu de 80 ?
Je noterai que contrairement au fichier de configuration ci-dessus, l'instance Bitnami de httpd écoute pour SSL/TLS sur 8000, et non 443, un serveur Tomcat (indépendant de la pile Bitnami) écoute sur 8443 (et apparaît dans netstat -l --numeric-ports comme) 8443, mappé en 443 via iptables, et rien écoute directement sur le port 443.
