Renewal failed due to dns problem

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: derm-in.pl

I ran this command:

It produced this output:

My web server is (include version): Apache 2.4.29

The operating system my web server runs on is (include version): Ubuntu Server 16.04 LTS

My hosting provider, if applicable, is: OVH

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): ISPConfig3 3.1.11

I still observe the letsencrypt.log file and I see what happens but I don’t understand why it happens. I see:
2018-03-15 03:00:40,090:INFO:letsencrypt.reporter:Reporting to user: The following errors were reported by the server:

Domain: derm-in.pl
Type: unauthorized
Detail: Invalid response from http://derm-in.pl/.well-known/acme-challenge/51qNNlFpM-uw88txxVh5W9BuyO32jr_YtA4J6oBWL1s: "

<title>Derm-In</title>
<link rel=""

Domain: www.derm-in.pl
Type: unauthorized
Detail: Invalid response from http://www.derm-in.pl/.well-known/acme-challenge/sLohkfeUI7F5EDHxCPOsKC86aTRi2WtXlCjpS2AtIXE: "

Derm-In <link rel=""

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.

2018-03-15 03:00:40,091:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/derm-in.pl.conf produced an unexpected error: Failed authorization procedure. derm-in.pl (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://derm-in.pl/.well-known/acme-challenge/51qNNlFpM-uw88txxVh5W9BuyO32jr_YtA4J6oBWL1s: "

<title>Derm-In</title>
<link rel="", www.derm-in.pl (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.derm-in.pl/.well-known/acme-challenge$
<title>Derm-In</title>
<link rel="". Skipping.

2018-03-15 03:00:40,095:DEBUG:letsencrypt.cli:Traceback was:
Traceback (most recent call last):
File “/usr/lib/python2.7/dist-packages/letsencrypt/cli.py”, line 1017, in renew
obtain_cert(lineage_config, plugins, renewal_candidate)
File “/usr/lib/python2.7/dist-packages/letsencrypt/cli.py”, line 706, in obtain_cert
_, action = _auth_from_domains(le_client, config, domains, lineage)
File “/usr/lib/python2.7/dist-packages/letsencrypt/cli.py”, line 457, in _auth_from_domains
new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
File “/usr/lib/python2.7/dist-packages/letsencrypt/client.py”, line 252, in obtain_certificate
return self.obtain_certificate_from_csr(domains, csr) + (key, csr)
File “/usr/lib/python2.7/dist-packages/letsencrypt/client.py”, line 225, in obtain_certificate_from_csr
authzr = self.auth_handler.get_authorizations(domains)
File “/usr/lib/python2.7/dist-packages/letsencrypt/auth_handler.py”, line 84, in get_authorizations
self._respond(cont_resp, dv_resp, best_effort)
File “/usr/lib/python2.7/dist-packages/letsencrypt/auth_handler.py”, line 142, in _respond
self._poll_challenges(chall_update, best_effort)
File “/usr/lib/python2.7/dist-packages/letsencrypt/auth_handler.py”, line 204, in _poll_challenges
raise errors.FailedChallenges(all_failed_achalls)

It’s real domain. DNS works - check intodns, mxtoolbox and points to some ip. I am helpless. Moreover it’s not the problem for each from maybe 20 websites but only few (and these few sites get this same error as above).

X-Powered-By: Express

Your site is powered by a Node.js application.

Can you describe how the site is setup? Can you show us the full Apache VirtualHost for this domain (i.e. including the ProxyPass directives).

If you are proxying to a backend Node.js application, you will most likely need further Apache configuration to route the /.well-known/acme-challenge path to a webroot location for use by Certbot.

Yes but as new user I can't upload files so I have to use some file hosting. I can't put whole vhost here, because I got message that body is similar to earlier posted. Here is the link:
https://nofile.io/f/1Sb2ObrKF7P/dermin.txt

Apache vhost creates basic setup for website and included ProxyPass proxy to specific port on which works node server. Site is deployed under ISPConfig3 and uses /var/www/derm-in.pl/web as root directory for files. All work without any htaccess redirections. Important thing - Let'sEncrypt is provided automatically by click two checkboxes - LE SSL and SSL - in website settings in ISP panel. I did ls -la in /var/www/derm-in.pl/ and here is not /.well-known/acme-challenge path. This same in /var/www/derm-in.pl/web which is root directory. This path is under:
/usr/local/ispconfig/interface/acme/.well-known/acme-challenge

Could you tell me more about this configuration?

The web root that you should be using would be defined in this file:

It could be something as simple as adding to the top of your VirtualHost (so that it takes priority over your ProxyPass):

Alias /.well-known/acme-challenge /usr/local/ispconfig/interface/acme/.well-known/acme-challenge
ProxyPassMatch ^/\.well-known !

(adjusting for whatever the renewal conf file says the webroot is).

1 Like

In /etc/letsencrypt/renewal/derm-in.pl.conf I have line:
webroot_path = /usr/local/ispconfig/interface/acme
So in this case alias should looks like you wrote above, yes?

Yes, see how you go with the ProxyPassMatch negation (remember to escape the regex as above).

I am quite beginner in this topic. If you say that this alias is good I am going to use it. :wink: But unfortunatelly I am not able to check it is working. The closest ssl cert for website will expire 18-19 April 2018. :wink:

You can create a test file and try to access it:

echo -n "Testing Alias and ProxyPassMatch" > /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/test

Now try to reach that file with your browser:

http://derm-in.pl/.well-known/acme-challenge/test

or using command line:

curl -ikL http://derm-in.pl/.well-known/acme-challenge/test

If you get the text "Testing Alias and ProxyPassMatch" it is working fine :wink:

Once done remove the test file:

rm /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/test

Cheers,
sahsanu

2 Likes

Thank you guys. I am going to check it now. :wink:

PS
It is working. I see in browser text “Testing Alias and ProxyPassMatch”. I hope it will help with renewal certs for node.js applications.

1 Like

Great, then you shouldn't have any problem to renew the certs :wink:

I hope it will be end of this big problem. I have almost 20 websites. Much of them are node app which are proxying from apache vhost and of course they use LE certs. :wink:

PS
I am going to share your help with other ppl on other forums where I put my problem and nobody could help. :wink: Node is growing, so probably more and more ppl is going to use it to build apps.

1 Like

One more thing. I have one vhost file and inside are two <VirtualHost *:80> <VirtualHost *:443>. Inside both or only 443 should I put mentioned earlier Alias?

The safest way is to put it wherever you have your ProxyPass directives, but in theory it should only be necessary on port 80.

I notice that the http://derm-in.pl/.well-known/acme-challenge/test is no longer working (it’s sending it to the Node backend again).

Did you remove the config, or did perhaps your control panel overwrite it?

I removed it after test which finished with success. I put Alias line to each *:80 and *:443 VirtualHost. I saw in my first post, where I put the log that there is line:
Detail: Invalid response from http://derm-in.pl/.well-known/acme-challenge/51qNNlFpM-uw88txxVh5W9BuyO32jr_YtA4J6oBWL1s: "
So I suppose it should be in *:80 but site use https so I also put Alias line to *:443.

The Alias line may not be the important one. I’m not sure how ISPConfig works, but it might already inherit that directive from an external context.

The ProxyPassMatch negation line is probably the more significant one to remember to include because it stops your ProxyPass from overriding absolutely everything.

Of course I included both lines - Alias and ProxyPassMatch - at the top of each VirtualHost tag. :slight_smile:
I hope it will do it’s job. :wink:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.