Это беспокоит меня последние пару дней, и я просто не могу понять, что происходит. У меня есть новый сервер, который я настроил (используя Веста, с 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 с жесткой политикой.
На основании комментариев:
Я проверил твой 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.
Проверьте, есть ли у вас другой server {}
раздел без необходимости listen 443
и удалите его. Также что у меня было CApath: /etc/ssl/certs
вместо настроенного /home/admin/conf/web/
предполагает то же самое.
Убедитесь, что у вас наверняка есть 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, не знаю почему).
Затем я вошел и настроил домен, и вуаля - это сработало!