Failed authorization procedure. (tls-sni-01):

Please fill out the fields below so we can help you better.

My domain is: app.re-roadmap.com

I ran this command: sudo certbot --nginx -d app.re-roadmap.com

It produced this output: Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for app.re-roadmap.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. app.re-roadmap.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: app.re-roadmap.com
    Type: connection
    Detail: Error getting validation data

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the

My web server is (include version): ubuntu 16.04 nginx on digital ocean droplet

The operating system my web server runs on is (include version): ubuntu 16.04

My hosting provider, if applicable, is: digital ocean

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

It looks like you are advertising an AAAA (IPv6) address record in DNS. Are you sure your host is properly responding to IPv6 requests? This is a common issue.

Hi @jared.m, I thought of that too, but I took a look and the IPv6 configuration looks fine to me!

By contrast, I think the problem might be some kind of firewall or intrusion detection system. When I try to connect on port 80 (in IPv4 or IPv6), everything is great, but when I try to connect on port 443, I get a connection reset error during the TLS negotiation. This is a weird kind of intermediate state between “doesn’t listen on port 443 and refuses connections” and “already listens successfully on port 443 but maybe doesn’t have a valid cert installed”. (Certbot could likely work OK with either of those two situations.) Very, very often the dropped connections like this are due to a firewall or something firewallesque that actively interrupts or drops connections under certain conditions, either in-path like UFW or a hosting provider’s firewall rules or the old-school TCP wrappers library, or on-the-side like an IDS that examines traffic and injects reset packets when it doesn’t like a connection.

Here is my ufw status:

sudo ufw status
Status: active

To Action From


22 LIMIT Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
OpenSSH ALLOW Anywhere
Nginx Full ALLOW Anywhere
22 (v6) LIMIT Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx Full (v6) ALLOW Anywhere (v6)

You might want to see if anything is currently listening to port 443 using netstat -plt.

This is a subdomain. The main domain name is hosted on google/square. All I know is that both the subdomain name and the ip address reliably point to my D-O server.

I only installed nginx and have tried to set it up as per instructions. Currently I have listen: 80; commented out and only using listen: 443;

