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

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

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

    {
        "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"
                }
            }
        ]
    }

As you can see, no you do not.

Now, S-expressions as used for programming languages such as Lisp do have numbers, but again Lisp has bignums. As for parsers of Lisp S-expressions written in other languages: if they want to comply with the standard, they need to support bignums.

For RSA-4096, the modulus is 4096 bits = 512 bytes in binary, which (for my test key) is 684 characters in base64 or 1233 characters in decimal. So the base64 version is much smaller.

Base64 is also more efficient to deal with. An RSA implementation will typically work with the numbers in binary form, so for the base64 encoding you just need to convert the bytes, which is a simple O(n) transformation. Converting the number between binary and decimal, on the other hand, is O(n^2) if done naively, or O(some complicated expression bigger than n log n) if done optimally.

Besides computational complexity, there's also implementation complexity. Base conversion is an algorithm that you normally don't have to implement as part of an RSA implementation. You might argue that it's not hard to find some library to do base conversion for you. Some programming languages even have built-in bigint types. But you typically want to avoid using general-purpose bigint implementations for cryptography. You want to stick to cryptographic libraries, which typically aim to make all operations constant-time to avoid timing side channels. Indeed, the apparent ease-of-use of decimal would arguably be a bad thing since it would encourage implementors to just use a standard bigint type to carry the values around.

You could argue that the same concern applies to base64, but it should be relatively safe to use a naive implementation of base64, since it's going to be a straightforward linear scan over the bytes with less room for timing side channels (though not none).

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

  >> import json
  >> j = "0.47234762761726473624762746721647624764380000000000000000000000000000000000000000000"
  >> json.loads(j)
  0.47234762761726473

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

That sentence has four negations and I honestly can't figure out what it means.

> This specification allows implementations to set limits on the range and precision of numbers accepted

JSON is a terrible interoperability standard.

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.

There are a number of shell-based ACME clients whose prerequisites are: OpenSSL and cURL. You're probably already relying on OpenSSL and cURL for a bunch of things already.

If you can read shell code you can step through the logic and understand what they're doing. Some of them (e.g., acme.sh) often run as a service user (e.g., default install from FreeBSD ports) so the code runs unprivileged: just add a sudo (or doas) config to allow it to restart Apache/nginx.

It's not just about not understanding, it's that more complex stuff is inherently more prone to security vulnerabilities, however well you think you reviewed its code.

Honest question:

* Do you understand OS syscalls in detail?

* Do you understand how your BIOS initializes your hardware?

* Do you understand how modern filesystems work?

* Do you understand the finer details of HTTP or TCP?

Because... I don't. But I know enough about them that I'm quite convinced each of them is a lot more difficult to understand than ACME. And all of them and a lot more stuff are required if you want to run a web server.

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.

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.

ASN.1 and X509 aren't all that bad. It's a comprehensively documented binary format that's efficient and used everywhere, even if it's hidden away in binary protocols you don't look at every day.

Unlike what most people seem to think, ACME isn't something invented just for Let's Encrypt. Let's Encrypt was certainly the first high-profile CA to implement the protocol, but various CAs (free and paid) have their own ACME servers and have had them for ages now. It's a generic protocol for certificate authorities to securely do domain validation and certificate provisioning that Let's Encrypt implemented first.

The unnecessarily complex parts of the protocol when writing a from-the-ground-up client are complex because ACME didn't reinvent the wheel, and reused existing standard protocols instead. Unfortunately, that means having to deal with JWS, but on the other hand, it means most people don't need to write their own ACME-JWS-replacement-protocol parsers. All the other parts are complex because the problem ACME is solving is actually quite complex.

