Live data from Hacker News

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

rachelbythebay.com

341–350 of 437 posts

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

#341
post #269

Earlier quoted context omitted.

But the requirements you listed aren't actually requirements of ACME, they're lazy choices you could make but they aren't necessary. Some clients do better. For example the client needs a Certificate Signing Request, one way to achieve that is to either have the client choose the private keys or give it access to a chosen key, but the whole point of a CSR is that you don't need the private key, the CSR can be made by…

I don't know that it's accurate, but at the beginning, it felt like using certbot was the only supported way to use ACME/LE, and it really wanted to do stuff as root and restart your webserver whenever. Or you could run Caddy which had a built in ACME client, but then you're running an extra daemon. apache_mod_md eventually came along which works for me, but it's also got some lazy things (it mostly just manages requ…

> I don't know that it's accurate, but at the beginning, it felt like using certbot was the only supported way to use ACME/LE, and it really wanted to do stuff as root and restart your webserver whenever.

It's fair to say that on day one the only launch client was Certbot, although on that day it wasn't called "Certbot" yet so if that's the name you remember it wasn't the only one. Given that it's not guaranteed this will be a success (like the American Revolution, or the Harry Potter books it seems obvious in hindsight but that's too late) it's understandable that they didn't spend lots of money developing a variety of clients and libraries you might want.

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

#343

Earlier quoted context omitted.

Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. I don't really buy this explanation. It's a very large unsigned number. Everyone knows this. Is there some arbitrary precision library in use that forces large integers to be signed? Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the…

> Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. This is probably a bug (where an unsigned integer with its high bit set is not printed with a leading 00) and should be reported. Note that RSA key moduli generated by OpenSSL will always have the high bit set, and so will always have 00 prepended when you ask it to print them. The same is not necessarily true of other integer…

> moduli generated by OpenSSL will always have the high bit set

Correct for 1024, but...

    openssl genrsa 1023 | openssl rsa -text -noout
:)

Also just noticed that openssl rsa actually has a -modulus switch so you can make do with "cut -b9-"

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

#344
post #343

Earlier quoted context omitted.

> Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. This is probably a bug (where an unsigned integer with its high bit set is not printed with a leading 00) and should be reported. Note that RSA key moduli generated by OpenSSL will always have the high bit set, and so will always have 00 prepended when you ask it to print them. The same is not necessarily true of other integer…

> moduli generated by OpenSSL will always have the high bit set Correct for 1024, but... openssl genrsa 1023 | openssl rsa -text -noout :) Also just noticed that openssl rsa actually has a -modulus switch so you can make do with "cut -b9-"

Ah, yeah, should have clarified that for any 8n-bit moduli it will be set.

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

#345
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…

As you said - it’s not really a problem with the JSON structure and format itself, but the underlying parser, which is specifically designed to map to the initial js types. There are parsers that don’t have this problem, but then the JSON itself is not portable. The problem with your solution is that it’s also not portable for the same reason (it’s not part of the standard), and the reason that it wasn’t done that wa…

Isn't the actual problem that it is supposed to map to JS types, which are badly designed, and thus being infectious for other ecosystems, that don't have these defects?

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

#346
post #199

Earlier quoted context omitted.

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

This is the same author that threw everyone into a panic about atop and turned out to not really have found anything.

Agreed and -- in particular -- I don't recall seeing any kind of "everybody get back into the pool" follow-up after the developers of atop quickly addressed the issue with an update. At least not any kind of follow-up that got the same kind of press as the initial alarm.

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

#347
post #214
post #207

Earlier quoted context omitted.

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.

Google's CA offers them for free via ACME https://pki.goog/

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

#348
post #249

Earlier quoted context omitted.

> I feel like not understanding why JSON won out is being intentionally obtuse. I didn’t feel like my comment was the right place to shill for an alternative, but rather to complain about JSON. But since you raise it. > JSON can easily be hand written, edited, and read for most data. So can canonical S-expressions! > Canonical S-expressions are not as easy to read and much harder to write by hand; having to prefix ev…

Your example uses s-expressions, not canonical s-expressions. Canonical s expressions[1] is basically a binary format. Each atom/string is prefixed by a decimal length of the string and a colon. It's advantage over regular s expressions is that there is no need to escape or quote strings with whitespace, and there is only a single possible representation for a given data structure. The disadvantage is it is much hard…

> Your example uses s-expressions, not canonical s-expressions.

I’ve always used ‘canonical S-expressions’ to refer to Rivest’s S-expressions proposal: https://www.ietf.org/archive/id/draft-rivest-sexp-13.html, a proposal which has canonical, basic transport & advanced transport representations which are all equivalent to one another (i.e., every advanced transport representation has a single canonical representation). I don’t know where I first saw it, but perhaps it was intended to distinguish from other S-expressions such as Lisp’s or Scheme’s?

Maybe I should refer to them as ‘Rivest S-expressions’ or ‘SPKI S-expressions’ instead.

> S-expressions don't have any way to encode type information in the data itself, you need a schema to know if a certain value should be treated as a number or a string.

Neither does JSON, as this whole thread indicates. This applies to other data types, too: while a Rivest expression could be

    (date [iso8601]2025-05-24T12:37:21Z)
JSON is stuck with:

    {
      "date": "2025-05-24T12:37:21Z"
    }
> And it's subjective which is more readable.

I really disagree. The whole reason YAML exists is to make JSON more readable. Within limits, the more data one can have in a screenful of text, the better. JSON is so terribly verbose if pretty-printed that it takes up screens and screens of text to represent a small amount of data — and when not pretty-printed, it is close to trying to read a memory trace.

Edit: updated link to the January 2025 proposal.

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

#349

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.

Came here to mention this.

Man page: https://man.openbsd.org/man1/acme-client.1

Source: https://github.com/openbsd/src/tree/master/usr.sbin/acme-cli...

Post reply on HN