Certificate won't renew

Blobby · March 8, 2022, 3:13pm

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?

Blobby

MikeMcQ · March 8, 2022, 3:23pm

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:

Osiris · March 8, 2022, 4:30pm

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.

9peppe · March 8, 2022, 4:40pm

Also, it can be not immediately obvious if an IPv4 address is "publicly routable" or not.

The most common are 192.168.0.0/16 and 10.0.0.0/8, but...

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 /8
192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are example networks

... and even more addresses are not publicly routable: Special-use addresses

Blobby · March 8, 2022, 6:47pm

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.

Blobby

jvanasco · March 8, 2022, 6:49pm

You can use DNS-01 validation to obtain certificates for domains running on private IPs.

9peppe · March 8, 2022, 6:52pm

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.

schoen · March 8, 2022, 8:49pm

By the way, I'm working on a proposal to change this to reduce the waste of many of these addresses.

Nummer378 · March 8, 2022, 10:29pm

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.

schoen · March 8, 2022, 11:06pm

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.

Blobby · March 9, 2022, 12:07am

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

Blobby

rg305 · March 9, 2022, 1:01am

Do they control your DNS zone?

webprofusion · March 9, 2022, 2:02am

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

Osiris · March 9, 2022, 7:11am

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.

system · April 8, 2022, 7:12am

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