What you fail to grasp is that there are multiple sizes of IT organizations on this planet. The vast majority of them have less than 10 total admins. For them, they could not build and maintain an internal PKI thats as secure or as reliable as Public PKI.
Expecting them to do so is giving up. They will just use self-signed certs and blindly click through warnings.
Having a real certificate that warns when something is wrong is always better than perfect security. When you've worked at more than 1 kind of organization, you get a broader perspective.
> What you fail to grasp is that there are multiple sizes of IT organizations on this planet. The vast majority of them have less than 10 total admins.
Nah, i grasp that very well because i was part of a three-people team that did manage, across other things, a private CA.
After evaluating a few options we decided to Vault from hashicorp to manage our own CA. We scripted the shit out of it and it worked beautifully for years with little to no maintenance. It was an unicorn company (1+ billion euros valuation) and there were multiple kubernetes clusters, around 120 people in the tech team and a multitude of microservices.
Frankly i think it's you that fail to grasp the reality of operating a private CA in a company that does other things rather than managing private CAs.
If you grasped that, you'd know that for example you cannot use (for example) letsencrypt certificate for client authentication anymore, or mutual tls, and you couldn't do that at all with a wildcard certificate.
With a private CA you can do whatever you need and whatever you want.
If you had worked in a real company doing that you would understand.
> When you've worked at more than 1 kind of organization, you get a broader perspective.
That's just a skeaky and mean way to attack me on a personal level, rather than attacking my point.
frankly your post shows a lot of insecurity and your complete ignorance on the reality of operating a private CA, if I were you I'd stop posting out of pure shame.
Nice rewrite. The SAN support is the right call, a lot of older generators trip on that.
One thing worth knowing if you're using this for internal services: generating the cert is the easy part. Getting the CA cert into the trust stores of everything that needs to trust it is where self-signed deployments usually turn into a maintenance problem, especially across a mix of Linux servers, Windows machines, and Java apps with their own keystores.
I am talking to so many mid-sized IT shops that still have lots of legacy on-prem windows systems or specialty software where Certbot or ACME renewals is hard. This sort of thing gets dismissed as "just use certbot" in threads like these, and its infuriating.
We started building CertKit (https://www.certkit.io/) to centralize ACME for just these sort of things.
Paying for certificates..? Manually copying cert files? Man, this reads like it was 2010 or something. Best of luck, but I don’t know why I wouldn’t just use acme.sh and systemd timers instead of this.
You're developing "certbot, but it's paid and sends private keys around the network instead of generating the csr locally"? Why? Who's the target audience? Platforms that can't run certbot, or any of the infinite amount of other acme clients, most likely won't be able to run your agent as well, so what's the value add vs just running a regular, well-defined (and free!) acme client and just moving the cert over manually?
You CNAME the acme challenge DNS to us, we manage all your certificates for you. We expose an API and agents to push certificates everywhere you need them, and then do real-time monitoring that the correct certificate is running on the webserver. End-to-end auditability.
Man, I agree. The whole thing sucks so much. We started building a centralized way to do this internally last year to get better visibility into renewals and expirations:
Cool but for us, this kind of thing is better solved closer to the edge with automation like Caddy server that does this for us while also being our ingress proxy for all those domains.
I want Apache to do this natively.
I want nginx to do this natively.
I want tomcat to do this natively.
I want express to do this natively.
Every single http server punts on TLS as an afterthought of supply me your private and public key and I’ll do it. Sure there are modules now for those servers for ACME but this process is still old school Web 1.0 deployment logic.
I've built something similar, not as cool as certkit, but using acme.sh i generate a wildcard and then internally my servers can pull the wildcard generates an md5 so i can track if it changes, put the certs where they need to be and restart the services they need that use it. Linux and Windows. It works.
It's more complicated than that. Apple (along with Google and Mozilla) basically held the CA's hostage. They started unilaterally reducing lifetimes. It was happening whether the CAB approved it or not.
The vote was more about whether the CAB would continue to be relevant. "Accept the reality, or browsers aren't even going to show up anymore".
It's interesting that this is pretty much identical to the WHATWG/W3C situation: there is theoretically a standards body, but in practice it's defunct; the browsers announce what they will ship, and the "standards body" can do nothing but meekly comply.
The difference being that there's at least a little bit of popular dissatisfaction with the status quo of browsers unilaterally dictating web standards, whereas no one came to the defense of CAs, since everybody hated them. A useful lesson that you need to do reputation management even if you're running a successful racket, since if people hate you enough they might not stick up for you even if someone comes for you "illegally".
Uber is a morally bankrupt company that built its market position through criminal conduct, but everyone looked the other way because they hated the taxi industry even more.
Thanks for this history, I wasn't aware. It's an interesting point that if this is happening anyways by Apple's fiat, it's in the legacy CAs' interest to even further accelerate the mandatory timeline, so they can pivot to consulting services for their existing customers.
I do still feel that "that blog/publication that had immense cultural impact years ago, that was acquired/put on life support with annual certificate updates, will now be taken offline rather than migrated to a system that can support ACME automations, because the consultants charge more than the ad revenue" will be an unfortunate class of casualty. But that's progress, I suppose.
I think it's more broadly "browsers vs. CAs", I think the balance of power shifted sharply after the Symantec distrusting, and I think very few people on HN would prefer the status quo ante of that power shift if we laid out what it meant.
Today, people are complaining that automation of certificate renewals are annoying (I'm sure they were). Before that, the complaint was that random US companies were simply buying and deploying their own root certificates, issuing certs for arbitrary strangers domains, so their IT teams wouldn't have to update their desktop configurations.
That was an interesting read, thanks! Two questions:
- What is the problem with stale certificates if a domain changes hands? It seems to me that whether they renew the certificate or not, the security situation for the user is still the same, no?
> What is the problem with stale certificates if a domain changes hands?
The previous owners have valid certificates for up to 398 days. If they are a malicious party cable of doing a man-in-the-middle attack, they can present a valid certificate and fully impersonate the owner. For example, when Stripe started, they purchased the domain from another party, who had a valid stripe.com payment certificate for nearly a year. (https://www.certkit.io/blog/bygonessl-and-the-certificate-th...)
> Is CertKit a similar solution to Anchor Relay?
I hadn't heard about anchor relay before, thanks for the link!
CertKit is similar, but broader. Anchor says it sits between your ACME clients and the CA and simplifies the validation steps, which is super useful. But you still have to run ACME clients and have a bunch of automation logic running on your end.
CertKit IS the ACME client. You CNAME the challenge record to us and we do all the communication with the CAs and store/renew/revoke your certificates centrally. Your systems can pull (or be pushed) the certs they need via our API, then we monitor the HTTPS endpoints to make sure the correct cert is running. Its a fully-audited centralized certificate management.
Except this is going the wrong way. We should be discouraging frequent domain ownership changes not making them easier. New owners getting visibility into traffic meant for the old owners is as much if not a bigger problem.
If you want to learn more about Certificate Transparency Logs, how to pull and search them, we just did a 3 part series about how we did this at CertKit:
https://www.certkit.io/blog/searching-ct-logs
