[rsstack]

> I've seen most of them moving to internally signed certs

Isn't this a good default? No network access, no need for a public certificate, no need for a certificate that might be mistakenly trusted by a public (non-malicious) device, no need for a public log for the issued certificate.

[pavon]

Yes, but it is a lot more work to run an internal CA and distribute that CA cert to all the corporate clients. In the past getting a public wildcard cert was the path of least resistance for internal sites - no network access needed, and you aren't leaking much info into the public log. That is changing now, and like you said it is probably a change for the better.

[pkaye]

What about something like step-ca? I got the free version working easily on my home network.

https://smallstep.com/docs/step-ca/

[simiones]

Not everything that's easy to do on a home network is easy to do on a corporate network. The biggest problem with corporate CAs is how to emit new certificates for a new device in a secure way, a problem which simply doesn't exist on a home network where you have one or at most a handful of people needing new certs to be emitted.

[bravetraveler]

> A lot more work

'ipa-client-install' for those so motivated. Certificates are literally one among many things part of your domain services.

If you're at the scale past what IPA/your domain can manage, well, c'est la vie.

[Spivak]

I think you're being generous if you think the average "cloud native" company is joining their servers to a domain at all. They've certainly fallen out of fashion in favor of the servers being dumb and user access being mediated by an outside system.

[bravetraveler]

Why not? The actual clouds do.

I think folks are being facetious wanting more for 'free'. The solutions have been available for literal decades, I was deliberate in my choice.

Not the average, certainly the majority where I've worked. There are at least two well-known Clouds that enroll their hypervisors to a domain. I'll let you guess which.

My point is, the difficulty is chosen... and 'No choice is a choice'. I don't care which, that's not my concern. The domain is one of those external things you can choose. Not just some VC toy. I won't stop you.

The devices are already managed; you've deployed them to your fleet.

No need to be so generous to their feigned incompetence. Want an internal CA? Managing that's the price. Good news: they buy!

Don't complain to me about 'your' choices. Self-selected problem if I've heard one.

Aside from all of this, if your org is being hung up on enrollment... I'm not sure you're ready for key management. Or the other work being a CA actually requires.

Yes, it's more work. Such is life and adding requirements. Trends - again, for decades - show organizations are generally able to manage with something.

Literal Clouds do this, why can't 'you'?

[Spivak]

Adding machines to a domain is far far more common on bare-metal deployments which is why I said "cloud native." Adding a bunch of cloud VMs to a domain is not very common in my experience because they're designed to be ephemeral and thrown away and IPA being stateful isn't about that.

You're managing your machine deployments with something so of course you just use that that to include your cert which isn't particularly hard but there's a long-tail of annoying work when dealing with containers and vms you aren't building yourself like k8s node pools. It can be done but it's usually less effort to just get public certs for everything.

[bravetraveler]

To be honest, with "cloud-init" and the ability for SSSD to send record updates, I could make a worthwhile cloudy deployment

To your point, people don't, but it's a perfectly viable path.

Containers/kubernetes, that's pipeline city, baby!