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

Help
#1

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: https://check-your-website.server-daten.de/?q=oracle-0.node.fewermc.tk

My domain is: oracle-0.node.fewermc.tk

I ran this command (with nginx stopped): certbot certonly --standalone -d oracle-0.node.fewermc.tk --test-cert --verbose

It produced this output: Detail: no valid A records found for oracle-0.node.fewermc.tk; no valid AAAA records found for oracle-0.node.fewermc.tk

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
#2

192.18.0.0/15 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 192.18.0.0 through 198.19.255.255 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, 192.18.0.0 - 192.18.194.255 is assigned to Oracle according to the whois.. 192.18.195.0/24 is assigned to some medical research company, 192.18.196.0 - 192.18.255.255 is again assigned to Oracle and 192.19.0.0/16 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:

4 Likes
#3

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.

6 Likes
#4

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:

4 Likes
#5

Thanks for the quick action @JamesLE !

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

2 Likes
#6

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.

2 Likes
#7

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

OR
Use a manual DNS challenge [one-time issuance]

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

3 Likes
#8

@jsha I think you might also want to update the unboundtest.com configuration accordingly, if that's not already on your radar, as https://unboundtest.com/conf lists 192.18.0.0/15 as well.

5 Likes
#9

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