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.
Why I no longer have an old-school cert on my HTTPS site
151–160 of 437 posts
Re: Why I no longer have an old-school cert on my HTTPS site
#152> 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
#153Earlier quoted context omitted.
> Why? The days of MITM boxes injecting content into HTTP traffic are basically over The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic. (This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without…
How do browsers distrust HTTP, exactly?
This was my experience sending a link to someone who primarily uses an iPad and is non-technical. They were not going to find/open their Macbook to see the link.
Re: Why I no longer have an old-school cert on my HTTPS site
#154Earlier quoted context omitted.
But what's wrong with sending the number as a string? `"65537"` instead of `"AQAB"`
Too likely that this would not work because silent conversion to number along the way
Re: Why I no longer have an old-school cert on my HTTPS site
#155Not the main point of the article, but the author’s comments on Gandi made me wonder: What registrar do people recommend in 2025?
Re: Why I no longer have an old-school cert on my HTTPS site
#156Re: Why I no longer have an old-school cert on my HTTPS site
#157I appreciate the author calling this stuff out. The increasing complexity of the protocols that the web is built on is not a problem for developers who simply need to find a tool or client to use the protocol, but it is a kind of regulatory capture that ensures only established players will be the ones able to meet the spec required to run the internet. I know ACME alone is not insurmountably complex, but it is anoth…
Re: Why I no longer have an old-school cert on my HTTPS site
#158Earlier quoted context omitted.
> 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.
The browser content model knows nothing if the data it's receiving is static or not.
ISPs had already shown time and again they'd inject content into http streams for their own profit. BGP attacks routed traffic off to random places. Simply put the modern web should be zero trust at all.
Re: Why I no longer have an old-school cert on my HTTPS site
#159Earlier quoted context omitted.
So a JSON parser that cannot store a 2 is technically compliant? :(
Yep. Or one that parses it into a 7 :)
if it's known and acceptable that LLMs can hallucinate arguments to an API then i don't see how this isn't perfectly acceptable behavior either.
Re: Why I no longer have an old-school cert on my HTTPS site
#160Earlier quoted context omitted.
> 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…
Well there is the integrity atttribute. https://www.w3schools.com/Tags/att_script_integrity.asp
Maybe you could have a mixed use case page in the browser where you had your secure context, then a sub context of unencrypted protected objects, that could possibly increase caching. With that said, looks like another fun hole browser makers would be chasing every year or so.