Назад | Перейти на главную страницу

LetsEncrypt не хочет проверять мой домен

Это беспокоит меня последние пару дней, и я просто не могу понять, что происходит. У меня есть новый сервер, который я настроил (используя Веста, с nginx). У них есть встроенный инструмент для использования LetsEncrypt, и предположительно это сработало:

... а затем редактируемый домен:

В snginx.conf файл имеет настройки в (и эти файлы действительно существуют):

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

У меня также есть это при определении server { немного:

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

Я не получаю ошибок при перезапуске / перезагрузке nginx. Вы когда заходите сюда, вы получаете ошибку: https://steampj.com/

и:

Я сбит с толку, почему это не работает

Вот полный server {} условие для этого домена:

server {
    listen      443 ssl;
    listen      [::]:443 ssl;
    server_name steampj.com www.steampj.com;
    root        /home/admin/web/steampj.com/public_html;
    index       index.php index.html index.htm;
    access_log  /var/log/nginx/domains/steampj.com.log combined;
    access_log  /var/log/nginx/domains/steampj.com.bytes bytes;
    error_log   /var/log/nginx/domains/steampj.com.error.log error;

    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)$ {
            expires     max;
        }

        location ~ [^/]\.php(/|$) {
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            if (!-f $document_root$fastcgi_script_name) {
                return  404;
            }

            fastcgi_pass    127.0.0.1:9005;
            fastcgi_index   index.php;
            include         /etc/nginx/fastcgi_params;
        }
    }

    error_page  403 /error/404.html;
    error_page  404 /error/404.html;
    error_page  500 502 503 504 /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*;
}

Мне было интересно, может быть, брандмауэр блокирует, но, похоже, он установлен как открытый в 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)

а потом:

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)

ОБНОВЛЕНИЕ 2: Мне удалось запустить ipv6 с http. Это было ufw блокирование порта по какой-то причине (отключил его, и все в порядке ... что нормально, так как у нас есть iptables и fail2ban в любом случае)

Я все еще не могу заставить его подключиться к openssl или curl на 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
---

ОБНОВЛЕНИЕ 3: Я не уверен, может ли это быть проблемой, но я заметил, что мой другой сервер (который я установил пару недель назад) использует nginx 1.10.0, тогда как этот новый использует 1.11.13 ... может есть ошибка?

Ваш сертификат работает нормально даже на Android с жесткой политикой.

На основании комментариев:

  • Почти все остальные теперь видят сертификат нормально.
  • Вы по-прежнему получаете ошибки.
  • LetsEncypt все еще не смог его проверить.

Я проверил твой SOA серийный, который 2017040741 со вчерашнего дня и твой TTL установлен на 24 часа. Проблема, скорее всего, в том, что в DNS-кеше вашего рекурсивный DNS-сервер, а также тот, который использует LetsEncrypt. (Все, кто вам помогает, раньше не кешировали его.)

Попробуй снова завтра. Отсюда также можно использовать более короткие TTL, например 21600 на 6 часов.


ОБНОВИТЬ: Вчера с сертификатом вроде все в порядке, а теперь у меня ERR_SSL_PROTOCOL_ERROR.

В подробном режиме curl Я вижу настоящую проблему:

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

Вы обычно получаете SSL23_GET_SERVER_HELLO когда что-то еще прослушивает порт 443. В большинстве случаев это происходит, когда HTTPD прослушивает порт 443 без SSL, но на этот раз это не так, потому что вы получаете ERR_INVALID_HTTP_RESPONSE из http://steampj.com:443/, и как показывает 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

Как твой nginx прослушивал порт 443 на основе lsof -OnP | grep LISTEN проблема скорее всего в конфигурации Nginx.

  1. Проверьте, есть ли у вас другой server {} раздел без необходимости listen 443 и удалите его. Также что у меня было CApath: /etc/ssl/certs вместо настроенного /home/admin/conf/web/ предполагает то же самое.

  2. Убедитесь, что у вас наверняка есть ipv6only=on. У тебя есть:

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

    Согласно документации Nginx ngx_http_core_module на Директива listen:

    ipv6only = on | off

    этот параметр (0.7.42) определяет (через IPV6_V6ONLY параметр сокета), прослушивает ли сокет IPv6 адрес с подстановочными знаками [::] будет принимать только соединения IPv6 или соединения IPv6 и IPv4. По умолчанию этот параметр включен. Его можно установить только один раз при запуске.

    Несмотря на это по умолчанию эта опция должна быть on, вы должны увидеть, установлен ли он off где-нибудь в конфигурации и обновите как свои server { разделы иметь:

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

    Поскольку этот параметр можно установить только один раз при запуске, очень важно, чтобы он on на default_server конфигурация также повлияет на все дальнейшие serverс.

Хорошо, это не совсем ответ как таковой, но мне удалось заставить его работать.

Я начал с нуля и переустановил VestaCP с нуля с:

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 andy.newby@xxx.com --password xxx

Затем я отредактировал /usr/local/vesta/data/templates/web/nginx/default.tpl, поэтому в нем также было:

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

(почему-то там только IPv4, не знаю почему).

Затем я вошел и настроил домен, и вуаля - это сработало!