Live data from Hacker News

Why I no longer have an old-school cert on my HTTPS site

rachelbythebay.com

131–140 of 437 posts

Re: Why I no longer have an old-school cert on my HTTPS site

#131
OpenBSD has a dead-simple lightweight ACME client (written in C) as part of the base OS. No need to roll your own. I understand it was created because existing alternatives ARE bloatware and against their Unixy philosophy.

Perhaps the author wasn't looking hard enough. It could probably be ported with little effort.

Re: Why I no longer have an old-school cert on my HTTPS site

#132
post #12
post #9

I don't understand the tone of aggression against ACME and their plethora of clients. I know it isn't a skill issue because of who the author is. So I can only imagine it is some sort of personal opinion that they dislike ACME as a concept or the tooling around ACME in general. We've been using LE for a while (since 2019 I think) for handful of sites, and the best nonsense client _for us_ was https://github.com/do-kn…

Some people don't want to be forced to run a bunch of stuff they don't understand on the server, and I agree with them. Sadly, security is a cat and mouse game, which means it's always evolving and you're forced to keep up - and it's inherent by the nature of the field, so we can't really blame anyone (unlike, say, being forced to integrate with the latest Google services to be allowed on the Play Store). At least yo…

Non-ACME certs are basically over. The writing has been on the wall for a long time. I understand people being squeamish about it; we fear change. But I think it's a hopeful thing: the Web PKI is evolving. This is what that looks like: you can't evolve and retain everyone's prior workflows, and that has been a pathology across basically all Internet security standards work for decades.

Re: Why I no longer have an old-school cert on my HTTPS site

#133

If you want to actually implement an ACME client from first principles, reading the RFC (plus related RFCs for JOSE etc) is probably easier than you think. I did exactly that when I made a client for myself. I also wrote up a digested description of the issuance flow here: https://www.arnavion.dev/blog/2019-06-01-how-does-acme-v2-wo... It's not a replacement for reading the RFCs, but it presents the information in th…

[flagged]

Re: Why I no longer have an old-school cert on my HTTPS site

#134
post #61

> So, yes, instead of saying that "e" equals "65537", you're saying that "e" equals "AQAB". Aren't you glad you did those extra steps? Oh JSON. For those unfamiliar with the reason here, it’s that JSON parsers cannot be relied upon to treat numbers properly. Is 4723476276172647362476274672164762476438 a valid JSON number? Yes, of course it is. What will a JSON parser due with it? Silently truncate it to a 64-bit or 6…

Go can decode numbers losslessly as strings: https://pkg.go.dev/encoding/json#Number

json.Number is (almost) my “favorite” arbitrary decimal: https://github.com/ncruces/decimal?tab=readme-ov-file#decima...

I'm half joking, but I'm not sure why S-expressions would be better here. There are LISPs that don't do arbitrary precision math.

Re: Why I no longer have an old-school cert on my HTTPS site

#135
post #42

I am running an HTTP-only blog and it's getting harder every year not to switch to HTTPS. For instance, Whatsapp can not open HTTP links anymore.

For god's sake, however complex ACME might be it's better than not supporting TLS

There's no good reason to serve a blog over TLS. You're not handling sensitive data, so unencrypted is just fine.

Re: Why I no longer have an old-school cert on my HTTPS site

#136
post #127

Earlier quoted context omitted.

Fortunately that’s only needed if you’re using the DNS validation method — necessary if you’re getting wildcards (but…eek, wildcards). For HTTP-01, no DNS changes are needed unless you want to add CAA records to block out other CAs.

Wildcard Certificates are your friend if you don't want all of your hostnames becoming public knowledge.

Having tried it myself, I can highly recommend a security posture that doesn't depend on the secrecy of any particular URL :)

Re: Why I no longer have an old-school cert on my HTTPS site

#137
post #50

Things change over time. Part of not wanting to let go is the sunk cost fallacy. Part of it is being suspicious of being (more) dependent on someone else (than you are already dependent on a different someone else). (As an aside, the n-gate guy who ranted against HTTPS in general and thought static content should just be HTTP also thought like that. Unfortunately, as I'm at a sketchy cafe using their wifi, his page c…

> thought static content should just be HTTP Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM. The only way it could possibly work is if the static content were signed somehow, but then you need another protocol the browser and you need a way to exchange keys securely, for example like signed RPMs. It would be less expensive as the encryption happens once, but…

> Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM.

Rather, it's that most people simply don't need to care about MITM. It's not a relevant attack for most content that can be reasonably served over HTTP. The goal isn't to eliminate every security threat possible, it's to eliminate the ones that are actually a problem for your use case.

Re: Why I no longer have an old-school cert on my HTTPS site

#138
post #52

Not the main point of the article, but the author’s comments on Gandi made me wonder: What registrar do people recommend in 2025?

Pork bun is my favorite.

I've been on Namecheap for years but I'm ready to move just because they refuse to support dynamic AAAA records. How's Porkbun on that front?

Re: Why I no longer have an old-school cert on my HTTPS site

#139
post #61

> So, yes, instead of saying that "e" equals "65537", you're saying that "e" equals "AQAB". Aren't you glad you did those extra steps? Oh JSON. For those unfamiliar with the reason here, it’s that JSON parsers cannot be relied upon to treat numbers properly. Is 4723476276172647362476274672164762476438 a valid JSON number? Yes, of course it is. What will a JSON parser due with it? Silently truncate it to a 64-bit or 6…

But what's wrong with sending the number as a string? `"65537"` instead of `"AQAB"`

Re: Why I no longer have an old-school cert on my HTTPS site

#140

I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu. My favourite client is probably https://github.com/acmesh-official/acme.sh If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should h…

Dunno about the protocol, but man, working with certbot and getting it do what I wanted was ... well, a lot more work than I would have guessed. The hooks system was so much trouble that I ended up writing my own.

But yeah, can definitely recommend DNS-01 over HTTP-01, since it doesn't involve implicitly messing with your server settings, and makes it much easier to have a single locked server with all the ACME secrets, and then distribute the certs to the open-to-the-internet web servers.

Post reply on HN