toddgardner

Yikes, not a good look when everyone needs to be automating certificate renewal.

OP Here.

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.

If you never want this to happen again to your systems, we’re building a tool that bakes monitoring and validation into automatic cert renewals.

<https://www.certkit.io/>

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

For all the folks worried about how hard automation is going to be, this is what my team and I have been working on for the past year:

https://www.certkit.io/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.

It's not really a stupid problem, its the BygoneSSL problem: https://www.certkit.io/blog/bygonessl-and-the-certificate-th...

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:

We're doing a beta of it for some other groups now. https://www.certkit.io/

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

I wrote a bunch about this recently: https://www.certkit.io/blog/47-day-certificate-ultimatum

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

Does anyone read articles before commenting? lol

Yea totally. this is a balance.

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.

I tend to sell to a wide variety of customers. They tend not to give a crap if a cloud provider is down, its still our problem to make it right.

Yea agreed. I don't build my own CDNs.

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.

wow, yea. that's foolish. Fixing.

How you approach this is very different depending on the size of organization. We're a small shop (3), but we deliver big services to lots of people.

We do this by owning everything we can, and using simple vendors for what we can't.

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.

Hey Hackernews! Todd the author here. Thanks for reading and sharing.

We (request metrics, author) are also using clickhouse. But we go beyond analytics to integrate performance, security, api monitoring, and errors under a single interface. We think of it as “client side observability”.

Request Metrics, obviously!

https://requestmetrics.com

Put Request Metrics on your list to credit the post :)

Author here.

Clearly Request Metrics should make it on your list ;)

Request Metrics is not an advertiser, does not track individuals, and complies with the EFF dnt policy. Ad block lists are way too aggressive--all it takes is some random person to put you on the list and it's hard to get off of it.

We wrote this in response to a HN request in our previous audit of Google Search: https://news.ycombinator.com/item?id=24482344

3.3kb async loaded JavaScript actually. But the irony is not lost.

:D Thanks Billy!!

4-6 second total page load time. This includes the document, static assets, and JavaScript parsing.

Based on many data points from our monitoring of website performance, this is a very common range.

It's real sad that the title of this was changed from "How the hell is Google so Fast?"