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.