I feel like this is a case of what can be done and not necessarily what should be done.
To me, effectively deprecating the entire subject component of a leaf certificate is... lazy. We would never do this for intermediate or root certificates (where the subject isn't an fqdn at all, but a made up name).
Never say never.
Oh no!
How would one identify a root/intermediate certificate without its subject? Might as well just throw the certificate away and use only the public key with a sticky note.
I like sticky notes; They hold passwords really well and securely!
For those who are interested:
In the latter, 2 links from jsha:
RFC 2818 from May 2000 deprecates Common Name: RFC 2818 - HTTP Over TLS
Also BRs 1.6.6 section 7.1.4.2.2: Subject Distinguished Name Fields: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.6.pdf
From the Baseline Requirements regarding Common Name:
Required/Optional: Deprecated (Discouraged, but not prohibited)
TLDR; discussing the merits of this decision is pointless and off-topic. The field was officially deprecated from Certificates via both the CA/B Forum and RFC and could be prohibited at any point in the future. The relevant RFCs and current Baseline Requirements state the field is currently optional; with current ACME servers and CAs split in their decision to support it. As a client author, I have n hours per week allocated to handling SSL Certificate concerns. That limited time is better spent ensuring the client is functional and implements the spec correctly, than criticizing upstream decisions or advocating for change.
Can you imagine a driver's license consisting of nothing but aliases? 
That'd be funny as hell.
Yep. Glad you gathered the relevant pieces. Thanks for that. It's very useful for citation later. I often tell people the CN has been deprecated for basically the whole life of the modern internet (to which I usually get blank stares). I agree fully that at day's end, we as developers need to get things to work. Sometimes we can forget the users' expectations/beliefs/understandings in the process though. I find remembering to be one of the most challenging (and occasionally rewarding) aspects of writing auditable code.
May as well post an update: ~8 days later, the challenge is still processing. The maximum backoff seems to be 24 hours. The acme-challenge file is being accessed once per day at the same time.
Fascinating. Do you know when the authz expires? I'd be curious if it just keeps trying daily until that happens.
I have experienced similar weird ZeroSSL retrying behaviour (ACME):
When I issued my first certificate with ZeroSSL via ACME in November 2020, I forgot to add a proper CAA record for Sectigo. This caused issuance to fail initially, with some weird error (something like "issuance failed", no specific error indicating CAA problem).
After going through potential issues, realizing CAA was missing, I corrected the CAA record and created a new order and successfully retrieved a new certificate.
3(!) days later, my automatic CT monitor notified me that (unexpectedly) a new certificate was issued for my domain - by ZeroSSL. Investigation revealed that this looked like the order I created 3 days earlier, retroactively fulfilled now, as the CAA now allowed it - even though the ACME server already reported failure and I abandoned the order. The timestamp ("NotBefore") on the certificate was three days after I originally created the order/DNS validation was performed. (ZeroSSL always sets NotBefore to midnight, so it was initially difficult for me to draw a conclusion between order and cert, given that I already had destroyed the keys and had to inspect backups).
I found that very weird, given that I a) already had made a new order and b) thought the original order had failed ("invalid"), but I might have misread that - apparently it does always retry. Anyway, It felt strange and so I went ahead and revoked the unexpected issuance, just to be sure.
It's curious.
On one hand, the recorded authz expiry is precisely 30 days. On the other, my program's authz (finally) went invalid after ~28.42 days, right after the final polling attempt. No problem/error recorded on the authz.
I suppose that sort of makes sense. It gives up immediately after it knows it won't have time to make another attempt prior to the expiration? The lack of error on the authz is weird though.
I noticed while LE don't care about http-01 challenge reply's content type, buypass.com will reject at least application/octet-stream as if server replied with 503
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.