server {
#listen 80 default_server;
#listen [::]:80 default_server;

    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;

getting original error. (Q: How do I get https to work before I have the cert and the keys?)

Here:

sudo netstat -plt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 localhost:mysql : LISTEN 16593/mysqld
tcp 0 0 :ssh : LISTEN 1565/sshd
tcp 0 0 :https : LISTEN 29535/nginx -g daem
tcp6 0 0 [::]:http-alt [::]:
LISTEN 13667/server.js
tcp6 0 0 [::]:ssh [::]:
LISTEN 1565/sshd
tcp6 0 0 [::]:https [::]:* LISTEN 29535/nginx -g daem

Adding listen 443 before you have a certificate and keys will probably produce an error (maybe this exact error; you could check your nginx error logs?). Certbot does not expect you to add listen 443 directives yourself if you don’t have a previous certificate. If you’re using certbot --nginx, it adds them for you when appropriate.

OK I undid the 443 back to 80 and verified and wbe page opens as normal.

Tried the certbot command and got the same as original post.

This site loads very slow right now - could that affect anything?

Also, you suggested looking at the error log - here is the latest few (I think it shows when i had the 443 in place and then what happened when i did the certbot):

2017/08/10 20:01:37 [error] 29592#29592: *21 no “ssl_certificate” is defined in server listening on SSL port while SSL handshaking, client: 70.169.115.30, server: 0.0.0.0:443
2017/08/10 20:10:14 [error] 30516#30516: *49 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 70.169.115.30, server: app.re-roadmap.com, request: “GET /lib/icons/icomoon.woff?3p0rtw HTTP/1.1”, upstream: “http://127.0.0.1:8080/lib/icons/icomoon.woff?3p0rtw”, host: “159.203.124.184”, referrer: "http://159.203.124.184/lib/css/main.css"
2017/08/10 20:12:39 [notice] 30760#30760: signal process started
2017/08/10 20:12:43 [notice] 30763#30763: signal process started

I see a kind of catch 22 happening here:
The --nginx auth requires 443 but your not setup for 443 nor allowing 443.
You might want to try –webroot -w /path/to/your/web/site instead of --nginx, as that would use port 80 for auth.

This is something a misconception that I tried to address earlier in this thread:

certbot --apache and certbot --nginx do not assume that your web server is already listening on port 443, only that it will be permitted (by firewalls, etc.) to do so after reconfiguration. You don’t need to have an existing certificate to use certbot --apache or certbot --nginx, and your web server doesn’t need to already be configured to listen on port 443. Both of these methods do listen on port 443 as part of the certificate issuance process, but, if necessary, they’ll reconfigure your web server to listen on that port (using a temporary, internally-generated certificate rather than any pre-existing certificate).

1 Like

That’s good to know but it seems different that what is found at: https://certbot.eff.org/docs/using.html#id5
Which seems to indicate that --nginx only supports “tls-sni-01 (443)” but doesn’t make it clear as how the tls is handled.
The “User Guide” may need some added detail to clarify that confusion.

It definitely only supports using port 443, but it doesn’t require that your nginx is already listening on port 443. Could you suggest any language for the documentation to clear this up? Maybe just something like “If your nginx server isn’t already listening on port 443, that’s OK; Certbot can configure it to do so”?

Thanks @schoen and @rg305 - any ideas how to further test the problem? Do I
need to do something different, like buy a SSL? Re-install? Start over?
Thanks.

Can you find anywhere else in your nginx configuration where you tell it to listen on port 443? Is it still listening on port 443 according to netstat -plt?

My preference would be to figure out how to stop your current nginx configuration from listening on port 443, and then use certbot --nginx again. However, there is also a form with certbot --webroot which used to be very widely used by nginx users, but is less preferred nowadays because it doesn’t install the certificate for you after containing it. This is also likely to work if necessary.

Do you know why your site is generating an HTTP redirect to use the IP address?

sshd?

Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program name
tcp 0 0 localhost:mysql :
LISTEN 16593/mysqld
tcp 0 0 :http :
LISTEN 30182/nginx -g daem
tcp 0 0 :ssh :
LISTEN 1565/sshd
tcp6 0 0 [::]:http-alt [::]:

LISTEN 30213/server.js
tcp6 0 0 [::]:http [::]:

LISTEN 30182/nginx -g daem
tcp6 0 0 [::]:ssh [::]:*
LISTEN 1565/sshd

That seems to be listening on port 22 rather than 443.

I’m still convinced that there is something in your network or infrastructure that’s actively interrupting connections. Your server accepts TCP connections on port 443 even though there is no process known to the OS listening on the port. Then it drops them as soon as the client sends any data. This is not the same behavior that we see when trying to connect to you on other ports.

thanks Sean for all the help - i am going to scrap it and start over.

i absolutely believe in letsencrypt but my experience has been so
difficult…

I would try:
"–standalone" with "–preferred-challenges"
see https://certbot.eff.org/docs/using.html#id9 for info

OK Everyone who is checking this:

tl;dr Did the exact same thing on a clean build

I did a ReBuild of the digital ocean droplet ubuntu server, so everything was clean.

I did the preliminaries exactly as recommended by these webpages:

I did this command: sudo certbot --nginx -d app.re-roadmap.com
And got exactly the same error I originally reported:

Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for app.re-roadmap.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. app.re-roadmap.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: app.re-roadmap.com
    Type: connection
    Detail: Error getting validation data

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

  • Your account credentials have been saved in your Certbot
    configuration directory at /etc/letsencrypt. You should make a
    secure backup of this folder now. This configuration directory will
    also contain certificates and private keys obtained by Certbot so
    making regular backups of this folder is ideal.