Hey all. I figured this might be of interest to other client devs. I've been doing some in-depth testing against the various free ACME CAs and ended up making a page to keep track of the results on the Posh-ACME docs site.
Most of what I cared about was the support for various ACME protocol features beyond the basic cert order/validation flow. But I ended up adding some general info about each CA as well that I'm hoping to expand on to make it more of a complete reference for folks who might care about the differences.
Some interesting things that surprised me during my tests.
Let's Encrypt is the only CA that doesn't support retrying challenge validation.
Of the ones that do, ZeroSSL is the only CA that will attempt to revalidate without being explicitly re-requested by the client. First retry happens after 1 min, then 2, with successively longer. I wasn't patient enough to see if it ever gave up entirely.
BuyPass doesn't seem to support cert revocation using anything but the original ACME account's key.
SSL .com currently has some weird issue that prevents doing anything with an ACME account other than create a new one.
ZeroSSL revocation hasn't worked for me in the past, not sure if it works now.
Each CA has a varying set of supported Key specifications (RSA key sizes or EC curves), e.g. ZeroSSL doesn't support RSA with keysize 4096
I've got them somewhat codified here:
For the ones that use EAB they also vary as to whether they let you re-use the same EAB credentials over multiple registrations (e.g. trying to use the same account on two machines).
ZeroSSL revocation hasn't worked for me in the past, not sure if it works now.
The revocation command didn't throw any error when I tested it and if I tried to re-revoke it, got an error saying it was already revoked. So perhaps they fixed it? But I didn't actually check CRL\OCSP to verify.
The EAB detail and private key support seem like a good things to add as well.
The other thing I forgot to add is SSL.com's weirdness with ACME accounts requiring an email address, but not at creation time.
It's so strange. I've been polling a challenge for over 12 hours now, and it's still status processing. I wonder if the act of polling it 'keeps it alive'? Here are the timestamps of HTTP hits from the ZeroSSL VA, just doubling of the backoff on every attempt:
It sort of makes me wonder what an interactive client is supposed to do with such a long polling timeout. At the moment Certbot just gives up and unhelpfully produces "All authorizations were not finalized by the CA". I guess an interactive client could occasionally ask the user if they want to keep waiting, or give up? Or give up at a fixed time and treat it the same way as a challenge failure, but without the error message? I only recall ever seeing one user getting confused by this, though. .
FWIW, some things that I would be interested in, if I bothered to support other CAs:
Object Re-use.
Boulder will reuse Pending and Valid Authorizations
Boulder will reuse an identical Order that is Pending or Ready
RSA Key Sizes
Boulder only accepts 2048, 3072, or 4096
How to handle the Common Name (Boulder currently wants it blank, with all domains in the SAN; previously domains could be mixed. i have no idea how other CAs handle this)
In CertSage (due to PHP's OpenSSL implementation), I always include a CN in the CSR (even though it's technically obsolete). Am I misunderstanding your comment?
I don't recall which of Boulder or Pebble will complain if example.com is in the CN or not; however it must be in the SAN. IIRC, at least one of the two servers wanted the CN blank. Perhaps it was Pebble being more strict, and I got confused.
I think polling authz status vs challenge status is probably much of a muchness, since in ACME the relationship of challenges->authz is that you need to respond to exactly one challenge (whereas in authzs->order you need to respond to exactly all authzs).
Certify used to poll challenges as well until recently when testing a-CA-who-could-not-be-named it hit an implementation that didn't like post as get on challenge status.
No, I'm only going on a test I did ages ago, revoking the cert then checking their control panel. I'll let someone else investigate further but it's getting off topic for this forum anyway
I typically poll an Authorization instead of a Challenge, for the sole reason of saving an additional followup request to ensure the Authorization is valid. It's theoretically unnecessary, as the Challenge will influence the Authorization, but I like to be extra careful and ensure the Authorization status has been affected.
Ok, you jogged my memory. Under V2 boulder a FQDN can be in the CN, but it must be repeated in the SAN. V1 did not require a repeat, and allowed the SAN to extend the CN.
I guess I leave it blank because one or more test servers I used required it to be blank.
Personally, I wish that the subject alternative names (as an overly fancy way of saying aliases of the subject) would always just be other names of the same subject (and not a twisted mechanism for trying to affiliate a single private key with a bunch of things).
small rant coming not specifically directed at you...
The subject is the subject. The key is not the subject. A certificate is intended to describe a subject, including what key is associated with that subject and what that subject is allowed to do with that key. Just because 100 people use the same building key doesn't mean they're all the same person. Sure, they all fit into the class of people with a key to the building, but the purpose of each person's ID is identifying that person and indicating that they have access to the building.
The moral of this story:
Don't put things in the SAN set that aren't actually aliases of the subject, no matter how tempting it is to optimize by collecting key-users together. It makes the world a whole lot more sane that way.
That's why we get so many confused firebase users here wondering why their certificates have been invaded by foreign entities. It's almost like a chauffeur's license listing everyone who will be driving a certain car rather than listing the individual licensed to drive the car.
An operator's license (identifying an operator or fqdn here) could indicate the operator's (fqdn's) thumbprint.
A vehicle's registration (identifying a vehicle or key here) could indicate the thumbprints of operators allowed to use that vehicle (key).
The operator (fqdn) is the subject of the former.
The vehicle (key) is the subject of the latter.
The trouble in our case is that all of our operators are effectively treated as having the same thumbprint (being the same person).
They're not clones or doppelgangers. They just happen to share a vehicle.
I used to feel that way. Except the Subject was deprecated in favor of everything being in the SAN, so it's pointless. It's a weird abuse of the RFC, which I think stems from the CA/B forum deciding to push in this direction through their rules, and not having to redefine an RFC. The recommendation form LetsEncrypt in the past has been to leave it blank, which is what many clients do - including Certbot do.
If I want control as to how a certificate appears to users, I only issue it for one domain. If multiple domains are involved, I've found it best to just let Boulder decide so tests don't fail, again, when polices change.
.
