zlacker

>>fanf2+(OP)
> The Kubernetes DNS resolves A-B-C-D.N.pod.cluster.local to A.B.C.D, as long as A.B.C.D is a valid IP address and N is an existing namespace. Let’s be honest: I don’t know how this serves any purpose, but if you do, please let me know!

You can use that to

- test weird dns setups

- to issue proper TLS certificates (you can do that technically, but it's less known fact and some services like let's encrypt forbid that as their rule)

- to utilize single IP and same port for multiple services (so just a common host/server configuration on typical reverse proxy, optionally with SNI to be used with TLS on top.

>>szszrk+Kx2
I don’t think you can issue proper cert for a private IP. So using dns host name is the only option.

>>vbezhe+3B7
If you control an internal CA you can make certs for anything. I have one for my homelab, and even have a few certs issued for my homelab, which are not for domains i control as well as certs with IPs. The CA is who says you cant do those things, and yes its generally agreed upon for the public internet, certs shouldnt have IPs in them, but if you are operating internally theres nothing stopping you.

>>CableN+zE7
Which software are you using and what is the process !??

>>scienc+YT7
Im just using hashicorp vault, with a multi tier CA setup. Real CA is just a docker container that stays off 99.9% of the time, and the furthest branch intermediate lives on the actual vault instance, which is used to issue certs, among other things. As long as you add your CA chain to your system and browser, they get treated as valid. I even have long term certs in some places because i dont want to change them. Public CAs max at 1 year most of the time now. I issue certs for my internal domains, and public subdomains where im only the one to use it. I use LE for the real public things.