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

201–210 of 437 posts

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

#201

Post by eadmund »

cortesoft wrote: post #192
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…

> Canonical S-expressions would have been far preferable, but for whatever reason the world didn’t go that way. I feel like not understanding why JSON won out is being intentionally obtuse. JSON can easily be hand written, edited, and read for most data. Canonical S-expressions are not as easy to read and much harder to write by hand; having to prefix every atom with a length makes is very tedious to write by hand. I…

> 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 every atom with a length makes is very tedious to write by hand.

Which is why the advanced representation exists. I contend that this:

    (urn:ietf:params:acme:error:malformed
     (detail "Some of the identifiers requested were rejected")
     (subproblems ((urn:ietf:params:acme:error:malformed
                    (detail "Invalid underscore in DNS name \"_example.org\"")
                    (identifier (dns _example.org)))
                   (urn:ietf:params:acme:error:rejectedIdentifier
                    (detail "This CA will not issue for \"example.net\"")
                    (identifier (dns example.net))))))
is far easier to read than this (the first JSON in RFC 8555):

    {
        "type": "urn:ietf:params:acme:error:malformed",
        "detail": "Some of the identifiers requested were rejected",
        "subproblems": [
            {
                "type": "urn:ietf:params:acme:error:malformed",
                "detail": "Invalid underscore in DNS name \"_example.org\"",
                "identifier": {
                    "type": "dns",
                    "value": "_example.org"
                }
            },
            {
                "type": "urn:ietf:params:acme:error:rejectedIdentifier",
                "detail": "This CA will not issue for \"example.net\"",
                "identifier": {
                    "type": "dns",
                    "value": "example.net"
                }
            }
        ]
    }
> for an Canonical S-expression, you have to count how many characters you are typing/deleting, and then update the prefix.

As you can see, no you do not.

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

#202

Post by AStonesThrow »

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 has more CSE/SWE experience+talent in her little pinky finger than 80% of HN commenters

https://medium.com/wogrammer/rachel-kroll-7944eeb8c692

So I'd say that her position and experience command enough respect that we cannot judge her merely by peeking at a few trifling journal entries.

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

#203

Post by cryptonector »

mcpherrinm wrote: post #189

I’m the technical lead for the Let’s Encrypt SRE/infra team. So I spend a lot of time thinking about this. The salt here is deserved! JSON Web Signatures are a gnarly format, and the ACME API is pretty enthusiastic about being RESTful. It’s not what I’d design. I think a lot of that came via the IETF wanting to use other IETF standards, and a dash of design-by-committee. A few libraries (for JWS, JSON and HTTP) go a…

> JSON Web Signatures are a gnarly format

They are??

As someone who wallows in ASN.1, Kerberos, and PKI, I don't find JWS so "gnarly". Even if you're open-coding a JSON Web Signature it will be easier than to open-code S/MIME, CMS, Kerberos, etc. Can you explain what is so gnarly about JWS?

Mind you, there are problems with JWT. Mainly that HTTP user-agents don't know how to fetch the darned things because there is not standard for how to find out how to fetch the darned things, when you should honor a request for them, etc.

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

#204

Post by johannes1234321 »

ipdashc wrote: post #167
tptacek wrote: post #132

Earlier quoted context omitted.

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.

ACME is cool (compared to what came before it), but I'm kind of sad that EV certs never seemed to pan out at all. I feel like they're a neat concept, and had the potential to mitigate a lot of scams or phishing websites in an ideal world. (That said, discriminating between "big companies" and "everyone else who can't afford it" would definitely have some obvious downsides.) Does anyone know why they never took off?

> Does anyone know why they never took off?

Browser vendors at some point claimed it confused users and removed the highlight (I think the same browser vendors who try to remove the "confusing" URL bar ...)

Aside from that EV certificates are slow to issue and phishers got similar enough EV certs making the whole thing moot.

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

#205

Post by upofadown »

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?

I recently had to bail on Gandi. I had a special requirement, being Canadian, in that I didn't want to use a registrar in the USA. I found a Canadian registrar that seemed to have the technical stuff reasonably worked out (many don't) and had easy to understand pricing:

https://grape.ca/

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

#206

Post by [deleted] »

dwedge wrote: post #195
mcpherrinm wrote: post #189

I’m the technical lead for the Let’s Encrypt SRE/infra team. So I spend a lot of time thinking about this. The salt here is deserved! JSON Web Signatures are a gnarly format, and the ACME API is pretty enthusiastic about being RESTful. It’s not what I’d design. I think a lot of that came via the IETF wanting to use other IETF standards, and a dash of design-by-committee. A few libraries (for JWS, JSON and HTTP) go a…

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?

[deleted]

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

#207

Post by belorn »

dwedge wrote: post #195
mcpherrinm wrote: post #189

I’m the technical lead for the Let’s Encrypt SRE/infra team. So I spend a lot of time thinking about this. The salt here is deserved! JSON Web Signatures are a gnarly format, and the ACME API is pretty enthusiastic about being RESTful. It’s not what I’d design. I think a lot of that came via the IETF wanting to use other IETF standards, and a dash of design-by-committee. A few libraries (for JWS, JSON and HTTP) go a…

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

She don't mention what this "other site" is.

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

#208

Post by anishathalye »

jazzyjackson wrote: post #191
anishathalye wrote: post #165

Earlier quoted context omitted.

Implementing an ACME client is part of the final lab assignment for MIT’s security class: https://css.csail.mit.edu/6.858/2023/labs/lab5.html

Looks like a good class; is it only available to enrolled students? videos seem to be behind a log-in wall.

Looks like the 2023 lectures weren't uploaded to YouTube, but the lectures from earlier iterations of the class, including 2022, are available publicly. For example, see the YouTube links on https://css.csail.mit.edu/6.858/2022/

(6.858 is the old name of the class, it was renamed to 6.5660 recently.)

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

#209

Post by fireflash38 »

mr_toad wrote: post #144
wolf550e wrote: post #101

Implementing an ACME client in python using pyca/cryptography (or in Go) would be fine, but why do it in C++ ?

Not everyone wants to deal with maintaining Python and untold dependencies on their web server. A C++ binary often has no additional dependencies, and even if it does they’ll be dealt with by the OS package manager.

Docker/podman?

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

#210

Post by eximius »

eadmund wrote: post #201
cortesoft wrote: post #192

Earlier quoted context omitted.

> Canonical S-expressions would have been far preferable, but for whatever reason the world didn’t go that way. I feel like not understanding why JSON won out is being intentionally obtuse. JSON can easily be hand written, edited, and read for most data. Canonical S-expressions are not as easy to read and much harder to write by hand; having to prefix every atom with a length makes is very tedious to write by hand. I…

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

For you, perhaps. For me, the former is denser, but crossing into a "too dense" region. The JSON has indentation which is easy on my poor brain. Also, it's nice to differentiate between lists and objects.

But, I mean, they're basically isomorphic with like 2 things exchanges ({} and [] instead of (); implicit vs explicit keys/types).

Post reply on HN