Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rachelbythebay.com

Post reply on HN
Print view View original

211–220 of 437 posts

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

#211

Post by cryptonector »

tialaramex wrote: post #176
fanf2 wrote: post #168

Earlier quoted context omitted.

Tedious and pedantic note: You can’t mindlessly compare the bytes of the host name: you have to know that it’s the presentation format of the name, not the DNS wire format; you have to deal with ASCII case insensitivity; you have to guess what to do about trailing dots (because that isn’t specified); you have to deal with wildcards (being careful to note that PKIX wildcard matching is different from DNS wildcard matc…

In practice it's much easier than you seem to have understood The names PKIX writes into dnsName are exactly the same as the hostnames in DNS. They are defined to always be Fully Qualified, and yet not to have a trailing dot, you don't have to like that but it's specified and it's exactly how the web browsers worked already 25+ years ago. You're correct that they're not the on-wire label-by-label DNS structure, but t…

> You don't need to "deal with" case except in the sense that you ignore it, DNS doesn't handle case

The DNS is case-insensitive, though only for ASCII. So you have to compare names case-insensitively (again, for ASCII). It _is_ possible to have DNS servers return non-lowercase names! E.g., way back when sun.com's DNS servers would return Sun.COM if I remember correctly. So you do have to be careful about this, though if you do a case-sensitive, memcmp()-like comparison, 999 times out of 1,000 everything will work, and you won't fail open when it doesn't.

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

#212

Post by teddyh »

JackSlateur wrote: post #188
eadmund wrote: 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…

Is this ok ? Python 3.13.3 (main, May 21 2025, 07:49:52) [GCC 14.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.loads('47234762761726473624762746721647624764380000000000000000000000000000000000000000000') 47234762761726473624762746721647624764380000000000000000000000000000000000000000000

I prefer

  >> import json, decimal
  >> j = "47234762761726473624762746721647624764380000000000000000000000000000000000000000000"
  >> json.loads(j, parse_float=decimal.Decimal, parse_int=decimal.Decimal)
  Decimal('47234762761726473624762746721647624764380000000000000000000000000000000000000000000')
This way you avoid this problem:

  >> import json
  >> j = "0.47234762761726473624762746721647624764380000000000000000000000000000000000000000000"
  >> json.loads(j)
  0.47234762761726473
And instead can get:

  >> import json, decimal
  >> j = "0.47234762761726473624762746721647624764380000000000000000000000000000000000000000000"
  >> json.loads(j, parse_float=decimal.Decimal, parse_int=decimal.Decimal)
  Decimal('0.47234762761726473624762746721647624764380000000000000000000000000000000000000000000')

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

#213

Post by donnachangstein »

tialaramex wrote: post #186
donnachangstein wrote: post #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.

When I last checked this client is a classic example of OpenBSD philosophy not understanding why security is the way it is. This client really wants the easy case where the client lives on the machine which owns the name and is running the web server, and then it uses OpenBSD-specific partitioning so that elements of the client can't easily taint one another if they're defective But, the ACME protocol would allow act…

I said it was dead-simple and you delivered a treatise describing the most complex use case possible. Then maybe it's not for you.

Most software in the OpenBSD base system lacks features on purpose. Their dev team frequently rejects patches and feature requests without compelling reasons to exist. Less features means less places for things to go wrong means less chance of security bugs.

It exists so their simple webserver (also in the base system) has ACME support working out of the box. No third party software to install, no bullshit to configure, everything just works as part of a super compact OS. Which to this day still fits on a single CD-ROM.

Most of all no stupid Rust compiler needed so it works on i386 (Rust cannot self-host on i386 because it's so bloated it runs out of memory, which is why Rust tools are not included in i386).

If your needs exceed this or you adore complexity then feel free to look elsewhere.

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

#214

Post by jchw »

belorn wrote: post #207
dwedge wrote: post #195

Earlier quoted context omitted.

What is she talking about that you have to pay for certs if you want more than 3? Am I about to get a bill for the past 5 years or did she just misunderstand?

to quote the article (or rather, the 2023 article which is the one mentioning the number 3). "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." "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 th…

FWIW, it is ZeroSSL. I want there to be more major ACME providers than just LE, but I'm not sure about ZeroSSL, personally. It seems to have the same parent company as IdenTrust (HID Global Corporation). Probably a step up from Honest Achmed but recently I recall people complaining that their EV code signing certificates were not actually trusted by Windows which is... Interesting.

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

#215

Post by dangus »

lucideer wrote: post #38
1a527dd5 wrote: 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…

> I don't understand the tone of aggression against ACME and their plethora of clients. > ACME idea good, ACME implementation bad. Maybe I'm misreading but it sounds like you're on a similar page to the author. As they said at the top of the article: > Many of the existing clients are also scary code, and I was not about to run any of them on my machines. They haven't earned the right to run with privileges for my pr…

I disagree, the author is overcomplicating and overthinking things.

She doesn't "trust" tooling that basically the entire Internet including major security-conscious organizations are using, essentially letting perfect get in the way of good.

I think if she were a less capable engineer she would just set that shit up using the easiest way possible and forget about it like everyone else, and nothing bad would happen. Download nginx proxy manager, click click click, boom I have a wilcard cert, who cares?

I mean, this is her https site, which seems to just be a blog? What type of risk is she mitigating here?

Essentially the author is so skilled that she's letting perfect get in the way of good.

I haven't thought about certificates for years because it's not worth my time. I don't really care about the tooling, it's not my problem, and it's never caused a security issue. Put your shit behind a load balancer and you don't even need to run any ACME software on your own server.

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

#216

Post by its-summertime »

eadmund wrote: post #194
marcosdumay wrote: post #126

Earlier quoted context omitted.

What I don't understand is why you (and a lot of other people) just expect S-expression parsers to not have the exact same problems.

Because canonical S-expressions don’t have numbers, just atoms (i.e., byte sequences) and lists. It is up to the using code to interpret "34" as the string "34" or the number 34 or the number 13,108 or the number 13,363, which is part of the protocol being used. In most instances, the byte sequence is probably a decimal number. Now, S-expressions as used for programming languages such as Lisp do have numbers, but aga…

"it can do one of 4 things" sounds very much like the pre-existing issue with JSON

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

#217

Post by teddyh »

orion138 wrote: post #47

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

Like I frequently¹ advise²:

Don’t look to large, well-known registrars. I would suggest that you look for local registrars in your area. The TLD registry for your country/area usually has a list of the authorized registrars, so you can simply search that for entities with a local address.

Disclaimer: I work at such a small registrar, but you are probably not in our target market.

1. https://news.ycombinator.com/item?id=32095499>

2. https://news.ycombinator.com/item?id=32507784>

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

#218

Post by dwedge »

AStonesThrow wrote: post #202
dwedge wrote: post #196

I really don't understand why this blog gets so much traction here. Ranting against rss scrapes, FUD about some atop vulnerability that turned out to be nothing, and thinking you have to pay for acme certs and caring about the way it's parsed?

Well, I will perhaps endure flak or downvotes for pointing a few things out, but Rachel: - Is female [TIL the term "wogrammer"] - Works for Facebook [formerly Rackspace and Google] so an undeniably Big MAMAA - Has been blogging prolifically for at least 14 years [let's call it 40 years: she admin'd a BBS at age 12] - Website is custom self-hosted; very old school and accessible; no ads or popup bullshit - Probably ha…

And yet that's exactly what HN does

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

#219

Post by TZubiri »

eadmund wrote: 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…

It feels like malpractice to use json in encryption

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

#220

Post by schoen »

mschuster91 wrote: post #41
jeroenhd wrote: post #11

There's something to be said for implementing stuff like this manually for the experience of having done it yourself, but the author's tone makes it sound like she hates the protocol and all the extra work she needs to do to make the Let's Encrypt setup work. Kind of makes me wonder what kind of stack her website is running on that something like a lightweight ACME library ( https://github.com/jmccl/acme-lw comes to…

> but the author's tone makes it sound like she hates the protocol and all the extra work she needs to do to make the Let's Encrypt setup work. The problem is, SSL is a fucking hot, ossified mess . Many of the noted core issues, especially the weirdnesses around encoding and bitfields, are due to historical baggage of ASN.1/X.509. It's not fun to deal with it, at all... the math alone is bad enough, but the old abstr…

Yes, we actually considered the "have the protocol transmit all of the required math values in a decent form and get an x.509 cert back" version, but some people who were interested in using Let's Encrypt were apparently very keen on being able to use an existing external CSR. So that became mandatory in order not to have two totally separate code paths for X.509-based requests and non-X.509-based requests.

An argument for this is that it makes it theoretically possible for devices that have no knowledge of anything about PKI since the year 2000, and/or no additional programmability, to use Let's Encrypt certs (obtained on their behalf by an external client application). I have, in fact, subsequently gotten something like that to work as a consultant.

Post reply on HN