Certbot: Erreur: options d'écoute en double pour [::]: 443

@iamdubx avez-vous

Même problème ... Cela fonctionne pour mon site par défaut, mais pas pour un sous-domaine personnalisé

J'ai le même problème.

J'ai cependant une configuration pour attraper plusieurs domaines.

server {
  listen 80;
  listen [::]:80;

  root /home/primarydomain/public;
  index index.html index.htm;

  server_name domain1.com *.domain1.com domain2.com *.domain2.com domain3.com *.domain3.com domain4.com *.domain4.com;

  return 302 $scheme://primarydomain.com$request_uri;

  access_log /var/log/nginx/others.access.log;
  error_log /var/log/nginx/others.error.log;

  location / {
    try_files $uri $uri/ /index.html =404;
  }
}

J'obtiens nginx: [emerg] duplicate listen options for [::]:443 in /etc/nginx/sites-enabled/others:19 pour cette configuration.

Système d'exploitation: Ubuntu 16.04. De l'aide?

Même problème.

J'ai exécuté la commande: certbot --redirect --nginx -d readacted.com -d www.redacted.com

mon fichier de configuration d'origine ressemble à:

    server {
        server_name redacted.com;
        location / {
        root   /home/redacted/www;
        index  index.html;
      }
    }

    server {
        listen 80;
        listen [::]:80;
        server_name www.redacted.com;
        return 301 $scheme://redacted.com$request_uri;
    }

selon /var/log/letsencrypt/letsencrypt.log je vois que certbot essaie de faire ceci:

    server {
        server_name redacted.com;
        location / {
        root   /home/redacted/www;
        index  index.html;
      }

        listen [::]:443 ssl ipv6only=on; # managed by Certbot
        listen 443 ssl; # managed by Certbot
        ssl_certificate /etc/letsencrypt/live/redacted.com-0001/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/redacted.com-0001/privkey.pem; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    }

    server {
        listen 80;
        listen [::]:80;
        server_name www.redacted.com;
        return 301 $scheme://redacted.com$request_uri;

        listen [::]:443 ssl ipv6only=on; # managed by Certbot
        listen 443 ssl; # managed by Certbot
        ssl_certificate /etc/letsencrypt/live/www.redacted.com/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/www.redacted.com/privkey.pem; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    }

nginx se plaint que sur la ligne listen [::]:443 ssl ipv6only=on; # managed by Certbot

le message d'erreur réel:

nginx: [emerg] duplicate listen options for [::]:443 in /etc/nginx/sites-enabled/redacted.com:23

un google rapide a fait apparaître cette page à partir de 2010:

http://www.serverphorums.com/read.php?5 , 203912

ce qui suggère que nginx est confus en raison de certains détails d'implémentation interne.

Je ne suis pas un expert nginx, mais j'ai testé que ce qui suit semble fonctionner:

    server {
        server_name redacted.com;
        location / {
        root   /home/redacted/www;
        index  index.html;
      }

        listen [::]:443 ssl ipv6only=on; # managed by Certbot
        listen 443 ssl; # managed by Certbot
        ssl_certificate /etc/letsencrypt/live/redacted.com-0001/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/redacted.com-0001/privkey.pem; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    }

    server {
        listen 80;
        listen [::]:80;
        server_name www.redacted.com;
        return 301 http://redacted.com$request_uri;

        listen [::]:443; # manually changed
        ssl on;  #manually changed
        listen 443 ssl; # managed by Certbot
        ssl_certificate /etc/letsencrypt/live/www.redacted.com/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/www.redacted.com/privkey.pem; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    }

J'aimerais une meilleure solution que cette solution de contournement idéalement ...

@ohemorange , savez-vous si nous avons un problème de suivi? Cela me semble familier, mais je ne me souviens pas si c'est quelque chose que nous avons examiné auparavant.

