Hacker News Reader

Comment by samcat116 | Hacker News Reader

Does this help at all with the issue of deploying the root CA cert on every device that will interact with services with these certs deployed? That seems to me to be the hardest part about running an internal CA. You've got to put it on everyones laptops as well as all your servers.

View on HN

Indeed, we automatically build language (JS, Go, Ruby, Python soon) and OS (debian) packages that you can use in your application or base image. Those packages bundle the set of root CA certs so that your clients trust the certificates presented by servers. Soon we'll have automatic package publishing, so that rotating cert material is just another dependabot PR.

edit: for the laptop problem, we have a CLI toolchain that gets your development environment setup by adding all the necessary CA certs to your local trust store. More about that here: https://blog.anchor.dev/getting-started-with-anchor-for-loca...

Considering the amount of time I’ve spent dealing with trusting CA’s in different environments (and worse, seen people just disable cert verification) I think the real value proposition is probably in the client tooling.

Any org that care enough to have an internal PKI (compared to just using e.g public certs for internal dns names or wildcard certs) probably don’t hosting something internally.

But if the pricing is reasonable and help the client situation enough, then I see it could maybe be worth it?

One thing I'd say on the client side would be an integration with MDM vendors somehow. All the platforms have native hooks to install certs into their trusts that the MDMs use, and corporate IT is already using MDMs. I think that would actually be a lot easier than telling everyone "go download this CLI", especially if a non engineer needs to access these internal services.

Reply on news.ycombinator.com