Certificate won't renew

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 and, but...

  • is a private network as well
  • is CGNAT
  • is loopback, yes, the whole /8
  •,, and 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 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 www.rickjan.com.


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):                                                                                                                                                                                                                                 
  commit 1e637c74b0f84eaca02b914c0b8c6f67276e9697                                                                                                                                                                                                             
  Author: Jan Engelhardt <jengelh@computergmbh.de>                                                                                                                                                                                                            
  Date:   Mon Jan 21 03:18:08 2008 -0800                                                                                                                                                                                                                      
unicast 0/8 (since 5.3):                                                                                                                                                                                                                                      
  commit 96125bf9985a75db00496dd2bc9249b777d2b19b                                                                                                                                                                                                             
  Author: Dave Taht <dave.taht@gmail.com>                                                                                                                                                                                                                     
  Date:   Sat Jun 22 10:07:34 2019 -0700                                                                                                                                                                                                                      
unicast subnet lowest address (since 5.14):                                                                                                                                                                                                                   
  commit 58fee5fc83658aaacf60246aeab738946a9ba516                                                                                                                                                                                                             
  Merge: 77091933e453 6101ca0384e3                                                                                                                                                                                                                            
  Author: David S. Miller <davem@davemloft.net>                                                                                                                                                                                                               
  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. :slight_smile:


Thanks everyone.
Really impressed with the help given here, and the speed of response.


1 Like

Do they control your DNS zone?

1 Like

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.