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.
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.
> 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.
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:
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".
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
Very few times should you manage the actual hardware yourself.
But often a cloud is overly complex for what you need. 10 years ago we left MS Azure and started leasing dedicated hardware in OVH. Our costs were cut by 90%, our performance tripled, and our reliability improved. We did have to take on some effort to make our systems portable with ansible and containers, but we greatly simplified our vendor stack.
I am never confused why something goes down, and I have confidence that I can stand up with another vendor without re-writing anything.
If I can't own it, it should be as simple and commoditized as possible. Most clouds are not that.
But I don't choose cloudflare either, because its too complicated and I don't need that. So I choose the simplest possible thing with as little complexity as possible (for me, that was BunnyCDN). If it goes down, its usually obviously why. And I didn't rely on anything special about it, so I can move away painlessly.
An alternative to multiple providers is to use commoditized providers. By using simple infrastructure rather than cloud platforms, I can redploy my infrastructure using ansible with another provider in hours rather than re-building my platform if I decide the cloud is the wrong fit.
For twenty years, Certificate Authorities ran the perfect protection racket. Then SHA-1 got shattered, Apple went rogue, and certificates went from lasting 3 years to 47 days. This is the story of how browsers broke the CA cartel, and why your manual certificate process is about to become your biggest problem.
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.