> 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.