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:remote.rickjan.com
I ran this command: Automatic certificate renewal using Certify The Web
It produced this output: Error - cannot find A record for remote.rickjan.com
My web server is (include version):remote.rickjan.com
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know): don't know
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):no
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):
My domain name server is Google Domains and it definitely shows an A record present.
My certificate is expired please can you help me?
Welcome to the community @Blobby
Yes, it has an A record but the IP is a private IP not a public one. Any address starting with 192.168 is private.
That IP never would have worked with Let's Encrypt certs. Did you change it since your last good cert in December?
You can see a fuller description using this test site:
IMO it's rather unfortunate that the Let's Encrypt validation server filters out all private IP addresses from the DNS resolver results. When the list of IP addresses of a hostname is empty due to the filtering, the validation server raises an error about no IP addresses found. Which of course isn't true strictly speaking, but from the point of view of the validation server there are no valid IP addresses.
Also, it can be not immediately obvious if an IPv4 address is "publicly routable" or not.
The most common are
172.16.0.0/12 is a private network as well
100.64.0.0/10 is CGNAT
127.0.0.0/8 is loopback, yes, the whole
203.0.113.0/24 are example networks
... and even more addresses are not publicly routable: Special-use addresses
Thanks for your replies everybody.
Yes I did change the IP address to the private 192.168.0.0 one, but I didn't realise it would have this affect. I will endeavour to change to the private one, but unfortunately it is subject to change from my ISP.
I thought there was a way around this but I can't remember what it is.
You can use DNS-01 validation to obtain certificates for domains running on private IPs.
It's called Dynamic DNS. These are two providers that work fine:
Then you put a CNAME from your subdomain to the subdomain they give you. Just remember that you cannot use a CNAME on
rickjan.com but only on
remote.rickjan.com and all other subdomains including
By the way, I'm working on a proposal to change this to reduce the waste of many of these addresses.
Wow I just saw that you even got patches for some of this accepted into the kernel! This really needs more attention, I couldn't even find mentions of that in major kernel changelog summaries...
Being able to use 300+ million additional IPv4s is huge. IPv6 deployment is still **** and NAT gets worse every year.
To be precise, support for three of the address categories was added in Linux as follows:
unicast 240/4 (since 2.6.25):
Author: Jan Engelhardt <firstname.lastname@example.org>
Date: Mon Jan 21 03:18:08 2008 -0800
unicast 0/8 (since 5.3):
Author: Dave Taht <email@example.com>
Date: Sat Jun 22 10:07:34 2019 -0700
unicast subnet lowest address (since 5.14):
Merge: 77091933e453 6101ca0384e3
Author: David S. Miller <firstname.lastname@example.org>
Date: Mon May 17 13:47:58 2021 -0700
(I wrote the last patch, but David S. Miller merged it.)
Support for other operating systems is a more complicated topic.
Really impressed with the help given here, and the speed of response.
Do they control your DNS zone?
I'm the developer of Certify The Web. In addition to the above:
- http validation requires a public IP and port 80 open (Certify The Web will run a temporary http server to answer the challenge from Let's Encrypt, but this only works of port 80 TCP traffic gets to the machine running Certify).
- DNS validation is best if you don't want to allow public http requests to your domain.
We support Manual DNS validation for testing purposes, you could use that as a quick workaround:
- On the Authorization tab, select "dns-01" as the Challenge Type, then (Update DNS Manually) as the update method.
- Click "Request Certificate" and it will begin the order and pause on the validation step (see the Status tab) - you will be prompted to add/update a
TXT record in your domains DNS called
_acme-challenge with a new value, set that in your Google Domains control panel then wait a minute and then click "Request Certificate" to proceed. Your certificate order should then complete normally.
We also have support for things like acme-dns and Certify DNS (which are both the same type of DNS challenge delegation thing), for an automated solution that doesn't require Google Cloud credentials.
We do have Google Cloud DNS support in Certify The Web (via Posh-ACME) but I've not tried it via Google Domains specifically, just using Google Cloud DNS. Docs for setting up those credentials are here: GCloud - Posh-ACME
THIS is the real issue, not IPv4 IMO. I'm running dual stack since at least 2014. First using a tunnel, later native through my ISP. I really can't take ISPs or hosting providers seriously if they don't offer native IPv6 anno 2022.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.