Je n'avais jamais vu ça avant. On dirait qu'ils ont corrigé le bogue d'origine, sauf lorsque vous utilisez IPv6. Et puisque nous venons de lancer la prise en charge IPv6, c'est pourquoi les gens le font. La solution ci-dessus fonctionnera; Je vais voir s'il y a une raison pour laquelle cela n'a pas encore été corrigé dans Nginx pour IPv6.

En fait, vous n'avez même pas besoin de faire le changement ssl on - supprimer ipv6only=on de l'un ou des deux résout le problème.

@joohoi , nous voulons probablement résoudre ce problème en supprimant complètement ipv6only=on ou en ne le mettant qu'une seule fois par ligne d'adresse unique que nous ajoutons. Avez-vous une idée de ce qui serait le mieux ici?

Avoir le même problème ici. Tout allait bien pour mon premier domaine. Le deuxième domaine a commencé à avoir ces problèmes.

Il semble que Certbot est incapable de détecter complètement la directive ipv6only pour une raison quelconque. Supprimer cela résoudrait le problème pour la plupart des utilisateurs. Cela peut causer des problèmes avec les très anciennes versions de Nginx, car le comportement d'ipv6only et les valeurs par défaut ont changé au fil du temps.

Toutes mes excuses pour le mauvais patch, mais cela a résolu le problème pour moi, j'espère qu'il y aura bientôt une solution appropriée!

--- /usr/lib/python3/dist-packages/certbot_nginx/configurator.py.orig   2018-02-14 18:38:30.380863045 +0000
+++ /usr/lib/python3/dist-packages/certbot_nginx/configurator.py    2018-02-14 18:38:01.501018553 +0000
@@ -507,10 +507,10 @@ class NginxConfigurator(common.Installer
                           '[::]:{0}'.format(self.config.tls_sni_01_port),
                           ' ',
                           'ssl']
