It's probably due to the fact that Certbot is quite Let's Encrypt orientated, even while it's not developed by Let's Encrypt for a long time now.
The developers probably included the behaviour of the Let's Encrypt ACME server into their documentation, whilst not mentioning it as such.
We can ask @certbot-devs about their opinion in this thread here and whether they think it's worth opening an GH issue for or not.
I'm interested to see if you're able to get the older iOS working with a Buypass cert with a common name. You can use patch -p3 <add-cn-to-csr-v1.12.0.patch.txt in the correct directory where crypto_util.py of the acme Python package resides (or lower -p values if you're more "up" in the directory tree I guess). In the correct Python version directory too of course 
(Not sure if other OS can also easily have multiple Python versions next to each other, but I have 3 to 4 versions installed at a time 
)
I agree, that is a great idea and I would be interested to know myself! I am not confident, however, to apply the patch and recompile in reasonable time. Do you still have the domain name/cert that you used above to confirm Bypass supports Common Name in the Subject field? If you can share the URL with me, I will be happy to test on my older iPhone.
Python is an interpred language, no recompiling required.
Right, I just thought certbot is still made into some kind of package and/or binary, knowing the executable lives in /usr/bin/certbot. But I can see now it's actually a text file. Looking into this further.
You can run locate acme/crypto_util.py to check which location(s) contain(s) the file to patch. Use the -b option on patch to backup the original crypto_util.py.
I'm not sure whether Certbot should/shouldn't.
It seems like the decision to not include a CN was taken a long time ago, long before alternative ACME servers were a thing. At the time, there was little consequence to following the best practice of omitting a Subject CN in the CSR, because Let's Encrypt would include one on the certificate anyway.
Looking over old issues, it seems like a number of users have complained about empty Subjects with BuyPass, Digicert, Venafi and Smallstep ACME servers, and with macOS compatibility.
It feels bad to undo a best practice, but I'd be open to doing something about this, if there's a pressing need for it. That said, I think iOS 9 is too far old to warrant a change like this.
@mcpherrinm what would your advice to clients be? If Let's Encrypt still intends to eventually stop forcing a CN onto certificates once compatibility is good enough, my intuition is that it would be wise to have a client-side flag to control what appears on the CSR. I am not up to speed on what incompatibilities Subject CN-less certificates would cause.
IIRC, I believe this decision was made as part of the switch to ACME-V2.
Here are two later threads from the Pebble repo from people who ran into issues with this. There are some comments from Boulder devs on both:
I think the documentation of the client should resemble the actions taken by the client. While it might make sense back in the day, currently the documented behaviour does not correspond with the actual behaviour of Certbot in the case of Buypass. So I'd say the documentation needs to be modified/clarified if the choice is made to keep not including a CN. For me either is fine
The first phase will probably be omitting the CN when none of the SANs are short enough to fit in the size limit, which is a strict improvement over failing to issue certs, but is still potentially troublesome if those certs don't universally work. It definitely seems like a change that's perilous, as this thread shows.
I think it probably makes sense to have a flag / pair of flags to control whether certbot includes a CN, but that's firmly into making dangerous compatibility hazards for all but the most sophisticated users with a deep understanding of the x509 ecosystem.
Alright, I can confirm having a Subject CN does make a difference for iOS 9.3, and Safari does work with a cert having a Subject Common Name!
Here iOS 9 Safari works with a certificate generated after applying your patch:
And it does not work with another certificate I generated after restoring the original crypto_util.py:
I'm on Debian, so the file I patched was /usr/lib/python3/dist-packages/acme, found using find / -name "crypto_util.py". There are two files with this name, go for the one under the acme folder. I had to edit the patch from @Osiris to reflect the different path, basically replaced acme/acme with just acme: add-cn-to-csr-v1.12.0.patch.txt (2.4 KB). Then:
cd /usr/lib/python3/dist-packages/acmepatch -b -p2 < ~/add-cn-to-csr-v1.12.0.patch.txtI agree, the documentation is misleading and only adds to confusion.
While that's an easy way out, there are still people using iOS 9 who didn't upgrade for some reason. We're still having visitors on our site who are on iOS 9 - not a lot, but non-zero. And on a scale of certbot, there could be many more. When Google launched their own CA, they said they specifically support the wide range of all kinds of devices, and by using their CA the webmasters can benefit from that. (I can't find the exact link, here's the closest paraphrase I could find.)
Buypass is the only free ACME CA that ticks all three:
The only thing that's missing is the Subject Common Name coming from Certbot. I think if we could pass a flag asking it to include a CN, that would be enough. I admit however, I do not realise the scale of the change required to implement that and have no idea about all possible consequences that may follow. On the other hand,
… simply because Let's Encrypt already does automatically include the CN anyway – just does it on the server side, this means it's generally safe to automatically include the CN?
Lastly, having been released in 2016, I think it's too early to consider iOS 9 that much ancient and obsolete.
See, I was able to get ultimately helpful answers and also learnt a lot – all in just few hours, is exactly the reason why I posted my non Let's Encrypt related question specifically on this forum
Many thanks guys!
Yes, we always include a CN today. We might not do that forever. The main problem is it makes certs bigger, which adds bandwidth to TLS handshakes. That can matter at a certain scale, but is otherwise usually harmless to include. The main place it causes trouble is if all your names are over the length limit on CNs, which I think is 64 characters.
It is. The market share is less than a fraction of a single digit. The only devices that are capable of running it are iphone 4-6 and a few iPad versions (See iOS version by device — iOS Ref), which have an incredibly low global market share. Running iOS 9 on any compatible device is pretty painful.
Apple aggressively pushes for OS upgrades and has short device support windows. Between that and how quickly users upgrade devices, it's rarely worth supporting an ios version for more than 4 years.
Whatever the decision is with a future --include-subject-common-name flag, it's probably best to remove the Let's Encrypt specific bits from the docs 
.
Yes, I believe that at the time that documentation was written, there was no other ACME CA available in the world.
Luckily there are multiple free ACME CAs out there currently! Outdated documentation as a good thing 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.