LetsEncrypt não quer validar meu domínio

Question

Isso tem me incomodado nos últimos dois dias, e eu simplesmente não consigo descobrir o que está acontecendo. Eu tenho um novo servidor que eu configurei (usando Vesta , com nginx). Eles têm uma ferramenta interna para usar LetsEncrypt , e supostamente isso funcionou:

...edepoisodomíniosendoeditado:

Oarquivosnginx.conftemasconfigurações(eessesarquivosrealmenteexistem):

ssl_certificate/home/admin/conf/web/ssl.steampj.com.pem;ssl_certificate_key/home/admin/conf/web/ssl.steampj.com.key;

Tambémtenhoissoaodefiniroserver{bit:

server{listen443ssl;listen[::]:443ssl;

Nãoreceboerrosaoreiniciar/recarregaronginx.Quandovocêchegaaqui,recebeumerro: link

e:

Estouconfusosobreoporquêdenãoestarfuncionando

Aquiestáacondiçãoserver{}completaparaessedomínio:

server{listen443ssl;listen[::]:443ssl;server_namesteampj.comwww.steampj.com;root/home/admin/web/steampj.com/public_html;indexindex.phpindex.htmlindex.htm;access_log/var/log/nginx/domains/steampj.com.logcombined;access_log/var/log/nginx/domains/steampj.com.bytesbytes;error_log/var/log/nginx/domains/steampj.com.error.logerror;ssl_certificate/home/admin/conf/web/ssl.steampj.com.pem;ssl_certificate_key/home/admin/conf/web/ssl.steampj.com.key;location/{location~*^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)${expiresmax;}location~[^/]\.php(/|$){fastcgi_paramSCRIPT_FILENAME$document_root$fastcgi_script_name;if(!-f$document_root$fastcgi_script_name){return404;}fastcgi_pass127.0.0.1:9005;fastcgi_indexindex.php;include/etc/nginx/fastcgi_params;}}error_page403/error/404.html;error_page404/error/404.html;error_page500502503504/error/50x.html;location/error/{alias/home/admin/web/steampj.com/document_errors/;}location~*"/\.(htaccess|htpasswd)$" {
        deny    all;
        return  404;
    }

    location /vstats/ {
        alias   /home/admin/web/steampj.com/stats/;
        include /home/admin/web/steampj.com/stats/auth.conf*;
    }

    include     /etc/nginx/conf.d/phpmyadmin.inc*;
    include     /etc/nginx/conf.d/phppgadmin.inc*;
    include     /etc/nginx/conf.d/webmail.inc*;

    include     /home/admin/conf/web/snginx.steampj.com.conf*;
}

Eu me perguntei se talvez o firewall estava bloqueando, mas parece estar definido como aberto em ufw :

root@com:~# ufw status
Status: active

To                         Action      From
--                         ------      ----
8181                       ALLOW       Anywhere
443                        ALLOW       Anywhere
8181 (v6)                  ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)

e depois:

root@com:~# lsof -OnP | grep LISTEN
nginx      2382                     root   22u     IPv4              95181      0t0        TCP 213.219.38.44:443 (LISTEN)
nginx      2382                     root   45u     IPv6             264609      0t0        TCP *:443 (LISTEN)
nginx      2637                 www-data   22u     IPv4              95181      0t0        TCP 213.219.38.44:443 (LISTEN)
nginx      2637                 www-data   45u     IPv6             264609      0t0        TCP *:443 (LISTEN)
nginx      2638                 www-data   22u     IPv4              95181      0t0        TCP 213.219.38.44:443 (LISTEN)
nginx      2638                 www-data   45u     IPv6             264609      0t0        TCP *:443 (LISTEN)

UPDATE 2: Eu consegui fazer o material do ipv6 com o http. Foi o ufw que bloqueia a porta por algum motivo (desativado, e ts bem ... o que é OK como temos iptables e fail2ban de qualquer maneira)

Ainda não consigo conectá-lo ao openssl ou enrolar no ipv4: /

root@steamdev2:~# curl -Iv4 https://steampj.com/
* Hostname was NOT found in DNS cache
*   Trying 213.219.38.44...
* Connected to steampj.com (213.219.38.44) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS Unknown, Unknown (22):
* SSLv3, TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol


