Forum Linux.général Let's encrypt et plusieurs serveurs sur la même IP

Posté par EauFroide le 06 novembre 2016 à 14:54. Licence CC By‑SA.

Étiquettes :

nov.

2016

Je cherche un moyen de certifier des certificat TLS avec cette m…. de Let's encrypt.
Trois serveurs se trouvent sur la même IP publique et un seul des trois (qu'on nommera server1) occupe les ports publique 80/443.

Donc la grande question : comment certifier les certificat de server2 et server3 alors que let's encrypt ne permet PAS de choisir d'autres ports que les deux principaux des 4 ports web (car oui, même 8080 et 8443 ne sont pas autorisé, oh comble des merveilles).

Si vous possédez une méthode, je suis preneur.

Truc déjà tenté

Mentionner dans le vhost le même port local que publique (nat), ne fonctionne pas
Mentionner dans le vhost au niveau du hostname un port spécifique, mais ça ne fonctionne pas
J'ai songé a centraliser sur server1 et expédier les certificat via scp mais let's encrypt utilisant des lien symbolique dans les vhost apache2, ça ne va pas fonctionner
Je suis en train de tester une solution, pure hacking : 1 dossier partagé entre server, censé être accessible a www-data de server1. Ainsi quand server2 ou server3 fait sa certification le webroot est le dossier partagé et c'est server1 qui s'occupe (via un vhost dédié) de répondre à l'agent Smith de let's encrypt. Mais les permissions linux, trop restrictive à leur accoutumée, semblent bloquer (je suis pas sur que www-data de server1 arrive à accéder au dossier partagé ("su www-data ls /path/folder" ne fonctionnant pas, ni même le www-data du server hostant le dossier partagé malgré un chown www-data et chmod 777)
la seule méthode qui a déjà fonctionné pour le moment c'est de taper tout Let's Encrypt (avec TOUT les certificat de tout les servers) dans un dossier partagé et de faire pointer les règles des certificats des vhost vers ce dossier. Mais quand le dossier est inaccessible (server qui fait dodo par exemple) toute l'infrastructure tombe (et glusterfs bug donc pas possible d'utiliser un dossier partagé repliqué sur toutes les machines, en plus y a pas de crypto pour les échanges en glusterfs par défaut)

Edit : solution apportée : reverse proxy sur frontend avec un vhost par hostname a proxifier

# Modifier ports

Posté par ptit_poulet le 06 novembre 2016 à 15:02. Évalué à 2.

Bonjour,

Tu peux aussi modifier tes ports en écoutes juste l'instant de renouveler tes certificats, non ?
- [^] # Re: Modifier ports
  
  Posté par EauFroide le 06 novembre 2016 à 15:05. Évalué à 2.
  
  Je pourrais en effet, mais je cherche une solution pour automatiser le renouvellement. Changer les redirections sur le NAT ne semble pas pouvoir se faire automatiquement
  
  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
  - [^] # Re: Modifier ports
    
    Posté par EauFroide le 06 novembre 2016 à 15:23. Évalué à 0. Dernière modification le 06 novembre 2016 à 15:24.
    Note que ça donne une idée (mais encore de l'ordre du hacking) :
    - lorsqu'un serveur enclenche un renouvellement lui permettre d'activer sur server1 un vhost spécifique pour rediriger les flux http/https vers serverX (grâce a apache2 reverse proxy) et quand l'opération est terminée désactiver ce vhost.
    - Ou dans le même ordre d'idée lors d'un renouvellement serverX pourrait désactiver apache2 sur server1 et activer 2 tunnels SSH depuis server1:80/443 vers serverX:80/443 puis une fois le challenge terminé désactiver les tunnels sur server1 et ré-activer apache2. Mais les webservices n'apprécieraient vraiment pas cela.
    Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# Ce que j'ai fait

Posté par GG (site web personnel) le 06 novembre 2016 à 16:13. Évalué à 8.

J'ai un serveur qui écoute sur le 80 et le 443.

Tout ce qui arrive sur le 443 est renvoyé vers une VM qui s'occupe exclusivement de Let's Encrypt, puis il y a ensuite des règles de redirections, comme pour un reverse proxy.

Sur le 80, j'ai un reverse proxy, qui sert d'aiguillage. Et, si j'y détecte une requête qui est nécessaire pour le renouvellement ou la création d'un certificat Let's Encrypt, je la fais suivre vers la VM spécifique pour Let's Encrypt.

Tu peux faire sans Let's Encrypt, mais c'est bien plus compliqué.

Sincèrement, avec Let's Encrypt, la gestion des certifcats est enfin automatisable.

Si tu ne sais pas t'en servir, ce n'est pas nécessaire d'être insultant.
Tu faisais comment avant?

Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
- [^] # Re: Ce que j'ai fait
  
  Posté par EauFroide le 06 novembre 2016 à 16:29. Évalué à -3. Dernière modification le 06 novembre 2016 à 16:32.
  
  Tu faisais comment avant?
  
  Avant let's encrypt j'utilisais que des certificat auto signé depuis let's encrypt je n'ai encore rien d'automatisé, c'est du test que je trouve fort décevant. (surtout que leur excuse pour refuser toutes les demandes de changement c'est "vous avez qu'a créer votre autorité de certification")
  Pour le moment la méthode la moins prises de tête que je vois c'est de taper tout mes VHOST sur la même machine puis de rediriger le trafic vers les différents servers en fonction de l'hostname en full http ou au pire via de nombreux&gourmand tunnel SSH.
  
  J'essaye que mon installation soit compatible IPv4 et IPv6 afin que la migration prochaine se fasse "sans modification" mais c'est mal parti là.
  
  Si tu ne sais pas t'en servir, ce n'est pas nécessaire d'être insultant.
  
  Désolé mais t'imagine pas la frustration que je subis avec ce TLS foireux et les blocages fait par les navigateurs/logiciels qui pourrissent l'utilisation de l'auto hébergement et de l'internet des objets (genre la camera de surveillance compatible TLS mais dont firefox bloque l'accès en https car le certificat ne lui plait pas)
  
  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# certbot / debian

Posté par Marc Quinton le 06 novembre 2016 à 16:21. Évalué à 4.
voici ma procédure d'installation suivi du renouvellement via crontab, sur l'un de mes serveurs hébergeant un multi-domaine.
```
# arret du serveur apache
service apache2 stop

# certbot est le client Let's Encrypt de la distribution DEbian
# on l'active en mode certonly+standalone ; dans ce mode, un serveur web en standalone  est lancé
# il est probablement en écoute sur les ports 443 et 80
certbot certonly --email admin@mon-domaine.fr --standalone -d serv1.mon-domaine.fr -d serv2.mon-domaine.fr

service apache2 start

root@linux-host:/etc/cron.d# cat > /etc/cron.d/certbot 
# 
# renew Let's Encrypt certificate
# every second day of month, between 0h00 and 5h00.
#
0 0 2 * * root perl -e 'sleep int(rand(3600*5))'; certbot renew --standalone \
 --pre-hook "service apache2 stop" --post-hook "service apache2 start"
```
- [^] # Re: certbot / debian
  
  Posté par EauFroide le 06 novembre 2016 à 16:39. Évalué à 0. Dernière modification le 06 novembre 2016 à 16:41.
  
  C'est gentil mais le problème n'est pas le multi domaine mais le multi server.
  J'ai déjà un serveur qui automatise le renouvellement de deux hostname avec certbot-auto (note que j'attends l'enclenchement du cron pour voir si ça fonctionne). Le problème est qu'il faudrait aussi certifier deux hostnames (minimum) pour chacun des autres servers qui n'ont pas accès à 80/443 de l'ip publique.
  
  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
  - [^] # Re: certbot / debian
    
    Posté par Adrien Dorsaz (site web personnel, Mastodon) le 06 novembre 2016 à 20:02. Évalué à 5.
    
    Si tu maitrises ton serveur DNS et que tu peux le configurer pour autoriser des modifications automatiques des zones (avec des clés TSIG par exemple), tu peux tout faire sur ce serveur en utilisation la vérification par entrées DNS fournie par Let's Encrypt.
    
    Est-ce que tu as ces problèmes à cause d'un NAT qui gère les 3 serveurs ? Dans ce cas, une solution serait aussi d'utiliser un réseau IPv6 que Let's Encrypt sait utiliser.
    
    Si Let's Encrypt t'ennuie autant, personne ne te force à utiliser leurs services et ça ne sert strictement à rien de leur cracher dessus: le problème des NAT existe depuis bien avant et il complexifie beaucoup d'autres services également (XMPP, P2P,…) sans que ce soit de leur faute.
    - [^] # Re: certbot / debian
      
      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 06 novembre 2016 à 20:32. Évalué à 4. Dernière modification le 06 novembre 2016 à 20:35.
      Désolé, je n'avais pas vu que c'était bien le NAT ton problème.
      
      Dans ce cas, il faut:
      
      Pointer tous tes domaines et sous-domaines sur l'adresse IP publique
      
      Configurer le NAT pour envoyer toutes les connexions entrantes sur les ports 80 et 443 vers ton serveur 1
      
      Configurer le service web du serveur 1 pour écouter chaque domaine et sous-domaines sur les ports 80 et 443
      
      Utiliser le serveur 1 pour demander des certificats à Let's Encrypt pour chacun des domaines et sous domaines
      
      Quand les certificats sont reçu, tu peux soit:
      
      demander au serveur 1 de pousser les bons certificats sur chacun de tes autres serveurs (l'avantage est que le serveur 1 sait quand il crée les certificats, par contre le désavantage est qu'il doit avoir un accès sur chacun des serveurs)
      
      dire à chacun de tes autres serveurs d'aller chercher les nouveaux certificats sur le serveur1 (le désavantage est que les autres serveurs doivent récupérer assez souvent les certificats pour être sûr d'avoir le dernier, l'avantage est que chaque serveur aura ses propres droits sur le serveur 1 et le serveur 1 ne peut pas toucher aux autres serveurs)
      
      En bonus, si tu maitrises suffisamment ton service web sur le serveur 1, tu peux l'utiliser comme reverse proxy : si une requête est faite sur les URLs utilisées par Let's Encrypt, il répond lui-même à la requête, dans les autres cas, il renvoie les requêtes vers les bons servuers. Comme ça, tu peux utiliser tout tes domaines avec les ports standards web.
      
      Pour t'aider pour le reverse proxy, tu peux regarder ce lien : https://blog.bandinelli.net/index.php?post/2016/10/19/Pound-Let-s-Encrypt-%3A-un-service-pour-tout-r%C3%A9gler
      - [^] # Re: certbot / debian
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 06 novembre 2016 à 20:44. Évalué à 4. Dernière modification le 06 novembre 2016 à 20:46.
        
        Ah et bien sûr, il ne faut pas que ton client ACME touche à la configuration de ton service web.
        
        Il parraît qu'il y a des options pour ça avec le client certbot (que je n'utilise pas), il faut lire son manuel.
        
        Il y a plein de clients ACME alternatifs qui permettent de récupérer les certificats sans toucher au serveur web. Je pense qu'acme-tiny devrait faire l'affaire dans ce cas (en plus il n'a besoin que d'accéder à ta clé Let's Encrypt et aux CSR).
        
        PS: Surtout n'utlise pas chmod 777 pour la protection de tes fichiers, ils seront tous accessibles si quelqu'un arrive à s'introduire sur tes serveurs.
        
        PS2: Tu peux faire un dossier partagé par serveur, rien ne t'oblige de mettre tous les certificats dans le même dossier partagé…
        
        [^] # Re: certbot / debian
        
        Posté par EauFroide le 06 novembre 2016 à 21:35. Évalué à -1.
        
        Merci je vais aller voir les différents clients ptete que l'un ou l'autre permet de passer par d'autres port.
        
        J'ai déjà un reverse proxy mais pour plusieurs raisons je l'ai remplacé, pour certains services, par un accès direct via un des autres ports web.
        
        Il faut savoir qu'un certificat Let's Encrypt n'est utilisable que sur les ports 80, 443, 8080, 8443. Si on utilise des autres ports pour raison X ou Y, firefox bloque et je suppose que ses bêtes compères pareil.
        
        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
        
        [^] # Re: certbot / debian
        
        Posté par GG (site web personnel) le 06 novembre 2016 à 22:04. Évalué à 3.
        
        J'insiste:
        
        Pour Let's Encrypt, tu n'as besoin que de 2 ports (80 et 443) et d'un reverse proxy.
        
        Mon reverse proxy me permet de :
        - renvoyer vers le port 80 de la VM Let'sEncrypt les requêtes pour créer ou renouveler un certificat (comme ça, pas besoin de couper le service web)
        - renvoyer selon le nom de domaine vers telle machine en changeant éventuellement de ports
        
        Sur la VM qui gère les certificats, c'est pareil, il y a un reverse proxy qui va renvoyer vers les VM/ports selon le nom de domaine.
        
        Pound c'est simple, très simple, mais à un moment tu vas peut être préférer utiliser Nginx ou Haproxy.
        Tu peux tester avec pound si tu veux, c'est très simple à mettre en place.
        
        Pour tes ports 8080 et 8443, à toi d'écrire tes règles NAT pour envoyer vers tes VM/port what ever. Mais pour créer ou renouveller tes certificats, automatiquement, il faut passer par le port 80. mais ce n'est pas un problème, puisque la requête est identifiable, et donc tu va pouvoir la transférer comme tu voudras.
        
        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
        
        [^] # Re: certbot / debian
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 06 novembre 2016 à 22:08. Évalué à 5.
        
        Merci je vais aller voir les différents clients ptete que l'un ou l'autre permet de passer par d'autres port.
        
        Ne cherche pas, ça n'existe pas, car le protocole ACME ne pourra pas vérifier que tu es l'administrateur système (voir ma réponse plus bas).
        
        J'ai déjà un reverse proxy mais pour plusieurs raisons je l'ai remplacé, pour certains services, par un accès direct via un des autres ports web.
        
        Le reverse proxy n'est qu'un bonus, il n'est pas nécessaire. Tu peux garder tes sites accessibles sur d'autres ports, ça ne pose aucun problème.
        
        Il faut savoir qu'un certificat Let's Encrypt n'est utilisable que sur les ports 80, 443, 8080, 8443. Si on utilise des autres ports pour raison X ou Y, firefox bloque et je suppose que ses bêtes compères pareil.
        
        Non, ce n'est pas vrai: les certificats ne définissent pas les ports sur lesquels ils peuvent être utilisés. Par exemple, pour mon serveur, j'utilise les certificats Let's Encrypt sur les ports : 25, 587, 5222, 5269, 5280, 443, 486, … Un certificat n'est qu'un document signé par une autorité de certification. Ce document contient principalement la clé publique utilisée par ton domaine et une date de validité, c'est quasiment tout.
      - [^] # Re: certbot / debian
        
        Posté par EauFroide le 07 novembre 2016 à 13:20. Évalué à 0.
        
        Bon j'ai réussi à faire certifier server2 en passant par le reverse proxy.
        Par contre je ne sais pas si le renouvellement fonctionne.
        Quand je lance la commande de renouvellement il me réponds :
        
        Cert not yet due for renewal The following certs are not due for renewal yet: /etc/letsencrypt/live/www.0rion.netlib.re/fullchain.pem (skipped) No renewals were attempted.
        
        Je conçois que le certificat n'a pas besoin d'être renouvelé (il à moins de 10 minutes), mais pourquoi n'y vois-je qu'un seul hostname (sur deux)? Server2 réponds la même chose et lui aussi sur un seul hostname.
        
        Les commandes :
        sur RPI
        
        sudo ./certbot-auto renew
        
        sur Xubuntu
        
        letsencrypt renew --webroot-path /var/www/html/ --register-unsafely-without-email
        
        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
        
        [^] # Re: certbot / debian
        
        Posté par EauFroide le 07 novembre 2016 à 16:41. Évalué à 0. Dernière modification le 07 novembre 2016 à 16:45.
        
        Hmm j'ai compris pourquoi il n'y à qu'un seul hostname signalé: il semblerait que les clés privées/certificats se trouvent dans les mêmes fichiers.
        Bon ben la suite dans un mois histoire de voir si le renouvellement fonctionne.
        
        Merci pour votre aide à ceux qui ont participé ;)
        
        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
    - [^] # Re: certbot / debian
      
      Posté par EauFroide le 06 novembre 2016 à 21:25. Évalué à -2. Dernière modification le 06 novembre 2016 à 21:29.
      
      Si Let's Encrypt t'ennuie autant, personne ne te force à utiliser leurs services et ça ne sert strictement à rien de leur cracher dessus: le problème des NAT existe depuis bien avant et il complexifie beaucoup d'autres services également (XMPP, P2P,…) sans que ce soit de leur faute.
      
      C'est leur choix de bloquer la possibilité de choisir les ports, c'est leur choix de foutre une limite de trois mois, c'est un projet de mozzila dont comme par hasard firefox force a utiliser des certificats trusté.
      Mais je pense me passer de leur service sauf pour le forum. Dépendre d'un tiers pour mes propres services ça me la fou déjà assez mal.
      
      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
      - [^] # Re: certbot / debian
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 06 novembre 2016 à 22:02. Évalué à 6.
        
        C'est leur choix de bloquer la possibilité de choisir les ports, c'est leur choix de foutre une limite de trois mois, c'est un projet de mozzila dont comme par hasard firefox force a utiliser des certificats trusté.
        
        De un, ce n'est pas Mozilla qui gère ce projet d'après le site letsencrypt.org : "Linux Foundation Collaborative Projects".
        
        De deux, Mozilla ne t'empêche pas d'utiliser des certificats auto-signés: il faut juste ne pas activer HSTS, car dans ce cas, il est nécessaire d'avoir une configuration TLS correcte (sinon, ce n'est pas une configuration de type Strict-Transport-Security), ce qui requiert un certificat signé par une autorité de confiance reconnue par les navigateurs.
        
        Le but de la vérification par HTTP est de vérifier automatiquement que tu maîtrises la configuration du serveur web qui pointe sur le domaine demandé (et donc que ce domaine t'appartienne bien).
        Si tu es incapable de maîtriser cette configuration sur le service web standard (ports 80 et 443), alors le protocole ACME considère que tu n'es pas le maître de ce serveur et il n'a pas d'autre moyen de le faire automatiquement.
        
        Si ACME autorise la vérification avec un autre port, alors n'importe quel employé qui a un accès non-root sur un serveur peut créer des certificats frauduleux: en effet, tous les ports plus grand que 1000 (comme les ports 8080 et 80443), si je me souviens bien, peuvent être utilisés par n'importe quel utilisateur de la machine. Dans ce cas, ACME ne peut pas certifier que c'est bien l'administrateur système qui demande la certification.
        
        L'automatisation de la certification demande en effet une préparation non-évidente pour l'auto-hébergement, mais ce n'est pas non plus insurmontable (voire les solutions que j'ai donné plus haut).
      - [^] # Re: certbot / debian
        
        Posté par GG (site web personnel) le 06 novembre 2016 à 22:08. Évalué à 6.
        
        C'est bien 3 mois.
        
        Une fois que c'est automatisé, sincèrement, ce serait une semaine et cela ne ma gênerait pas.
        
        Avant Let's Encrypt, j'avais des certificats auto-signés.
        
        Maintenant, j'ai des certificats signés pour mes noms de domaines, les sous-domaines (nombreux), et aussi pour les VM que je prête pour certains amis.
        
        Je suis très content que Let's Encrypt m'ait permis d'avoir enfin des certificats qui ne provoquent plus d'alertes, et pour l'ensemble de mes domaines et sous-domaines, sans que cela ne me coûte une fortune.
        
        Il m'a fallu m'adapter un peu, c'est la vie.
        Tu n'es pas obligé d'utiliser Let's Encrypt.
        
        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
        
        [^] # Re: certbot / debian
        
        Posté par EauFroide le 07 novembre 2016 à 14:00. Évalué à -1.
        
        Tu n'es pas obligé d'utiliser Let's Encrypt.
        
        Enfaite: si.
        -Firefox bloque les contenus http sur les pages https.
        -En cas d'auto signé venant de plusieurs machines firefox ne va proposer d'autoriser que le principale et bloquer tout le reste (exit le serveur d'image)
        -je me fais harceler par des potes geek qui sont pas foutu de passer l'alerte de sécurité sur safari/chrome/firefox, cette alerte bloque complètement mes users âgés. (et tout le monde me dis que je suis con à rendre inaccessible mes tuto)
        -Même le robot de linuxfr (Go 1.1 pkg http) qui va récupérer les images à l'air d'avoir compliqué avec les certificats auto-signé
        -certaines applications comme wget nécessite d'ajouter un paramètre pour télécharger sur auto signé se qui pose parfois problèmes avec certaines applications (quand on le sait pas, c'est un bug troublant)
        
        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
        
        [^] # Re: certbot / debian
        
        Posté par GG (site web personnel) le 07 novembre 2016 à 16:03. Évalué à 3.
        
        Tu devrais avoir des certificats auto-certifié certifiées.
        
        C'est ce que permet Let's Encrypt.
        
        Essaye de te calmer, et étudie bien la question, parce que Let's Encrypt à été pensé pour résoudre les problèmes de certificats auto-signés, entre autres.
        
        Et, c'est automatisable.
        Il y a plein de manières différentes, selon la situation de chacun, mais rien d'insurmontable.
        Il y a plein de tutoriels sur internet. Il n'y a pas besoin d'écrire des scripts compliqués parce qu'il existe maintenant des outils qui font le travail très bien.
        
        Bonne journée
        
        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Mal parti

Posté par 🚲 Tanguy Ortolo (site web personnel) le 07 novembre 2016 à 10:09. Évalué à 6.

Je cherche un moyen de certifier des certificat TLS avec cette m…. de Let's encrypt.

Ça commence mal, très mal. Si tu pars avec l'idée que c'est merdique et que tu n'y arriveras pas, tu n'as que peu de chance d'y arriver effectivement. Et si Let's Encrypt ne te plaît pas, personne ne t'oblige à utiliser leurs services. Par ailleurs, ledit service est gratuit, donc si tu n'es pas content, c'est ton problème, ils ne te doivent rien du tout.
# alternative ports

Posté par Jerome le 09 novembre 2016 à 17:59. Évalué à 2.

Donc la grande question : comment certifier les certificat de server2 et server3 alors que let's encrypt ne permet PAS de choisir d'autres ports que les deux principaux des 4 ports web (car oui, même 8080 et 8443 ne sont pas autorisé, oh comble des merveilles).

Si, on PEUT choisir d'autres ports :
sh ./certbot-auto certonly -d $1 --standalone --tls-sni-01-port 1443 --http-01-port 8080

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.