-            if not ipv6info[1]:
-                # ipv6only=on is absent in global config
-                ipv6_block.append(' ')
-                ipv6_block.append('ipv6only=on')
+            #if not ipv6info[1]:
+            #    # ipv6only=on is absent in global config
+            #    ipv6_block.append(' ')
+            #    ipv6_block.append('ipv6only=on')

         if vhost.ipv4_enabled():
             ipv4_block = ['\n    ',

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial
$ nginx -V
nginx version: nginx/1.10.3 (Ubuntu)
built with OpenSSL 1.0.2g  1 Mar 2016
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads
$ apt show python-certbot-nginx
Package: python-certbot-nginx
Version: 0.21.1-1+ubuntu16.04.1+certbot+1
Priority: optional
Section: oldlibs
Maintainer: Debian Let's Encrypt <[email protected]>
Installed-Size: 9,216 B
Depends: python3-certbot-nginx
Download-Size: 2,470 B
APT-Manual-Installed: yes
APT-Sources: http://ppa.launchpad.net/certbot/certbot/ubuntu xenial/main amd64 Packages
Description: transitional dummy package
 This is a transitional dummy package for the migration of certbot
 from python2 to python3.  It can be safely removed.

Même problème. Cela sera-t-il réglé?

Désolé pour le mur de texte, mais c'est parti.

Pour faire la lumière sur le problème:
L'option ipv6only est utilisée pour pouvoir gérer plusieurs instructions d'écoute par socket. Malheureusement, il ne peut être utilisé qu'une seule fois dans la configuration du serveur pour le socket. Donc Nginx ne démarrera pas en cas de:

server {
    ...
    server_name first.example.org;
    listen [::]:80 ipv6only=on;
    listen 80;
} 
server {
    ...
    server_name second.example.org;
    listen [::]:80 ipv6only=on;
    listen 80;
}

Avec les versions récentes de Nginx, ce problème n'existe pas si le paramètre ipv6only est complètement omis, car la valeur par défaut de la variable est ipv6only=on . Donc, ce qui suit est une configuration valide et fonctionnelle dans les versions Nginx> = 1.3.4:

server {
    ...
    server_name first.example.org;
    listen [::]:80;
    listen 80;
} 
server {
    ...
    server_name second.example.org;
    listen [::]:80;
    listen 80;
}

Cependant, la valeur par défaut de la variable ipv6only dans les versions Nginx antérieures à 1.3.4 était ipv6only=off , donc les anciennes versions échoueront avec la configuration suivante:

server {
    ...
    server_name first.example.org;
    listen [::]:80;
    listen 80;
} 

Actuellement, la situation avec l'empaquetage de distribution est que la seule distribution livrée avec une version plus ancienne de Nginx serait Debian Wheezy (Debian 7), qui fournit la version 1.2.1 de Nginx à partir des dépôts par défaut.

Si nous supprimions complètement la détection et le paramètre ipv6only de Certbot, cela serait interrompu pour tous les utilisateurs de Debian Wheezy. Heureusement, la date EOL pour Wheezy est fixée à mai 2018 , nous sommes donc sur le point de pouvoir supprimer complètement cette complexité supplémentaire du code Certbot.

La fonctionnalité actuelle de Certbot analyse la configuration complète de Nginx, détectant le paramètre ipv6only=on déjà présent dans l'un des blocs server{} et en omettant l'ajout si c'est le cas. Si toutefois la valeur n'était pas trouvée, Certbot l'ajouterait. Ce problème se résume au fait que Certbot ne peut pas détecter cette variable déjà existante à partir d'un bloc de la configuration actuelle de l'utilisateur, et tente donc de l'ajouter au bloc server{} en cours de configuration.

Pour prendre la décision de la route pour résoudre ce problème, nous aurions besoin d'un exemple de configuration complet où Certbot échoue de la manière décrite ci-dessus pour être en mesure d'améliorer la détection d'une variable ipv6only=on déjà existante si nous décidons de corriger de cette façon au lieu de supprimer complètement cette fonctionnalité.

Merci pour le patch; cela a fonctionné pour moi. FWIW, je suis sur Ubuntu 17.

J'ai dû supprimer tous les

listen [::]:80;
listen 80;

Pour que ça marche

https://github.com/chilion - merci! suppression:

listen [::]:80;
listen 80;

a également travaillé pour moi.

J'ai deux domaines sur un serveur Ubuntu. Le premier a fonctionné sans problème. Ensuite, j'ai eu l'erreur comme ci-dessus. Votre solution a fonctionné pour moi. Je viens d'installer nginx sur un nouveau serveur avec tout frais.

Je vous remercie.

supprimer listen [::]:80 mais laisser listen 80; fonctionné pour moi pour l'installation sur un domaine non par défaut

Je commente écouter [::]: 443 dans le paramètre de sous-domaine, alors cela fonctionne. Ça va

Je viens de tomber sur ce problème. Tout corps essayant de donner un sens aux différentes directives listen et ipv6only .

Je recommande vivement cet article de blog, jusqu'à ce que je trouve cet article, je ne savais pas quoi faire avec tous les différents conseils que je trouvais sur le Web.

https://stefanchrist.eu/blog/2015_01_21/Using%20ipv6only%20in%20Nginx.xhtml

Cette citation du billet de blog a été le moment de l'ampoule pour moi.

Le paramètre est différent, par exemple, de l'indicateur ssl. Le drapeau ssl peut être utilisé dans plusieurs contextes de serveur et être activé et désactivé à votre guise. L'indicateur ipv6only ne peut être défini qu'une seule fois par port (et adresse). Une seule directive d'écoute peut contenir le paramètre et il sera valide pour tous les contextes de serveur utilisant ce port. Si vous l'utilisez deux fois, le démon nginx ne démarrera pas et écrira les messages d'erreur suivants dans son journal des erreurs

Existe toujours, après la purge de python, réinstallez cette erreur levée. Erreur quelque part dans certbot

Le commentaire de cette ligne résout l'erreur, mais crée d'autres problèmes

server {
        listen  443 ssl http2;
#        listen [::]:443 ssl http2 ipv6only=on;

En cas de domaines multiples

Au lieu de
écoute [::]: 443 ssl http2 ipv6only = on;

Utilisation
écoutez l'exemple. com: 443 ssl http2 ipv6only = activé;

Omettez la directive listen dans tous vos blocs de serveur.

Cette erreur apparaît lorsque deux blocs de serveur écoutent sur le même domaine avec le même port.
Vérifiez tous vos fichiers de configuration dans le dossier sites disponibles pour l'écouteur en double. Dans mon cas, certbot a créé un double écouteur pour 443 dans le fichier par défaut.

Si vous pouvez fournir des fichiers de configuration pour reproduire cela avec une version à jour de Certbot, je serais intéressé de les voir.

nginx: [émerg] un serveur par défaut en double pour

Pour les aventuriers qui pourraient atteindre ce ticket à l'avenir via une recherche solitaire, et ils ne peuvent pas comprendre pourquoi cela se produit alors qu'ils n'ont pas de ipv6only=on ailleurs.

Vous obtiendrez la même erreur / problème si vous avez reuseport dans votre configuration.

J'admets que je suis confus. Selon la documentation de nginx , il existe un certain nombre de paramètres pour listen , mais seulement ipv6only spécifie "Il ne peut être défini qu'une seule fois au démarrage." Cette ligne est-elle simplement absente des paramètres restants? Cela dépend-il du système? Je commence à penser que corriger ce comportement en amont pourrait être le meilleur plan d'action; il semble idiot de ne permettre que ces options ne soient définies qu'une seule fois, de toute façon.

Je ne suis malheureusement pas un expert des sockets Linux, donc je ne peux pas me forger une opinion correcte sur les raisons pour lesquelles ces options ne peuvent être définies qu'une seule fois, mais je suis sûr qu'il y a une raison.

Peut-être que cet article aide: https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/

Ce que je sais, c'est que, tout comme ipv6only , reuseport ne peut être défini qu'une seule fois par port spécifique (donc un seul auditeur peut l'avoir). Pourquoi cela est en conflit (faute d'un meilleur mot) avec ipv6only , je n'en ai aucune idée.

Pourtant, j'ai envie d'ajouter ipv6only=on lors de l'exécution de certbot est un peu futile.

Il n'est plus nécessaire depuis nginx 1.3.4, qui a été publié en 2012 , et c'est techniquement EOL.

Au moins, il devrait peut-être y avoir une vérification de version et l'ajouter seulement si c'est nginx < 1.3.4 avant de l'ajouter.

Nous ne le définissons pas dans Certbot. Lorsque nous créons un bloc serveur, nous copions certaines directives à partir du bloc serveur par défaut existant, ou d'un autre bloc serveur modèle, y compris la directive listen avec ses options. Cela permet à Certbot de fonctionner même si Nginx est derrière un proxy ou un autre type de redirection de port. Nous supprimiez ipv6only=on du bloc de serveur dupliquée , car la documentation indique qu'il ne peut être utilisé qu'une seule fois.

Idéalement, nous ferions la même chose pour toutes les options dont nous savons qu'elles ne peuvent pas être dupliquées de cette manière, mais nous laissons d'autres options que l'utilisateur peut souhaiter spécifiquement que tous ses blocs de serveur aient. Pour ce faire, nous devons savoir quelles options sont reproductibles, que la documentation ne semble pas indiquer, et que nous semblons découvrir uniquement grâce à des personnes qui viennent nous voir sur des questions comme celle-ci.

Merci @joohoi
Votre explication et votre solution ont fonctionné pour moi sur Ubuntu 20 avec la version nginx: 1.18.0

J'ai 2 VPS: 1 est Ubuntu exécute Nginx 1.10 fonctionne bien, l'autre est Centos exécute Nginx 1.16 et a cette erreur. Bizarre