root@steamdev2:~# openssl s_client -connect steampj.com:443
CONNECTED(00000003)
139846633119256:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 315 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

UPDATE 3: Não tenho certeza se esse poderia ser o problema, mas notei que meu outro servidor (que eu configurei há algumas semanas) está usando o nginx 1.10 .0 , enquanto este novo está usando 1.11.13 ... talvez haja um bug?

    

Answer 1

Seu certificado parece funcionar bem, mesmo no Android, que possui uma política rígida.

Como baseado nos comentários:

• Quase todo mundo vê o certificado agora.
• Você ainda recebe erros.
• O LetsEncypt ainda não pôde validá-lo.

Eu verifiquei seu SOA serial, que é 2017040741 de ontem e seu TTL está definido como 24 horas. O problema é que provavelmente existe um endereço IP incorreto no cache DNS do servidor DNS recursivo , bem como o usado pelo LetsEncrypt. (Qualquer um que esteja ajudando você não colocou o cache antes.)

Tente novamente amanhã. A partir daqui, também é possível usar TTL , por ex. 21600 por 6 horas.

ATUALIZAÇÃO: Ontem, o certificado parecia estar bem, mas agora eu tenho ERR_SSL_PROTOCOL_ERROR .

Com o modo detalhado de curl , posso ver o problema real:

curl -v -ipv4 https://steampj.com/
* About to connect() to steampj.com port 443 (#0)
*   Trying 213.219.38.44...
* connected
* Connected to steampj.com (213.219.38.44) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection #0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

Normalmente, você recebe SSL23_GET_SERVER_HELLO quando há outra coisa ouvindo na porta 443. Na maioria dos casos, isso acontece quando o HTTPD está escutando na porta 443 sem SSL, mas desta vez não é o caso, porque você obtém ERR_INVALID_HTTP_RESPONSE de link , e como mostra o netcat:

nc -v steampj.com 443
DNS fwd/rev mismatch: steampj.com != li1097-44.members.linode.com
steampj.com [213.219.38.44] 443 (https) open
GET / HTTP/1.1
▒▒▒PuTTY

Como seu nginx estava ouvindo a porta 443 com base em lsof -OnP | grep LISTEN , o problema é mais provável na configuração do Nginx.

1. Verifique se você tem outra seção server {} desnecessariamente com listen 443 e remova-a. Também que eu tive CApath: /etc/ssl/certs em vez de configurado /home/admin/conf/web/ sugere o mesmo.

2. Verifique se você tem ipv6only=on . Você tem:

   server {
       listen      443 ssl;
       listen      [::]:443 ssl;
   

   De acordo com a documentação do Nginx ngx_http_core_module, na Diretiva listen :

   ipv6only=on|off

   this parameter (0.7.42) determines (via the IPV6_V6ONLY socket option) whether an IPv6 socket listening on a wildcard address [::] will accept only IPv6 connections or both IPv6 and IPv4 connections. This parameter is turned on by default. It can only be set once on start.

   Apesar disso, por padrão, essa opção deve ser on , você deve ver se ela está definida off em algum lugar na configuração e atualizar ambas as seções server { para ter:

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

   Como esse parâmetro só pode ser definido uma vez no início, é crucial ter on na configuração default_server , o que também afetará mais server s.

Answer 2

Ok, bem, isso não é realmente uma "resposta" como tal, mas eu consegui fazê-lo funcionar.

Eu comecei do zero e re-instalei o VestaCP do zero com:

curl -O http://vestacp.com/pub/vst-install.sh

bash vst-install.sh --nginx yes --apache yes --phpfpm no --named no --remi yes --vsftpd yes --proftpd no --iptables yes --fail2ban yes --quota no --exim yes --dovecot yes --spamassassin yes --clamav yes --mysql yes --postgresql no --hostname com.mysite.com --email [email protected] --password xxx

Eu editei /usr/local/vesta/data/templates/web/nginx/default.tpl, então ele também tinha:

listen      [%ip%]:%proxy_port% ssl;

(por alguma razão, só tem IPv4 lá, não sei porquê).

Eu entrei e configurei o domínio, e voila - funcionou!