Nginx – LetsEncrypt doesn’t want to validate the domain

lets-encryptnginx

This has been bugging me for the last couple of days, and I just can't seem to figure out what is going on. I have a new server I setup (using Vesta, with nginx). They have a built-in tool for using LetsEncrypt, and supposedly this has worked:

…and then the domain being edited:

enter image description here

The snginx.conf file has the settings in (and those files do indeed exist):

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

I also have this when defining the server { bit:

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

I get no errors when restarting/reloading nginx. You when you go here, you get an error: https://steampj.com/

enter image description here

and:enter image description here

I'm baffled as to why it's not working

Here is the full server {} condition for that domain:

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

I did wonder if maybe the firewall was blocking, but it seems to be set as open in 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)

and then:

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: I managed to get the ipv6 stuff going with http. It was the ufw blocking the port for some reason (disabled it, and ts fine… which is OK as we have iptables and fail2ban anyway)

I still can't get it to connect with openssl or curl on ipv4 though :/

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: I'm not sure if this could be the issue, but I noticed that my other server (that I setup a couple of weeks ago), is using nginx 1.10.0, whereas this new one is using 1.11.13 … maybe there is a bug?

Best Answer

Your certificate seems to work just fine, even on Android that has strict policy.

As based on comments:

  • Almost everyone else sees the certificate ok now.
  • You still get errors.
  • LetsEncypt couldn't still validate it.

I checked your SOA serial, which is 2017040741 from yesterday and your TTL is set to 24 hours. The problem is most likely that there's wrong IP address in the DNS cache of your recursive DNS server, as well as the one LetsEncrypt uses. (Anyone helping you hasn't cached it before.)

Try again tomorrow. From here, It's also possible to use shorter TTL, e.g. 21600 for 6 hours.

UPDATE: Yesterday the certificate seemed to be fine but now I have ERR_SSL_PROTOCOL_ERROR.

With verbose mode of curl I can see the actual problem:

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

You usually get SSL23_GET_SERVER_HELLO when there's something else listening on port 443. In most cases this happens when HTTPD is listening on port 443 without SSL, but this time that's not the case, because you get ERR_INVALID_HTTP_RESPONSE from http://steampj.com:443/, and as netcat shows:

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

As your nginx was listening to port 443 based on lsof -OnP | grep LISTEN the problem is most likely in the Nginx configuration.

  1. Check whether you have another server {} section unnecessarily having listen 443 and remove it. Also that I had CApath: /etc/ssl/certs instead of configured /home/admin/conf/web/ suggests the same.

  2. Check that you surely have ipv6only=on. You have:

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

    According to Nginx ngx_http_core_module documentation on Directive 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.

    Despite that by default this option should be on, you should see whether it is set off somewhere in the configuration and update both your server { sections to have:

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

    As this parameter can only be set once on start, it's crucial to have it on on the default_server configuration as will also affect all further servers.

Related Topic