To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
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?
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.
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.
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
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.
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
chris@cns-itpro:/etc/letsencrypt$
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.
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.
