Certbot: autonome devrait permettre aux ports alternatifs de se lier (mais pas de s'authentifier)

Je crois que le client a déjà la fonctionnalité que vous voulez, cependant, il n'est pas présenté de manière très conviviale car il a principalement été utilisé pour les tests. Le client a les drapeaux suivants :

  --tls-sni-01-port TLS_SNI_01_PORT
                        Port number to perform tls-sni-01 challenge. Boulder
                        in testing mode defaults to 5001. (default: 443)
  --http-01-port HTTP01_PORT
                        Port used in the SimpleHttp challenge. (default: 80)

Ces drapeaux vous permettent de spécifier pour quels ports le client configure les défis de validation de domaine. En général, --tls-sni-01 devrait être le port vers lequel vous avez acheminé le trafic entrant du port 443 et --http-01-port devrait être le port vers lequel vous avez acheminé le trafic entrant du port 80.

Vous n'auriez pas besoin d'utiliser les deux indicateurs, cependant, autonome par défaut effectue des défis sur 443. Vous pouvez contrôler ce comportement en utilisant l'indicateur suivant :

  --standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
                        Supported challenges. Preferred in the order they are
                        listed. (default: tls-sni-01,http-01)

J'espère que ça aide!

Merci, je vais essayer ça demain.

Si cela fonctionne, il devrait vraiment être utilisé comme exemple. Il est beaucoup plus facile de redémarrer un serveur pour activer/désactiver le passage du proxy sur ces ports que de tout mettre hors ligne pour gérer le processus de vérification,

Le 22 mars 2016, à 15h16, bmw [email protected] a écrit :

Je crois que le client a déjà la fonctionnalité que vous voulez, cependant, il n'est pas présenté de manière très conviviale car il a principalement été utilisé pour les tests. Le client a les drapeaux suivants :

--tls-sni-01-port TLS_SNI_01_PORT
Numéro de port pour effectuer le défi tls-sni-01. Rocher
en mode test, la valeur par défaut est 5001. (par défaut : 443)
--http-01-port HTTP01_PORT
Port utilisé dans le défi SimpleHttp. (par défaut : 80)
Ces drapeaux vous permettent de spécifier pour quels ports le client configure les défis de validation de domaine. En général, --tls-sni-01 doit être le port vers lequel vous avez acheminé le trafic entrant du port 443 et --http-01-port doit être le port vers lequel vous avez acheminé le trafic entrant du port 80.

Vous n'auriez pas besoin d'utiliser les deux indicateurs, cependant, autonome par défaut effectue des défis sur 443. Vous pouvez contrôler ce comportement en utilisant l'indicateur suivant :

--standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
Défis pris en charge. Préférés dans l'ordre où ils sont
listé. (par défaut : tls-sni-01, http-01)
J'espère que ça aide!

—
Vous recevez ceci parce que vous êtes l'auteur du fil.
Répondez directement à cet e-mail ou consultez-le sur GitHub

@jvanasco la plupart des gens utilisent le plugin webroot pour ce cas d'utilisation mais oui, un exemple de proxy pass nginx pourrait être bon. N'hésitez pas à faire un PR qui en ajoute un aux docs ; il s'agit d'un cas d'utilisation suffisamment spécialisé pour qu'il obtienne probablement une nouvelle section au bas de ce fichier :

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst

Cependant, vous pouvez y accéder à partir de la section autonome existante :

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst#standalone

Nous n'avons jamais eu de retour à ce sujet donc je ferme ce sujet. Merci de commenter en me criant dessus si vous souhaitez que je rouvre.

Cela ne semble pas fonctionner. @BMW

/usr/local/bin/certbot-auto certonly --http-01-port 8484 --config-dir /etc/letsencrypt --work-dir /var/lib/letsencrypt --logs-dir /var/log/letsencrypt --standalone --standalone-supported-challenges http-01 --email [email protected] --domains example.com --agree-tos --non-interactive

tcp        0      0 0.0.0.0:8484                0.0.0.0:*                   LISTEN      7270/python2

Je vois l'authentification passer sur le port 80, mais le serveur python2 a démarré sur 8484.

Nginx sur le port 80

66.133.109.36 - - [25/Aug/2016:12:41:15 +0100] "GET /.well-known/acme-challenge/xxxxxxxx HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

ÉDITER:
Je vois que --tls-sni-01-port 5001 --http-01-port 5002 sont tous les deux requis !

Éditer:
Je ne sais toujours pas comment faire tourner un serveur autonome et l'authentifier

J'ai également des problèmes avec --tls-sni-01-port ignoré :

# certbot certonly --noninteractive --email "matt.hanley@****" --domain **** --agree-tos --tls-sni-01-port 40443 --http-01-port 4080 --standalone  
Failed authorization procedure. ****** (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 2af2853170e5be7e86cdff79d0ca****.febd4f14bb130b15910f30587cf4****.acme.invalid from 185.***.***.***:443. Received certificate containing '*****'

Notez que la requête est en fait allée à :443 ; J'ai déjà un service HTTPS fonctionnant sur :443 servant un certificat différent. Cela fonctionne cependant avec renew .

J'ai aussi un problème avec --tls-sni-01-port :

certbot certonly -n -d example.com --agree-tos --email "[email protected]" --standalone --tls-sni-01-port 8443 --http-01-port 8080

Failed to connect to 1.2.3.4:443 for TLS-SNI-01

--http-01-port / --tls-sni-01-port ne vous permet pas de spécifier sur quel port Let's Encrypt se connectera à votre serveur. Il utilisera toujours 80/443 respectivement. Tous ces drapeaux vous permettent de contrôler les ports sur lesquels Certbot écoute les plugins comme autonome. Ceci est utile si vous acheminez tout le trafic du port 80 vers le port 8080 par exemple.

Ouais, juste un avertissement, vous devez essentiellement avoir le port 80 accessible sur l'adresse IP publique.

Quelque chose qui manque beaucoup dans la documentation, signifie également que Let's Encrypt n'est pas adapté à une minorité qui ne peut pas contrôler le trafic entrant sur 80 (probablement la Chine / certains FAI, pare-feu Corp)

J'ai lu plusieurs articles à ce sujet, il semble presque que la capacité d'écouter sur 80 est considérée comme un gain de sécurité / une mesure de confiance car c'est un port privilégié sur une boîte Nix.

Bien que semble crypter, ne reconnaisse pas l'utilisation de certificats en dehors des serveurs Web. Par exemple, un serveur de messagerie, etc. t exécuter un serveur Web .. mais allez comprendre.

Cela signifie également que si vous utilisez une automatisation comme Chef par exemple, vous devez configurer des certificats auto-signés pour pouvoir démarrer votre nginx étant donné que la configuration aura SSL dessus, il doit avoir au moins un certificat valide.

Une autre option, cependant, si vous exécutez SSL uniquement, est d'avoir un serveur Web différent servant 80 afin qu'il puisse s'assurer que le certificat est téléchargé avant que nginx n'essaye de démarrer. (Configuration ennuyeuse)

Mes déploiements de chef passent désormais par les étapes suivantes :

1. Installez un certificat auto-signé.
2. Boot nginx (avec auto-certification)
3. Exécuter le certificat
4. Certificats de lien symbolique vers ma position
5. Recharger nginx

Envoyé de mon iPhone

Le 15 septembre 2016, à 23h18, Brad Warren [email protected] a écrit :

--http-01-port/--tls-sni-01-port ne vous permet pas de spécifier sur quel port Let's Encrypt se connectera à votre serveur. Il utilisera toujours 80/443 respectivement. Tous ces drapeaux vous permettent de contrôler les ports sur lesquels Certbot écoute les plugins comme autonome. Ceci est utile si vous acheminez tout le trafic du port 80 vers le port 8080 par exemple.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

Mon serveur Web écoute sur un seul port pour les connexions SSL et ce n'est pas le 443 par défaut. C'est parce que le serveur Web est derrière un service VPN qui permet la redirection de port, mais n'autorise pas la redirection de port vers le port 80 ou 443.

J'essaie de configurer Let's Encrypt sur ce serveur mais dans les journaux, je peux voir que le client acme essaie de se connecter sur le port 80 (qui n'est pas accessible) et échoue.

L'erreur que j'obtiens est un statut "Impossible de se connecter" 400.

La valeur "addressesResolved" est correcte, c'est juste que la valeur "port" est 80 et que toutes les URL sont incorrectes, car elles doivent avoir mon port personnalisé spécifié, par exemple subdomain.domain. tld:1234 où 1234 est mon port personnalisé.

Existe-t-il un moyen de le faire fonctionner avec ma configuration?

De @gsdevme, j'ai eu l'impression que je devais avoir le port 80 accessible au public...

_VOUS DEVEZ AVOIR LE PORT 80 ACCESSIBLE AU PUBLIC POUR VERIFIER LE SERVEUR ACME._

_CETTE SOLUTION EST UNIQUEMENT POUR FAIRE FONCTIONNER LE SERVEUR SUR UN PORT AUTRE EN INTERNE, ET METTRE EN PROXY DU PORT80 VERS LE PORT AUTRE._

_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._
_SI VOUS N'AVEZ PAS ACCESSIBLE LE PORT80, VOUS DEVEZ UTILISER LA VÉRIFICATION DNS._

Merci pour la réponse @jvanasco. Dommage que je ne puisse pas spécifier de ports personnalisés. La vérification DNS n'est pas une option, car mon fournisseur de DNS dynamique http://freedns.afraid.org/ n'a pas d'interface pour modifier automatiquement les enregistrements TXT.

@jvanasco Bien que je sache que vous avez tout à fait raison dans votre réponse, ce serait bien si nous nous calmions tous un peu avant de répondre :D

Y a-t-il une estimation du moment où cela sera configurable ? Parce que je suis sûr qu'il y a beaucoup de gens qui exécutent des serveurs Web sur des ports personnalisés.

Il n'est pas configurable par choix de conception

Envoyé de mon iPhone

Le 14 février 2017, à 16h16, nvaert1986 [email protected] a écrit :

Y a-t-il une estimation du moment où cela sera configurable ? Parce que je suis sûr qu'il y a beaucoup de gens qui exécutent des serveurs Web sur des ports personnalisés.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

Même problème ici, mais à des fins de menu fixe.

Problème :
Je ne souhaite pas empaqueter la commande certbot avec la commande de démarrage de mon serveur Web, car elle échouerait toujours dans des environnements non prod.
Je souhaite donc créer une image spécifique contenant un certbot qui :

• demander le certificat
• mettre le certificat dans un volume partagé avec mon serveur web

Mais cette solution ne fonctionnerait que si j'arrêtais le conteneur de mon serveur Web, qui est déjà lié aux ports 80 et 443.

Solution :
Avoir la possibilité de changer les ports de certbot. Cela permettrait à la fois au certbot et au conteneur de serveur Web de fonctionner en parallèle.

L'utilisation de la validation DNS peut résoudre le cas d'utilisation.

Envoyé de mon iPhone

Le 26 février 2017, à 23h32, NilsRenaud [email protected] a écrit :

Même problème ici, mais à des fins de menu fixe.

Problème :
Je ne souhaite pas empaqueter la commande certbot avec la commande de démarrage de mon serveur Web, car elle échouerait toujours dans des environnements non prod.
Je souhaite donc créer une image spécifique contenant un certbot qui :

demander le certificat
mettre le certificat dans un volume partagé avec mon serveur web
Mais cette solution ne fonctionnerait que si j'arrêtais le conteneur de mon serveur Web, qui est déjà lié aux ports 80 et 443.

Solution :
Avoir la possibilité de changer les ports de certbot. Cela permettrait à la fois au certbot et au conteneur de serveur Web de fonctionner en parallèle.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

Cela pourrait mais ce mode de validation n'est pas possible avec le mode autonome :/
(depuis : https://certbot.eff.org/docs/using.html#plugins)

Il semble qu'un juste milieu raisonnable sans compromettre la sécurité serait de permettre la découverte du port via l'enregistrement DNS SRV. Letsencrypt pourrait interroger un enregistrement comme

_letsencrypt._tcp IN SRV 0 0 8080 10.10.10.10

sur le domaine et transmettre les demandes de vérification à la combinaison adresse/port résultante. Cela présente les mêmes avantages que la vérification DNS mais sans l'inconvénient de nécessiter des mises à jour dynamiques.

Cela signifierait également que les utilisateurs pourraient facilement centraliser la gestion de leurs certificats s'ils le souhaitent, en référençant un serveur de certificats central.

En quoi l'autorisation de ports alternatifs compromet-elle la sécurité ?

Cet utilitaire FOSS peut vous aider à automatiser les installations directes et indirectes de certificats ACME sur les hôtes dont le port TCP/443 est occupé ou dont le port TCP/443 n'a pas été transféré :

https://www.actiu.net/sesele/

Où est la documentation sur le fonctionnement de SeSeLe pour permettre d'utiliser
ports différents de 443 ?.

Le 26 octobre 2017 à 13h21, "Narcis Garcia" [email protected] a écrit :

Cet utilitaire FOSS peut vous aider à automatiser les installations directes et indirectes de
Certificats ACME aux hôtes dont le port TCP/443 est occupé ou qui n'ont pas de port TCP/443
port qui leur est transmis :

https://www.actiu.net/sesele/

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-339754606 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAOGHuxKLiYjM4-cME-0GBu9Ujoe0NB_ks5swM20gaJpZM4H1uae
.

Merci de vous diriger vers le sujet du forum SeSeLe pour permettre une meilleure coordination de la documentation. (La réponse est écrite dans la documentation SeSeLe maintenant)

Peut-être que ce problème pourrait être réexaminé ? Il n'y a toujours pas de solution au problème sous-jacent. Oui, vous pouvez vous connecter en mode autonome à un port différent, mais cela ne sert à rien car l'autorité se connectera toujours au 80/443.

Si vous avez un serveur fonctionnant déjà sur 80/443 peut-être en production, vous ne pouvez parfois tout simplement pas vous permettre de libérer ces ports. Le placement manuel des fichiers de défi peut également être problématique (serveurs fonctionnant dans Docker).

La vraie solution ici serait de spécifier un ensemble de ports plus haut (10 000+) où l'autorité essaierait de se connecter en tant que repli ou quelque chose comme ça. Peut-être qu'il y a des implications de sécurité, pas un expert.

Quelle est la motivation pour que LE se connecte uniquement aux ports 80/443 ? Est-ce un
limitation formellement documentée ?

Quelqu'un peut-il m'indiquer les bons documents ?

Le 30 novembre 2017 à 6h31, "cen1" [email protected] a écrit :

Peut-être que ce problème pourrait être réexaminé ? Il n'y a toujours pas de solution à la
problème sous-jacent. Oui, vous pouvez vous connecter en mode autonome à un port différent, mais cela
est inutile car l'autorité se connectera toujours au 80/443.

Si vous avez un serveur fonctionnant déjà sur 80/443 peut-être en production, vous
parfois ne peuvent tout simplement pas se permettre de libérer ces ports. Placement manuel
les fichiers de challenge pourraient également être problématiques (serveurs fonctionnant dans Docker).

La vraie solution ici serait de spécifier un ensemble de ports plus haut (10
000+) où l'autorité essaierait de se connecter comme solution de repli ou quelque chose comme ça
comme ça. Peut-être qu'il y a des implications de sécurité, pas un expert.

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-348162321 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAOGHqWG9XZyTVDdAbm3t5xQ-AD6Y_OQks5s7pIDgaJpZM4H1uae
.

Quelle est la motivation pour que LE se connecte uniquement aux ports 80/443 ?
Est-ce une limitation formellement documentée ?

Quelqu'un peut-il m'indiquer les bons documents ?

Il s'agit d'une exigence actuelle du forum CA/B décrite ici :
https://cabforum.org/2017/09/19/ballot-190-revised-validation-requirements/

Et expliqué plus en détail ici : https://community.letsencrypt.org/t/support-for-ports-other-than-80-and-443/3419/100

Comme je comprends avec mon mauvais anglais, dans CA/Browser Forum, ils ont débattu en septembre 2017 de l'ajout possible des ports TCP 25, 115, 22.
Il semble que cette proposition ait été approuvée et devrait être effective en novembre.

Une note du futur SI quelqu'un vient ici de Google (comme moi):

2018-08-29 13:43:33,495: WARNING:certbot.plugins.standalone: 
The standalone specific supported challenges flag is deprecated. 
Please use the --preferred-challenges flag instead.

Si vous utilisez nginx, vous pouvez utiliser le module nginx avec certbot certonly --nginx , il exploite le serveur nginx existant sans aucune configuration.

Le drapeau --http-01-port n'est pas vraiment intuitif et je ne l'ai pas trouvé dans l'aide de la commande et j'ai dû rechercher le drapeau --http-01-port sur Google. Ce serait bien d'avoir le drapeau mentionné dans l'aide.