Certbot fails for IPv4 SSL creation

Help
1

Solved: You'll need to use lego or another tool to issue the IP based SSL, as certbot doesn't have support for IP SSLS yet, instructions for Ubuntu 24 are in my final comment

My domain is: Running this on a public ipv4 address I don't wish to share at this time as its hosting a dev site, I appreciate the understanding.

I ran this command: certbot --server https://acme-staging-v02.api.letsencrypt.org/directory run --preferred-challenges http-01 --required-profile shortlived --preferred-profile shortlived -d 164.92.X.X

It produced this output: Requested name 164.92.X.X is an IP address. The Let's Encrypt certificate authority will not issue certificates for a bare IP address.

My web server is (include version):
Server version: Apache/2.4.58 (Ubuntu)
Server built: 2025-08-11T11:10:09

The operating system my web server runs on is (include version): ubuntu 24

I can login to a root shell on my machine (yes or no, or I don't know): Yes :slight_smile:

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): certbot 2.9.0

I was under the understanding certbot will support an IP using the dev environment. What am I missing?

2

Hi @jamesmcq, welcome. :slight_smile:

The -d requires a domain name, not an IP Address.

Edit

And Getting ready to issue IP address certificates
They are not yet issuing IP Address certificates, only on the staging at this point in time.

Edit 2

Here are Certbot command line options documentation User Guide — Certbot 5.0.0 documentation

2 Likes
3

I think you need a newer version of certbot for IP certs as well. And you might need to specify the shortlived profile too. And that's if they've opened it up to everyone on staging, which I don't remember.

Usually, even (or especially) for dev sites, it's easier to use a real domain name, even if it's only internally accessible, than to try to connect to IPs directly.

3 Likes
4

I would assume then there is some sort of flag for IPs if -d doesnt' work?

This shows that certbot should have support for IP addresses.

1 Like
5

I stand corrected. :slight_smile: For the staging envionment.

I am not seeing it for Certbot in the documentation.
Consider an ACME Client that does support IP Addresses for issuance.

1 Like
6

Where? Because that page does not mention Certbot, an ACME client developed by the EFF and not by Let's Encrypt, anywhere..

As a matter of fact, Certbot currently STILL doesn't support IP addresses.. The active feature request for this can be tracked via [Feature Request]: IP address subjectAlternativeName certificates · Issue #10346 · certbot/certbot · GitHub.

5 Likes
7

You're right. The Let's Encrypt statement of "IP address certificates are available right now in Staging. They should be generally available in Prod later in 2025, at the same time that short-lived certificates become generally available." lead me to believe that it would have been folded into Certbot.

Thank you for the clarification, that is very helpful.

3 Likes
8

There are other ACME Clients that support IP addresses already. You might look at: GitHub - go-acme/lego: Let's Encrypt/ACME client and library written in Go as one example

5 Likes
9

Ideally, yes, but as Let's Encrypt and Certbot/EFF are 2 completely different things, unfortunately this is not the case.

The Certbot team is spread very thin and doesn't have much time (apparently). Hopefully IP address support will be added to Certbot before Let's Encrypt enables it in production, but personally I wouldn't get my hopes up.

I'm still thinking of porting everything I'm currently doing with Certbot over to acmed, an ACME client with IP address support in Rust. It runs as a daemon (as the name suggests), so no cronjobs, no timers et c. Being a daemon it should be able to implement ARI very easily, however unfortunately I don't see any ARI support listed in its features..

4 Likes
10

Too bad. ARI is a must-have feature for ACME Clients these days (as you well know but I mention for benefit of others)

I don't think being a daemon gives material benefit to implementing ARI. Although I agree most cron-based clients don't maintain enough state info to allow them to run very frequently and still be well-behaved in case of errors / outages.

3 Likes
11

If you're coming across this from Google, here is the command you need to run after installing the lego snap to install an SSL on an IP in Ubuntu 24:

Create an ip.cnf with this content to make the csr:

[ req ]
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = v3_req

[ dn ]
O = MyOrg   

[ v3_req ]
subjectAltName = IP:X.X.X.X

Generate the CSR off of the ip.cnf

root@x:~# openssl genrsa -out ip.key 2048
root@x:~# openssl req -new -key ip.key -out ip.csr -config ip.cnf

Put the ip.csr in a space where snap can see it, in this case /var/snap/lego/common/ip.csr, then run the cert request:

lego --server=https://acme-staging-v02.api.letsencrypt.org/directory \
     --email "your@email.tld" \
     --accept-tos \
     --http \
     --csr /var/snap/lego/common/ip.csr \
     run --profile shortlived

You should get the cert back /var/snap/lego/common/.lego/certificates/ . You can make a cert bundle and install from here.

2 Likes
12

Did you try just using the IP address as the value for --domains IPaddr

I admit to not having lego to test with at moment but looking at its code on github it seems like it should work. Saves the trouble of making your own CSR.

5 Likes
13

I confirm that --domains (or -d) accepts an IP address in addition to domain name.

I also needed the --disable-cn option so that the CSR that lego built did not include the IP address in the Common Name field. (*1)

This worked for me

lego --server=https://acme-staging-v02.api.letsencrypt.org/directory \
     --email "your@email.tld" \
     --accept-tos \
     --http \
     --domains 203.0.113.1 \
     --disable-cn \ 
     run --profile shortlived

(*1) The shortlived profile does not set the Common Name in the resulting cert. But, for some reason LE validates the CSR's common name and fails if it is an IP address. The --disable-cn option should be used to suppress the CN in the CSR. See: Certbot cert request fails for IP address in LE Staging - #5 by MikeMcQ

6 Likes
14

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