Why I still have an old-school cert on my https site

Why I still have an old-school cert on my https site

People sometimes ask me why I don't use Let's Encrypt, and it's a long story. It has a lot to do with just how damn evil the protocol is. It looks like it was created by people who had been drinking FAR too much of the web kool-aid, since it's chock full of terrible things. It should be a small amount of drama to start a process, receive a magic string, sock it away somewhere at a magic path, then poke the validator and say "go for it". Then you just check back and see whether it worked or not.

Actually doing this with the ACME stuff is terrifying. I first looked at this several years ago, and not only was the protocol bad, but the implementations I checked out were also miserable. One of them had line widths in excess of 200 characters. Many puppies paid the price when that was created, and the fact that nobody else cares just boggles the mind.

But, I kept reading. This thing winds up running openssl (as in, the CLI toolset in /usr/bin or whatever) and then grovels around in the output with regexes. Then it turns it into a jwk, and this is where the "web kool-aid" thing shows up. It's part of the protocol, so it's not like they had any choice, but it's just one more awful thing you now have to worry about supporting.

But somehow this gets turned into JSON, and then that gets a SHA-256 hash, and then the base64 encoding of that turns into a thumbprint? So it's a SHA of a text representation of something that can be reordered or reformatted, and this is supposed to be useful?

Then it runs openssl again to read the CSR, and so on and so forth.

Anyway, that's about where I got to it after first encountering it in 2018, and then after reconsidering it in 2020 when I found myself with a bunch of extra time on my hands due to the lockdown.

But what about now? This isn't about Let's Encrypt. This is about me finding a supposed alternative and going through the same process of due diligence to understand just what I'd be getting into. Somehow, a couple of weeks ago, I found this other site which claimed to be better than LE and which used relatively simple HTTP requests without a bunch of funny data types.

I went through all of their API docs. You call an endpoint and tell it which domain or domains you want, and feed in the CSR. You also tell it how many days it should last: 3 or 12 months, more or less. Once you do this, it tells you what to do in order to perform verification. They do the usual techniques: put this magic blob in DNS, put a magic blob in your document root somewhere, or confirm that you can receive e-mail at a certain address.

Your end goes and sets this up, then calls back and says "okay, I'm ready, go look". This starts the process rolling, and assuming it all checks out, in theory you'll get a certificate issues pretty soon after that point.

Sounds great, right? I thought so, and created an account at this point to take a whack at it. That's when I saw it started asking questions about what kind of account did I want. Did I want a free account, or to pay this much, or that much, or this other even bigger amount? What? They didn't mention this before.

This is when the fine print finally appeared. This service only lets you mint 90 day certificates on the free tier. Also, you can only do three of them. Then you're done. 270 days for one domain or 3 domains for 90 days, and then you're screwed. Isn't that great?

Oh, and finally? You can't do the less-insane API on the free tier. Yep. You have to pay up for that. Gotcha, sucker!

I immediately deleted my account and marked the experience as one worthy of warning others.

At least now I can point at this post when people ask why I'm still using an old-school certificate on my site. It's deliberate.