The author wrote [another post](https://rachelbythebay.com/w/2023/01/03/ssl/) about the time they fell for the lies of a CA that promised an "easier" solution. That solution is pretty much ACME, but with more manual steps (like registering an account, entering domain names).

I personally think that for this (and for many other protocols, to be honest) XML would've been a better fit as its parsers are more resilient against weird data, but these days talking about XML will make people look at you like you're proposing COBOL. Hell, I even exchanging raw, binary ASN.1 messages would probably have gone over pretty well, as you need ASN.1 to generate the CSR and request the certificate anyway. But, people chose "modern" JSON instead, so now we're base64 encoding values that JSON parsers will inevitably fuck up instead.

I see no other reason to serve content over HTTPS.

Must be other good ones? Somewhat prefer something in the UK (but have been using Gandi so its not essential).

Most of it is unused though, only CN, SANs and public key are used.

Some examples of gratuitous complexity:

1. Supporting too many goddamn algorithms. Keeping RSA and HMAC-SHA256 for leagcy-compatible stuff, and Ed25519 for XChaChaPoly1305 for regular use would have been better. Instead we support both RSA with PKCS#1 v1.5 signatures and RSA-PSS with MGF1, as well as ECDH with every possible curve in theory (in practice only 3 NIST Prime curves).

2. Plethora of ways to combine JWE and JWS. You can encrypt-then-sign or sign-then-encrypt. You can even create multiple layers of nesting.

3. Different "typ"s in the header.

4. RSA JWKs can specify the d, p, q, dq, dp and qi values of the RSA private key, even though everything can be derived from "p" and "q" (and the public modulus and exponent "n" and "e").

5. JWE supports almost every combination of key encryption algorithm, content encryption algorithm and compression algorithm. To make things interesting, almost all of the options are insecure to a certain degree, but if you're not an expert you wouldn't know that.

6. Oh, and JWE supports password-based key derivation for encryption.

7. On the other, JWS is smarter. It doesn't need this fancy shmancy password-based key derivation thingamajig! Instead, you can just use HMAC-SHA256 with any key length you want. So if you fancy encrypting your tokens with a cool password like "secret007" and feel like you're a cool guy with sunglasses in a 1990s movie, just go ahead!

This is just some of the things of the top of my head. JOSE is bonkers. It's a monument to misguided overengineering. But the saddest thing about JOSE is that it's still much simpler than the standards which predated it: PKCS#7/CMS, S/MIME and the worst of all - XMLDSig.

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 they are the canonical human readable DNS name, specifically the Punycode encoded name, so [the website] https://xn--j1ay.xn--p1ai/ the Russian registry which most browsers will display with Cyrllic, has its names stored in certificates the same way as it is handled in DNS, as Punycode "xn--j1ay.xn--p1ai". In software I've seen the label-by-label encoding stuff tends to live deep inside DNS-specific code, but the DNS name needed for comparing with a certificate does not do this.

You don't need to "deal with" case except in the sense that you ignore it, DNS doesn't handle case, the dnsName in SANs explicitly doesn't carry this, so just ignore the case bits. Your DNS client will do the case bit wiggling entropy hack, but that's not in code the certificate checking will care about.

You do need to care about wildcards, but we eliminated the last very weird certificate wildcards because they were minted only by a single CA (which argued by their reading they were obeying PKIX) and that CA is no longer in business 'cos it turns out some of the stupid things they were doing even a creative lawyerly reading of specifications couldn't justify. So the only use actually enabled today is replacing one DNS label at the front of the name. Nothing else is used, no suffixes, no mid-label stuff, no multi-label wildcards, no labels other than the first.

Edited to better explain the IDN situation hopefully

Yes, all the popular browsers require this.

> they certainly didn't even as of ~10 years ago?

That's true, ten years ago it was likely that if a browser required this they would see unacceptably high failure rates because CAs were non-compliant and enforcement wasn't good enough. Issuing certs which would fail PKIX was prohibited, but so is speeding and yet people do that every day. CT improved our ability to inspect what was being issued and monitor fixes.

> Yes, it is "required", but CN only has worked for quite some time.

No trusted CA will issue "CN only" for many years now, if you could obtain such a certificate you'd find it won't work in any popular browser either. You can read the Chromium or Mozilla source and there just isn't any code to look in CN, the browser just parses the SANs.

> I find this tricks up some IT admins who are still used to only supplying a CN and don't know what a SAN is.

In most cases this is a sign you're using something crap like openssl's command line to make CSRs, and so you're probably expending a lot of effort filling out values which will be ignored by the CA and yet not offered parameters you did need.

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.

1 - https://docs.astral.sh/uv/guides/scripts/

>I contacted Rachel and she said - and this is my poor paraphrasing from memory - that the IP ban was something she intentionally implemented but I got caught as a false positive

[0] https://news.ycombinator.com/item?id=42599359

If anyone else ran into that it's just a matter of adding

    --server letsencrypt

Then I discovered the web-root approach people mention here and it made a huge difference. Now I have the HTTP snippet in my server set to serve up ACME challenges from a static directory and push everything else to HTTPS, and the ACME client just needs write permission to that directory. I can dynamically include that snippet in all of the sites my server handles and be done.

If I really felt like it, I could even write a wrapper function so the ACME client doesn’t even need restart permissions on the web-server (for me, probably too much to bother with, but for someone like Rachel perhaps worthwhile).

I run it in "webroot" mode on NgINX servers so it's just a matter of including the relevant config file in your HTTP sections (likely before redirecting to HTTPS) so that "/.well-known/acme-challenge/" works correctly. Then when you do run certbot, it can put the challenge file into the webroot and NgINX will automatically serve it. This allows certbot to do its thing without needing to do anything with NgINX.

What would you suggest instead given all these cons?

TCP is just a bunch of bytes... You can't process a bunch of bytes without understanding what they are, and that requires signaling information at a different level (ex - in the bytes themselves as a defined protocol like SSH, SCP, HTTP, etc - or some other pre-shared information between server and client [the worst of protocols - custom bullshit]).