Cert challenge fails

Ubuntu Server 16.04


Using Dynu.com for Dynamic DNS

sudo certbot --apache

http-01 challenge for cns-itpro.dynu.com
http-01 challenge for www.cns-itpro.dynu.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. cns-itpro.dynu.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://cns-itpro.dynu.com/.well-known/acme-challenge/~challenge key~: "



since there are no certs found for cns-itpro.dynu.com nor www.cns-itpro.dynu.com, I will assume this is a new request and not a renewal.
both names resolve to just one IPv4 address - this is good (and simple)
http://cns-itpro.dynu.com/ forwards successfully to http://cns-itpro.dynu.com/login
http://www.cns-itpro.dynu.com/ fails while forwarding to http://www.cns-itpro.dynu.com/login (404 error)

please provide:
certbot --version
DocumentRoot location(s) for vhost file(s) that cover both names.
any special redirection or rewrite sections [within the vhost file(s) or globally]
any special handling for /.well-known/acme-challenge/ requests (if used)

“please provide:”
“certbot --version” Should be the most current version. I installed it two days ago..
“DocumentRoot location(s) for vhost file(s) that cover both names” /var/www/html/
“any special redirection or rewrite sections [within the vhost file(s) or globally]” No
“any special handling for /.well-known/acme-challenge/ requests (if used)” No

One thing I did not mention is that the Host has an Private IP and traffic on port 80 and 443 are forwarded to from the Public WAN IP. Would that cause this issue?


Chris Hobgood

Could you maybe post your complete Apache configuration somewhere? When using --apache, Certbot attempts to modify your configuration in order to satisfy the challenge (including adding new handling for /.well-known/acme-challenge paths—this is a different approach from the behavior of certbot --webroot, which uses your existing document root), and it looks like it maybe didn't succeed in this case.

Here you are. Thanks for your help.


Mutex file:${APACHE_LOCK_DIR} default


Timeout 300

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 5


HostnameLookups Off

ErrorLog ${APACHE_LOG_DIR}/error.log

LogLevel warn

IncludeOptional mods-enabled/.load
IncludeOptional mods-enabled/

Include ports.conf

Options FollowSymLinks AllowOverride None Require all denied

<Directory /usr/share>
AllowOverride None
Require all granted

<Directory /var/www/>
Options FollowSymLinks
AllowOverride None
Require all granted

AccessFileName .htaccess

<FilesMatch “^.ht”>
Require all denied

LogFormat “%v:%p %h %l %u %t “%r” %>s %O “%{Referer}i” “%{User-Agent}i”” vhost_combined
LogFormat “%h %l %u %t “%r” %>s %O “%{Referer}i” “%{User-Agent}i”” combined
LogFormat “%h %l %u %t “%r” %>s %O” common
LogFormat “%{Referer}i -> %U” referer
LogFormat “%{User-agent}i” agent

