I understand that this is frowned upon and not best practice, but Cisco has left me no choice but to pursue this. We have an ASA that sometimes uses it’s FQDN when prompting users ie. firewall.cisco.com other instances it uses it’s private IP. Because of this we get frequent SSL errors.
Cisco is aware of this but naturally, they don’t really care. Their only suggestion is to somehow get a public cert with the FQDN and the private IP as a SAN. As a Letsencrypt partner i’m pretty surprised this is their official recommendation.
Let’s Encrypt doesn’t offer the ability to have an IP (especially a private one) on a certificate. I know there was future discussion about that option for public IPs, but I think you’ll need to look into creating your own internal CA and going that route here.
As far as I know, it is impossible to get certificate with private IP in SAN from any of the publicly trusted CAs (not only Let’s Encrypt), as CAs are prohibited from doing so by current Baseline Requirements from CA/Browser Forum (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.8.pdf, section 7.1.4.2.1).
@GrizzInt: If you’re able to make your ASA use some public IP owned by you instead of private one, then you may have some luck with requesting certificate with IP SAN from some other CA, but I guess it won’t be quick and cheap.
For example, GlobalSign has such option. I’m not familiar with their process of verifying IP ownership, but they claim that they check information in whois databases - which in some cases may make obtaining certificate impossible (for example if “supernet” is not divided into smaller blocks with individual maintainers).