Paradigm change of a DNS zone

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. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version)

The operating system my web server runs on is (include version): Ubuntu 20.04

My hosting provider, if applicable, is:myself

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):Terminal

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):certbot 0.40.0

Is there a question, or problem, we can help you with?

Needs an update.


It's been a while since I built a web server In DNS zone I have defined two A records, an A record for (IP= and an A record for (IP= I secured the web server with a certificate for -d and -d -- Well, last week, I repurposed zone for a mail server application as follows (three A records): an A record for (new IP= and an A record for (same IP= and an A record for (new IP= A certificate has been generated on the mail server for -d (only). Today the old certificate expires for A record (IP= and for A record (IP= When trying to renew the certificate on the old webserver, the following error messages appear:

$ sudo certbot --apache -d
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
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: connection
    Detail: Fetching
    Timeout during connect (likely firewall problem)

    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.

Also, I'm preeeeeeeetty sure you don't actually own the domain I believe the introduction of the questionnaire is pretty clear.


Oh my dear friend and "copper engraver", please forgive me, an old computer geek (since 1977), that I do not want to announce the domain in plain text. But my cry for help is of a principled nature. I would be very interested in how such a paradigm change (as described) can be realized with the Certbot. I've been admiring and using Let's Encrypt for years and I still don't see through it. Woe, if I do something about a web server or Nextcloud or mail server configuration, then I am no longer able to reset the existing Letsencypt installation and start over. How can I reset an existing Letsencrypt configuration so that I don't have to set up the whole server again?

I'm not sure I follow. Might I suggest using simpler wording? Not all volunteers on this Community are native English speakers and I'm not familiar with anyone here being a poet.

In any case, from your previous post, with "paradigm change" you actually mean: "I've added the mail subdomain to my DNS zone", right?

Also, where does the "set up the whole server again" come from? Your previous post said nothing about removing the old server with """IP address"""

In any case, the error message presented by Certbot is clear: the Let's Encrypt validation server cannot reach the server at the www subdomain because port 80 is not reachable. See my previous post.

Also with regard to not announcing the domain name: as the questionnaire intro already said: all publicly trusted certificates are published to certificate transparancy logs and are in the public domain anyway. And it really hampers our diagnostic capabilities. So I really urge you to reconsider, otherwise we can only tell you generic things like: "you need to have port 80 open in your firewall".


Yes, you are right, perhaps I should use simpler words. - When I decided to place the web server and the mail server in the same zone, I clearly entered the A record "" in the DNS zone first. But somehow the mechanism didn't work with the MX record as well as SPF, DKIM and DMARC. Only when I made the mail server a kind of "master", the mail server propagated and got a score of 9.4 out of 10 points. This change (I call it paradigm change) has probably messed up the certificate installation on the web server (different IP). Yes, you are right, the first attempt to renew the certificate on the web server went wrong because I accidentally forgot to release port 80, but on all further attempts port 80 was open and the error messages got worse and worse. Last but not least, I had to reinstall the WordPress. Of course, I didn't have much joy, as so often. - Sorry, but the domain is "". Sorry, but the domain is "". But I wonder why I always fail at these certificates. As an old computer bunny, I dare to ask if there is not a solution to my problem, because it was always not port 80.

Could you share those outputs?

Also, from my point of view, your webserver doesn't respond on port 80 (you should just keep it open) and I'm not sure what's listening on port 443. It doesn't look like something OpenSSL understands.

Your mailserver on the other hand seems to be working fine on port 465 (SMTPS) and 587 (submission). Note that port 25 seems to be closed.


Do you have an email where I can send a pdf?

Oh, my goodness, I forgot to open port 25. That's probably because of my age! Thank you so much. You have something good with me!
Please note that my websites are all https only. No other ports are open, except when certs renewing.
By the way: The web server is again up and running with a new OS release and a new cert. All OK.

1 Like

Certificates are name based - not IP based.
If/When an IP changes, the cert will continue to function (on the new IP).
[provided that system is still in control of the private key]

I am glad to hear that things are now operational again.
Cheers :beers:


That's not recommended. Please see the documentation I linked in my first post.


By the way: IPs have not changed at all, only their role in the zone file. Before, the role of the zone was dominated by the IP of the webserver, and now, the role of the zone is dominated by the IP of the mailserver due to the propagation of MX, and TXT records. The cert of the webserver expired at the same time, and its renewal was only concentrated of his role as subdomain "" (old IP). The Let's Encrypt system has wondered why the renewal was only at the subdomain "" and not both "" AND "" as it was at its first beginning of of the zone where no mailserver existed at all.

I didn't know a DNS zone could have a role?


If there is a zone with several subdomains, each subdomain with a different IP address, then it plays a role, in the case of a subdomain "mail server", that this zone is dominated by its IP, precisely because of the propagation, because no zone is queried as often as with a mail server (practically every eMail for SPF, DKIM, and DMARC). In my case, this is not possible otherwise.

I don't follow how the uses shown has any actual effect/role within the DNS zone/system.

How one uses an FQDN, or an IP, does not reflect/alter the settings/structure/definitions within DNS.


Theoretically, you may be right, but my DNS provider was not against this change in the A Record table. And I feel better too.
But please do not forget my original concern: If a Cert Renew does not work from the beginning, and this has happened to me in my firewall infrastructure (HAProxy, SNI TLS extension) with six (6) web servers and two (2) Nextcloud servers, then Let's Encrypt has only one thing: set up the server NEW and request the certificate completely new!
Yes, that is the concern that I originally wanted to place with this request as a cry for help. Is there a solution where you could reset an existing certification without reinstalling the server from scratch?
Hopefully regards, Louis

Yes, "fix" whatever problem is preventing the renewal.
Step #1 in that path: "Find the problem" that is preventing the renewal.


You mean, at the age of 69, I should still find a software that has no errors? Yes, then I would have to go back to ETH Zurich again! Yes, why not?

1 Like

I mean that you should look for and find the error.
It hides in plain sight - LOL