Tried generating a certificate, fails with the following error:
srv:~# certbot --server https://acme-staging-v02.api.letsencrypt.org/directory run --preferred-challenges http-01 --requ
ired-profile shortlived --preferred-profile shortlived -d 2a01:799:15d1:8400::402 -v
Requested name 2a01:799:15d1:8400::402 is an IP address. The Let's Encrypt certificate authority will not issue certificates for a bare IP address.
srv:~# certbot --version
certbot 4.1.1
How did you manage to provision it?
Welcome @xstasy I moved your post into its own thread.
It looks like Certbot does not yet support using IP addresses in its -d option
I haven't seen the EFF's plan to support IP addresses. You might try asking on their github: GitHub - certbot/certbot: Certbot is EFF's tool to obtain certs from Let's Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.
You might try using the ACME client lego
There already is an issue open: [Feature Request]: IP address subjectAlternativeName certificates · Issue #10346 · certbot/certbot · GitHub
So, I followed your recommendation and tried the following in lego:
lego --http --server https://acme-staging-v02.api.letsencrypt.org/directory -m x@gbps.io -a -d 2a01:799:15d1:8400::402 run --profile shortlived
Resulting in a urn:ietf:params:acme:error:badCSR :: Error finalizing order :: CSR contains IP address in Common Name
Do you know the correct way to proceed?
Looks like a lot of startup pain for IP addresses. There's a good reason this is only in Staging 
A little bit of a "chicken and egg" problem as ACME Client authors have only recently been able to test with LE for IP addresses.
Let's Encrypt is not allowing an IP address in the CSR's CN. It isn't needed because for both the shortlived and tlsserver profiles there is no CN in the issued certificate.
LE should probably ignore the CSR CN for this but that does not seem imminent. See: IP SAN error: "CSR contains IP address in Common Name" - #8 by mcpherrinm
A reasonable solution is for the ACME Client to always omit the CN for LE's shortlived and tlsserver profiles. And, removing the CN from the CSR for all LE profiles is not a bad option.
You should probably post a link to this thread on the lego github: GitHub · Where software is built It generally supports IP addresses so hopefully the fix for LE is not difficult.
I'm not sure what other ACME client to recommend. @JamesLE what ACME Client did you use to get the IP address cert here: Getting ready to issue IP address certificates
With your report I now know that dehydrated, lego, and uacme suffer the same problem with CN in the CSR for IP certs. And, Certbot does not yet support it at all.
As an aside, I use a custom ACME client but it fails because of an LE bug for IP addresses using the tls-alpn challenge 
Sure I could redo my infra to use HTTP Challenge but it was only a test anyway.
Most of Let's Encrypt's testing was done with Lego, but we provided a domain name in addition to an IP (and put the domain first, so that's what was in the CSR's CN).
Our recommendation is that clients don't populate a CN in the CSR unless explicitly requested, but I know that's going to be a big change for some clients.
Quick question to avoid making a new thread, has that TLS ALPN fix landed in staging yet? Was just trying it and wasn't sure if I was hitting the bug or something else on my end.
Please file a feature request (or bug report) with lego as they shouldn't use a commonName to begin with as that has been deprecated for a long time now. But especially for IP addresses they shouldn't add one or at least provide the option to remove the CN from the CSR, seeing that LE refuses to issue certs with an IP address in the CN.
You can check https://acme-staging-v02.api.letsencrypt.org/build for yourself and see if the relevant commit from Commits · letsencrypt/boulder · GitHub is in the past of the commit from the build info.
TIL of that URL, thanks!
Wanted you to see lego has a fix out. Available now or wait for formal release