Problem with creating a certificate using DDNS CNAME

I'm sorry to use such an old post, but it seems that I still have this error:

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. 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.

I've just installed Let's Encrypt on my server, so I guess a have the last version.

My config:
RPY at home with internet access (no fixed WAN IP)
dynamic DNS with a provider (I've tried several)
sub domain name hosted by another provider, with a CNAME = the DDNS (difficult to change)

If I use only the DDNS instead of my sub domain, no error, certificate saved
If I change the CNAME with an A record with my IP directly, idem: no error, certificate saved.
But I could not have both to access my site.
I've also tried with my Synology with no success (but less info regarding the error)
For the time being, I'm stuck. Any advice please?
(I'm newbie with network, I've started with SSL certificate just a few days)

Hi @hestia,

I've moved your question to a new thread.

For us to help you, it's important to post the full output of the command resulting in that error, including your domain name. Otherwise, we don't have a good starting place to help you figure this out.

1 Like

Thanks for your quick reply!

Here is the full output and the command:

sudo /etc/letsencrypt/letsencrypt-auto certonly --webroot --email -d -w /home/pi/PROD_domoticz/www/

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at You must
agree in order to register with the ACME server at
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: (A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Using the webroot path /home/pi/PROD_domoticz/www for all unmatched domains.
Waiting for verification...
Challenge failed for domain
http-01 challenge for
Cleaning up challenges
Some challenges have failed.

 - The following errors were reported by the server:

   Type:   dns
   Detail: DNS problem: NXDOMAIN looking up A for -
   check that a DNS record exists for this domain
 - 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.

Have you forwarded ports 80 and 443 on your modem-router to your Raspberry Pi?

At the moment, I cannot access your webserver. This means that Let's Encrypt cannot access it either, in order to verify your control of the domain.

If you have forwarded the ports already and double checked it is correct, tt is possible that your ISP ( is blocking the ports. You would need to talk to your ISP in that case.

In the mean time, for me the site is accessible. Also, the previous noted error stated a DNS error: NXDOMAIN. This is also not the case when I dig +trace and dig @${auth_dns} the hostname.

Seems it should work now. If it doesn't work, I presume you'll get a whole different error.


Sorry for the site not accessible.
I did lots of unsuccessful testing and by the end I remove some parts of the configuration.
I've just put it back now.
I'm going to try the certificate again

Yes the result is different now
1: Keep the existing certificate for now
2: Renew & replace the cert (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate

 - Congratulations! Your certificate and chain have been saved at:

But It seems that I still have an A record

I'm going to reboot my Livebox to get another IP and redo the test

Please don't do that without a very good reason if you're not using the staging server. You'll run into rate limits otherwise.

You shouldn't use trial & error with getting a Let's Encrypt certificate to asses the status of your DDNS records. You should check those with tools like dig. Only and ONLY if you have the DNS settings correctly, you can try getting the correct certificate, first using the staging server. And ONLY when the DNS is correct and issuing using the staging server is correct, switch over to the production server.

1 Like

Thanks Osiris for the warning.
I didn't know!
Nevertheless I had performed the 2nd test before you write this.
And it was ok also ; I don't understand why it was KO before ; perhaps it was not the same ddns provider? or perhaps I didn't have opened the 443?
I've found dig and check how it is now.
In fact, I didn't want to go thu this, because on y Synology it's only on click ; I retried on the Syno and it is still the same (Failed to connect to Let’s Encrypt. Please make sure the domain name is valid). But perhaps it should be another topic.
As I've error, I'm going to continue installing the certificate. My other topic is that I've 3 servers and could not the 80 and 443 opened on my router for all of them at the same time.

1 Like

You can not use HTTP authentication for three servers (all behind the same external IP).
The firewall can only route/port forward HTTP to a single internal IP.

But there is a solution to that problem.
It involves using a proxy to use SNI to separate the multiple incoming HTTP traffic and send them to their corresponding server. Note: They must have unique FQDNs (domain names) for SNI to work.
So you can use multiple unique CNAMEs from your real domain or multiple unique DDNS names.
You can use Apache, or NGINX, to proxy all the incoming HTTP (and even HTTPS) requests.

[&2* readers: Get involved; Be heard. It starts with: if you read something you like, then like it :heart:]

1 Like

I'd managed to finish the installation of the certificate.
Many thanks to all of you
Next challenge get a certificate on the Synology and make it the reverse proxy for the others servers

1 Like

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