Canadian IP address starting in automatically rejected even if it's a public IP

I am fully aware that the 192.168.x.x ip range is considered private. However, I have a public IP, and yes you can ping it and head to the nginx landing page to verify, in the 192.18.x.x range. I am assuming that Let's Encrypt refuses to recognize this IP as being valid/public and therefore outputs the error stated below. I have used 'dig' commands to verify that it's returning the right values. My hypothesis seems to be confirmed from the fact this website, that I found while looking through the forum, says my IP is a private IP:

My domain is:

I ran this command (with nginx stopped): certbot certonly --standalone -d --test-cert --verbose

It produced this output: Detail: no valid A records found for; no valid AAAA records found for

My web server is (include version): N/A but the same result is produced under NGINX

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

My hosting provider, if applicable, is: Oracle

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): no, ssh only at the moment

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

3 Likes is actually seen as a reserved (private) network according to the Boulder software used by Let's Encrypt:

The mentioned RFC (RFC 2544 - Benchmarking Methodology for Network Interconnect Devices) says:

The network addresses through are have been
assigned to the BMWG by the IANA for this purpose.

However, that IP range is NOT mentioned in IANA IPv4 Special-Purpose Address Registry at all?

Weird.. And the RFC doesn't seem to be updated by another RFC?

Currently, - is assigned to Oracle according to the whois.. is assigned to some medical research company, - is again assigned to Oracle and is assigned to "Avago Technologies U.S. Inc.".. So it seems it's not so private any more :stuck_out_tongue:

Tagging @lestaff by/for (?) lack of a Boulder-dev specific group :slight_smile:


Oh, dear, I think I see the problem: RFC Errata Report » RFC Editor

I've made a Boulder issue and pull request to fix this:

Unfortunately, we probably will not be able to deploy this fix until next week. Many apologies for the trouble, and thanks for pointing this out.


I am amazed at the quick replies! Thank you so much! Thankfully, in this case waiting a week is probably fine since we are just using the VPS for internal testing and the service will only be made available to users in about a week or two.
You can imagine my confusion and frustration as I try creating a cert over and over, even using AAAA records to see if that would help it get through =P
Once again thank you so much for the help :slight_smile:


Thanks for the quick action @JamesLE !

That should work. But reading your post I sense it didn't?


I only tried that once to be fair, I don't know if the records had the time to propagate. I will try again and keep you updated.


You could also point the name to some other IP
Get the cert at the other server
Point the name back
Copy/Move the cert

Use a manual DNS challenge [one-time issuance]

By the time you need to renew it, the IPv4 will be allowed.


@jsha I think you might also want to update the configuration accordingly, if that's not already on your radar, as lists as well.


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