IncludeOptional conf-enabled/*.conf

IncludeOptional sites-enabled/*.conf

Servername cns-itpro.dynu.com

The Apache2.conf file contains a ServerName directive but shows no redirection.
There must be other files…
That cover the “www” name and do the redirection.
Maybe you could show those files along with actually typing
“sudo certbot --version”
and showing the output.

certbot version 0.22.2

The only other file I can think of would be the vhost file.

<VirtualHost *:80>
ServerAdmin chrishobgood@cns-itpro.com
DocumentRoot /var/www/html/
ServerName cns-itpro.dynu.com
ServerAlias www.cns-itpro.dynu.com

 <Directory /var/www/html>

 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined

<VirtualHost *:80>
ServerAdmin chrishobgood@cns-itpro.com
DocumentRoot /var/www/html/invoiceninja/ninja/public
ServerName ininja.cns-itpro.dynu.com
ServerAlias www.ininja.cns-itpro.dynu.com

 <Directory /var/www/html/invoiceninja/ninja/public>
    Options +FollowSymlinks
    AllowOverride All
    Require all granted

 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined

Thanks! Could you please also post the log from /var/log/letsencrypt associated with the failed attempt to obtain a certificate?

Try adding a test.txt file in the challenge folders:

would use: /var/www/html/.well-known/acme-challenge/
mkdir /var/www/html/.well-known/
mkdir /var/www/html/.well-known/acme-challenge/
echo "just a test" > /var/www/html/.well-known/acme-challenge/test.txt
and should be reacheable via: http://cns-itpro.dynu.com/.well-known/acme-challenge/test.txt

would use: /var/www/html/invoiceninja/ninja/public/.well-known/acme-challenge/
mkdir /var/www/html/invoiceninja/ninja/public/.well-known/
mkdir /var/www/html/invoiceninja/ninja/public/.well-known/acme-challenge/
echo "just another test" > /var/www/html/invoiceninja/ninja/public/.well-known/acme-challenge/test.txt
and should be accessible via: http://ininja.cns-itpro.dynu.com/.well-known/acme-challenge/test.txt

Sorry, I’m new here so I could not post the log (too long) or attach it.

Yes those tests worked…

I got rid of the www. server aliases in the hosts files it seemed to have corrected the first error. but then I got an error suggesting too many certs had been issued for my domain. So I guess the problem was with the aliases. I was under the impression that the Certbot would add all the necessary info to the host files for SSL/TLS to work. Also I saw pem files were created in the /var/letsencrypt/keys/ folder… I read that the current certs would be in /var/letsencrypt/live/. That folder did not exist… I don’t know enough about this to know what’s supposed to be where.

I don’t see how removing the WWW alias could correct a problem…
Maybe you corrected it with some other change.
I would try adding it back in and also adding it to the certificate request.

DYNU.COM is not on the PSL and is rate limited.
If possible, try switching to a domain that is on the list.
See: https://www.dynu.com/ControlPanel/AddDDNS

You might be thinking of /etc/letsencrypt/live rather than /var?

You are correct. but…

chris@cns-itpro:/etc/letsencrypt$ cd live
-bash: cd: live: No such file or directory
chris@cns-itpro:/etc/letsencrypt$ ls
accounts cli.ini csr keys options-ssl-apache.conf renewal renewal-hooks

I not exactly sure what rate limited means. How does that affect me?
When I set my account up with DYNU.com the dynu.com domain was available.

Did you have certificates that you obtained successfully before or have you never yet created any certificate successfully?

Let's Encrypt normally only issues 20 new certificates per week for subdomains of a given Internet domain name. For shared free domains this can be a big problem because users are then competing with other users for some of those 20 slots. (For more complicated reasons, they're also sometimes competing with users who are renewing pre-existing certificates too.) In this case the ability to issue certificates for one of these public domains can be a matter of luck, or of running software like lectl in order to figure out the exact moment when a certificate issuance is likely to go through.

We'd like to see public domain operators list their domains on the Public Suffix List, which @rg305 mentioned. When they do this, we have software that relatively automatically grants a rate limit exemption for the domains in question, because their operators have confirmed that the domains are used by the general public, not just by a single person or organization. It seems that Dynu has not done this with dynu.com. I don't know why not, but that does mean that the competition with other users for the limited number of certificate issuances for dynu.com subdomains is still active.

No this is is the first time I have tried to get a certificate. I do own the domain cns-itpro.com hosted by GoDaddy and the DNS records are on their servers. I don’t have a static IP. That’s why I went with dynu.com. I have been wondering if I can use my domain with their updating service, but I have not looked into that. My worry is it will cause conflicts since the main records are on GoDaddy’s DNS servers. There are no A records there currently though… Using my own domain would probably clear this issue up I’m guessing…

Also, thanks for the rate limiting info. Very helpful…

So, the nonexistence of /etc/letsencrypt/live and so on is a consequence of not having obtained a certificate. The other PEM files are just results of the previous unsuccessful attempts.

Among other possibilities, you could create a CNAME record at GoDaddy like cns-itpro.com IN CNAME cns-itpro.dynu.com and www.cns-itpro.com IN CNAME www.cns-itpro.dynu.com. You can then get certificates for the cns-itpro.com without making further changes to your DNS setup.

1 Like

Yeah, It would have to be an A record which would require an IP address. I already have CNAME records associated with my Office 365 account so that won’t work.