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.
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;
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.
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).
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?
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.
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.