Renewing certificate for one particular domain giving errors

[rleeden]

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

My domain is: https://parkrunstats.servehttp.com

I ran this command: certbot-auto certonly --dry-run -n --webroot -w /website/parkrun -d parkrunstats.servehttp.com

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for parkrunstats.servehttp.com
Using the webroot path /website/parkrun for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. parkrunstats.servehttp.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to parkrunstats.servehttp.com.well-known

IMPORTANT NOTES:

• The following errors were reported by the server:

  Domain: parkrunstats.servehttp.com
  Type: connection
  Detail: Could not connect to parkrunstats.servehttp.com.well-known

  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.

My operating system is (include version): Centos 6.8

My web server is (include version): apache 2.4.23

My hosting provider, if applicable, is: N/A

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

I am able to succesfully run dry-run renewals for my other domains (such as https://iplookup.flagfox.net) hosted on the same server but not this one.
Have also tried to renew using --apache rather than --webroot with the following results:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for parkrunstats.servehttp.com
No vhost exists with servername or alias of: parkrunstats.servehttp.com (or it’s in a file with multiple vhosts, which Certbot can’t parse yet). No vhost was selected. Please specify ServerName or ServerAlias in the Apache config, or split vhosts into separate files.
Falling back to default vhost *:443…
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. parkrunstats.servehttp.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 687ed6a200f554da43e9bc91c87e10ca.2722a25735d11f4ad9511240853f2ac5.acme.invalid from 77.98.120.113:443. Received certificate containing ‘’

IMPORTANT NOTES:

• The following errors were reported by the server:

  Domain: parkrunstats.servehttp.com
  Type: unauthorized
  Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
  Requested
  687ed6a200f554da43e9bc91c87e10ca.2722a25735d11f4ad9511240853f2ac5.acme.invalid
  from 77.98.120.113:443. Received certificate containing ‘’

The site is publically accessible, the DNS is correct, no load balancers or similar.
Also, directory /website/parkrun/.well-known created succesfully. And /website/parkrun is definitely the correct webroot directory.

Thanks for any help!

[serverco]

can you create a text file in /website/parkrun/.well-known/acme-challenge/test
with the contents “success” and then check reaching it in the browser ?

[rleeden]

Done. And I can sucessfully see - https://parkrunstats.servehttp.com/.well-known/acme-challenge/test

[serverco]

It works for me as well - so that eliminates the most common error. re-reading all your info above to see what else it could be.

[pfg]

The HTTP version of your site is serving a broken redirect - note the value for the Location header:

curl -v http://parkrunstats.servehttp.com/.well-known/acme-challenge/test
*   Trying 77.98.120.113...
* Connected to parkrunstats.servehttp.com (77.98.120.113) port 80 (#0)
> GET /.well-known/acme-challenge/test HTTP/1.1
> Host: parkrunstats.servehttp.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Sun, 30 Oct 2016 16:29:46 GMT
< Server: Apache
< Strict-Transport-Security: max-age=15768000
< Location: https://parkrunstats.servehttp.com.well-known/acme-challenge/test

Seems you’re missing a slash somewhere in your config.

[rleeden]

Great - yes that was it. Ran another test and all OK, and I can see a connection coming in from outbound1.letsencrypt.org now.

Thanks for your quick response.

[rleeden]

After thinking about this for a while I was a little puzzled by this, but I think I understand what was going on, so just updating this post in case anybody else has this issue.

So the mistake I’d make was that my Apache redirect was:

Redirect permanent / https://parkrunstats.servehttp.com

Whereas it should have had a trailing slash - i.e.

Redirect permanent / https://parkrunstats.servehttp.com/

What puzzled me was why did accessing the test file that was created earlier in this thread work in the browser, but not when using curl. The answer is because I’m using HTTP Strict Transport Security (HSTS).
So I’d visited the homepage of my site for which the redirect still works fine (as the missing trailing slash is not relavant for the homepage), and then because of HSTS my browser will note that this site should alway use HTTPS in future. So next time I visit the site it won’t use the redirect as it already knows to use HTTPS. So when accessing the test file it didn’t use the misconfigured redirect as the browser went straight to using https. Whereas curl and other such tools that I guess the letsencrypt processes use don’t use HSTS.