Certbot: Erro: opções de escuta duplicadas para [::]: 443

@iamdubx você descobriu isso? Estou tendo o mesmo problema.

Mesmo problema ... Funciona para meu site padrão, mas não para subdomínio personalizado

Estou tendo o mesmo problema.

Eu tenho uma configuração para capturar vários domínios.

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;
  }
}

Eu recebo nginx: [emerg] duplicate listen options for [::]:443 in /etc/nginx/sites-enabled/others:19 por esta configuração.

SO: Ubuntu 16.04. Qualquer ajuda?

Mesmo problema.

Executei o comando: certbot --redirect --nginx -d readacted.com -d www.redacted.com

meu arquivo conf original se parece com:

    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;
    }

de acordo com /var/log/letsencrypt/letsencrypt.log, vejo que o certbot está tentando fazer isso:

    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 reclama que na linha listen [::]:443 ssl ipv6only=on; # managed by Certbot

a mensagem de erro real:

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

um rápido google trouxe esta página de 2010:

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

o que sugere que o nginx fica confuso devido a alguns detalhes de implementação interna.

Não sou um especialista em nginx, mas testei que o seguinte parece funcionar:

    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

    }

Eu adoraria uma solução melhor que esta solução alternativa idealmente ...

@ohemorange , você sabe se temos um problema existente rastreando isso? Parece familiar para mim, mas não me lembro se é ou não algo que examinamos antes.

Eu nunca vi isso antes. Parece que eles consertaram o bug original, exceto quando você está usando IPv6. E como acabamos de lançar o suporte ao IPv6, é por isso que as pessoas estão começando a pensar nisso. A solução acima funcionará; Vou ver se há um motivo pelo qual isso ainda não foi corrigido no Nginx para IPv6.

Na verdade, você nem mesmo precisa fazer a ssl on alteração - remover ipv6only=on de um ou de ambos corrige o problema.

@joohoi , provavelmente queremos corrigir isso removendo ipv6only=on completamente ou apenas colocando-o uma vez por linha de endereço exclusivo que adicionarmos. Você tem uma ideia do que seria melhor aqui?

Tenho o mesmo problema aqui. Tudo estava bem para meu primeiro domínio. O segundo domínio começou a ter esses problemas.

Parece que o Certbot não consegue detectar a diretiva ipv6only completamente por algum motivo. Remover isso resolveria o problema para a maioria dos usuários. Isso pode causar alguns problemas com versões realmente antigas do Nginx, pois o comportamento do ipv6only e os padrões mudaram ao longo do tempo.

Peço desculpas pelo patch desagradável, mas isso corrigiu para mim, espero que haja uma correção adequada em breve!

--- /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.

O mesmo problema. Isso será abordado?

Desculpe pela parede de texto, mas vamos lá.

Para lançar alguma luz sobre o problema:
A opção ipv6only é usada para lidar com várias instruções de escuta por soquete. Infelizmente, ele só pode ser usado uma vez na configuração do servidor para o soquete. Portanto, o Nginx não será iniciado em caso 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;
}

Com as versões recentes do Nginx, esse problema não existe se a configuração ipv6only for omitida completamente, pois o valor padrão da variável é ipv6only=on . Portanto, o seguinte é uma configuração válida e funcional nas versões Nginx> = 1.3.4:

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

No entanto, o valor padrão da variável ipv6only nas versões do Nginx anteriores a 1.3.4 era ipv6only=off , portanto, as versões mais antigas falharão com a seguinte configuração:

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

Atualmente, a situação com o empacotamento da distribuição é que a única distribuição que vem com uma versão mais antiga do Nginx seria o Debian Wheezy (Debian 7), que vem com a versão 1.2.1 do Nginx dos repositórios padrão.

Se removêssemos a detecção e configuração ipv6only completamente do Certbot, isso quebraria para todos os usuários do Debian Wheezy. Felizmente, a data EOL para Wheezy está definida para maio de 2018 , então estamos perto de poder remover essa complexidade adicional do código do Certbot por completo.

A funcionalidade atual do Certbot está analisando a configuração Nginx completa, detectando a configuração ipv6only=on já presente em um dos blocos server{} e omitindo sua adição se for o caso. Porém, se o valor não for encontrado, o Certbot o adicionará. Esse problema se resume ao Certbot não ser capaz de detectar essa variável já existente de algum bloco da configuração atual do usuário e, portanto, tenta adicioná-la ao bloco server{} que está sendo configurado.

Para tomar a decisão da rota para corrigir esse problema, precisaríamos de um exemplo de configuração completo em que o Certbot falhe da maneira descrita acima para poder melhorar a detecção de uma variável ipv6only=on já existente se decidirmos corrigir dessa forma, em vez de remover essa funcionalidade por completo.

Obrigado pelo patch; que funcionou para mim. FWIW, estou no Ubuntu 17.

Eu tive que remover todos os

listen [::]:80;
listen 80;

Para fazer funcionar

https://github.com/chilion - obrigado! removendo:

