> The point is that if you used a 1kb random password for service to service auth and someone tried to sell you a $400/mo service to generate them, you’d laugh in their face and then have security escort them from the building.
Go ahead, run an internal secret store that issues properly trustworthy internal certificates. It isn’t hard, but neither is it cheap not. You oversimplify and gloss over a few _really_ important aspects of why and how certificates work. A certificate _acting like a password_ in some cases doesn’t mean it actually _is_ a password, and if you don’t really need the additional functionality to the point where the cost outweighs the delivered value, you are using the wrong tool for the job.
Running a CA is not at a technical challenge. Running a _trustworthy_ (there is that word again) CA is process heavy and it involves quite a few people doing work on a regular basis, and without those processes you may as well just something else - like an untrusted CA, or some kind of token issuing service (which, shockingly, also costs money to run properly).
A few really good options around DIY CAs were mentioned in this discussion, smallstep is pretty good for example. Nothing (except possibly your $org’s security policies) prevents you from throwing that up somewhere and start vending certs.
The fact that it is an internal CA to be used for internal purposes makes no difference, unless you believe that “everything internal is trusted because it is internal” in which case many other discussions on a very wide variety of subjects is due.
Internal here means I don’t need the certificates trusted by a third party.
Having built many Enterprise PKI systems — including Smart Card auth — I do know the complexity involved. I can prattle on for hours about how the Key Recovery Agents should be distributed and stored, and how “offline” means no network cables at all you dimwit.
I also know that there is virtually no difference between a root CA certificate and a signed leaf certificate.
They’re both just files.
The difference is the amount of ceremony.
DigiCert’s Root CA certificate files had a lot of ceremony — with good reason.
But the CA for “I need five devs in India to get VPN certs with a common root” is practically zero.
No, it does not take a “a lot of infrastructure” to host a 1kb file. It really doesn’t, and your persistent confusion is my point: you are simply unable to let go of your preconceptions.
Just last week I needed a pair of certs with a common root for a load balancer’s back end. Not for transmitting NSA secrets over intercontinental backhaul.
I already have access to a bone-fide HSM! For pennies!
Why can’t I be allowed to use that pre-engineered secure certificate storage system for its intended purpose!?
Go ahead, run an internal secret store that issues properly trustworthy internal certificates. It isn’t hard, but neither is it cheap not. You oversimplify and gloss over a few _really_ important aspects of why and how certificates work. A certificate _acting like a password_ in some cases doesn’t mean it actually _is_ a password, and if you don’t really need the additional functionality to the point where the cost outweighs the delivered value, you are using the wrong tool for the job.
Running a CA is not at a technical challenge. Running a _trustworthy_ (there is that word again) CA is process heavy and it involves quite a few people doing work on a regular basis, and without those processes you may as well just something else - like an untrusted CA, or some kind of token issuing service (which, shockingly, also costs money to run properly).
A few really good options around DIY CAs were mentioned in this discussion, smallstep is pretty good for example. Nothing (except possibly your $org’s security policies) prevents you from throwing that up somewhere and start vending certs.
The fact that it is an internal CA to be used for internal purposes makes no difference, unless you believe that “everything internal is trusted because it is internal” in which case many other discussions on a very wide variety of subjects is due.