listen [::]:80;
listen 80;

funcionou para mim também.

Eu tenho dois domínios em um servidor Ubuntu. O primeiro funcionou sem problemas. Então eu obtive o erro acima. Sua solução funcionou para mim. Acabei de instalar o nginx em um servidor novo com tudo novo.

Obrigado.

remover listen [::]:80 mas deixar listen 80; funcionou para mim para instalação em domínio não padrão

Eu comento listen [::]: 443 na configuração do subdomínio, então funciona. Está tudo bem

Acabei de me deparar com esse problema. Qualquer entidade tentando entender as diferentes diretivas listen e ipv6only .

Eu recomendo fortemente esta postagem do blog, até encontrar este artigo eu não tinha certeza do que fazer com todos os diferentes conselhos que estava encontrando na web.

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

Esta citação do post do blog foi o momento da lâmpada para mim.

O parâmetro é diferente, por exemplo, do sinalizador ssl. A sinalização ssl pode ser usada em vários contextos de servidor e pode ser ligada e desligada conforme desejar. O sinalizador ipv6only só pode ser definido uma vez por porta (e endereço). Apenas uma única diretiva de escuta pode conter o parâmetro e será válida para todos os contextos de servidor que usam esta porta. Se você usá-lo duas vezes, o daemon nginx não iniciará e gravará as seguintes mensagens de erro em seu log de erros

Ainda existe, após a limpeza do python, reinstale este erro lançado. Erro em algum lugar no certbot

Comentar esta linha resolve o erro, mas cria outros problemas

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

No caso de múltiplos domínios

Ao invés de
ouvir [::]: 443 ssl http2 ipv6only = ativado;

Usar
ouça o exemplo. com: 443 ssl http2 ipv6only = on;

Omita a diretiva listen em todos os seus blocos de servidor.

Este erro aparece quando há dois blocos de servidor escutando no mesmo domínio com a mesma porta.
Verifique todos os seus arquivos de configuração na pasta de sites disponíveis para o ouvinte duplicado. No meu caso, o certbot criou um listener duplicado para 443 no arquivo padrão.

Se você puder fornecer arquivos de configuração para reproduzir isso com uma versão atualizada do Certbot, estou interessado em vê-los.

nginx: [emerg] um servidor padrão duplicado para

Para os aventureiros que podem obter este bilhete no futuro por meio de uma busca solitária, e eles não conseguem descobrir por que isso acontece quando não têm ipv6only=on nenhum outro lugar.

Você obterá o mesmo erro / problema se tiver reuseport em sua configuração.

Eu admito, estou confuso. De acordo com a documentação do listen , mas apenas ipv6only especifica "Só pode ser definido uma vez na inicialização." Esta linha está faltando nos parâmetros restantes? Depende do sistema? Estou começando a pensar que corrigir esse comportamento no upstream pode ser o melhor curso de ação; parece bobagem permitir que essas opções sejam definidas apenas uma vez.

Infelizmente, não sou um especialista em soquetes de Linux, então não consigo formar uma opinião adequada sobre por que essas opções só podem ser definidas uma vez, mas tenho certeza de que há um motivo.

Talvez esta postagem ajude: https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/

O que eu sei é que, assim como ipv6only , reuseport também só pode ser definido uma vez por porta específica (portanto, apenas um ouvinte pode tê-lo). Por que isso conflita acidentalmente (por falta de uma palavra melhor) com ipv6only , não tenho ideia.

Ainda assim, acho que adicionar ipv6only=on ao executar o certbot é um pouco inútil.

Ele não é mais necessário desde o nginx 1.3.4, que foi lançado em 2012 , e é tecnicamente EOL.

No mínimo, talvez deva haver uma verificação de versão e apenas adicionar se nginx < 1.3.4 antes de adicioná-lo.

Não o configuramos no Certbot. Quando criamos um bloco de servidor, copiamos algumas diretivas do bloco de servidor padrão existente ou outro bloco de servidor de modelo, incluindo a diretiva de escuta junto com suas opções. Isso permite que o Certbot funcione mesmo se o Nginx estiver atrás de um proxy ou outro tipo de encaminhamento de porta. Nós explicitamente excluir ipv6only=on a partir do bloco servidor duplicado porque a documentação indica que ele só pode ser usado uma vez.

Idealmente, faríamos o mesmo para todas as opções que sabemos que não podem ser duplicadas dessa forma, mas deixamos outras opções que o usuário pode querer especificamente que todos os seus blocos de servidor tenham. Para fazer isso, temos que saber quais opções são repetíveis, que a documentação não parece indicar e que só parecemos descobrir por meio de pessoas que nos procuram sobre questões como esta.

Obrigado @joohoi
Sua explicação e solução funcionaram para mim no Ubuntu 20 com versão nginx: 1.18.0

Eu tenho 2 VPS: 1 é o Ubuntu roda Nginx 1.10 funciona bem, o outro é Centos executa Nginx 1.16 e tem esse erro. Esquisito