Connection between iOS 9 support and Subject Common Name or X509v3 Subject Alternative Name Critical?

Here are the two certificates I picked randomly from the certificate transparency log. (I have tried some others to confirm the pattern.) One of them has empty Subject Common Name as well as Subject Alternative Name: critical and it does not work on iOS 9.3.5 Safari (does not mean causation though).

(Note: the issuer is Buypass and it was not affected by DST Root CA X3 Expiration.)

Here are the differences I could pick between the two:

Certificate 8354494421 8476758885
Subject commonName = www.fioraioperugia.it (empty)
X509v3 Subject Alternative Name Critical (empty) critical
X509v3 Subject Alternative Name DNS DNS:www.fioraioperugia.it DNS:www.fioraioreggiocalabria.it DNS:www.fioraiorivoli.it DNS:www.fioraiosamassi.it DNS:www.fioraiosavona.it DNS:pianomobil.com DNS:www.pianomobil.com
Address Tested https://www.fioraiosavona.it https://www.pianomobil.com/
Works on iOS 9.3.5 Safari Yes No

The certificate I'm getting for one of my domains name is similar to the latter (8476758885) in that it has empty Subject Common Name, X509v3 Subject Alternative Name is critical, and it does not work on iOS 9.3 Safari. It does work on the new devices though. I use certbot configured to talk to Buypass:

certbot certonly --non-interactive --agree-tos --standalone --http-01-port 8008 --email "username@example.com" -d "example.com"

I am trying to understand what is going on.

The closest I found is this advice to keep an eye on the order of -d arguments, but it does not apply because in the latter cert the CN is completely empty, it's not that the wrong domain had been picked.

Please help me figure this out or let me know if I need to provide more information. Thank you.

1 Like

Both of those certificates are from BuyPass. How is this related to Let's Encrypt?

3 Likes

Additionally, the one on the left is a leaf certificate and the right is a pre-certificate.

4 Likes

What is that cert number?

3 Likes

Certbot doesn't request a Subject Common Name in its Certificate Signing Request. Some CAs (like Let's Encrypt) always provide a certificate with one, but there's no requirement to do so beyond some potential compatibility hazards.

You can try making your own CSR and giving it to certbot with --csr rather than relying on Certbot to do it, or try patching Certbot to include a CN.

4 Likes

Just adding:

  • some CAs will not issue a cert with a Common Name, others will.
  • the Baseline Requirements (for all CAs) require the Common Name to be repeated in the SANs list
  • some clients and CAs will ignore the Common Name and order of SANs in the CSR, and will request/issue a Certificate with no Common Name and an alphabetically sorted SAN listing.

The only expected/required behavior across clients/servers is that a Common Name MUST be repeated in the SAN - as the Baseline Requirements state that. Everything else varies by client/server and will vary across versions so it is not guaranteed and likely to change.

3 Likes

How is this related to Let's Encrypt?

It is and it isn't. It's a different issuer, but the same certbot and ACME. I was hoping with the level of expertise on this forum someone would still recognise the issue.

When going this route, I strongly advice to patch Certbot to include a CN. Not because I like hacking & patching (which I do), but because using --csr with Certbot REEEAAAALLLLLY isn't a very good idea. E.g., no automation and no storage into Certbots own "cert store"..

I'll try to put a simple patch into this thread this evening :slight_smile:

@mehov Which version of Certbot are you using?

3 Likes

I checked on my ios9 device, and you're right.

So I checked the intermedia via OpenSSL:

    Issuer: C = NO, O = Buypass AS-983163327, CN = Buypass Class 2 Root CA
    Validity
        Not Before: May 23 12:57:38 2017 GMT
        Not After : May 23 12:57:38 2027 GMT
    Subject: C = NO, O = Buypass AS-983163327, CN = Buypass Class 2 CA 5

Catch anything there?

iOS 9.3.5 was released in 2016. (WHY DO I KNOW THESE THINGS??? WHY?)

There's a 9.3.6 updated that came out on select hardware in 2019, but I don't think that updated the trust store.

Here is the trust store:

iOS 9.3.5 supports the Root CA in your chain, but not the intermediate.

Your intermediate is "Buypass Class 2 CA 5"; that version of iOS only supports:

  • Buypass Class 2 CA 1
  • Buypass Class 2 Root CA
  • Buypass Class 3 CA 1
  • Buypass Class 3 Root CA

You can work with your vendor to see if you can backport support somehow, otherwise you need to issue a Certificate via another CA that is compatible with your audience.

Edit: I have no idea why one is working, as the fullchains seem to be the same. One may be working due to short-circuit logic and caching, or an alternate chain being sent. Maybe the "critical" bit is affecting how iOS handles intermediates, as it's weird to me that BuyPass has intermediates in the Trust Store.

3 Likes

Thank you for bringing this up! I did a similar test and forgot to include it in my original post.

  1. openssl s_client -connect www.fioraiosavona.it:443 -servername www.fioraiosavona.it -trusted_first
    
Output for www.fioraiosavona.it which works on iOS 9.3.5
CONNECTED(00000003)
depth=2 C = NO, O = Buypass AS-983163327, CN = Buypass Class 2 Root CA
verify return:1
depth=1 C = NO, O = Buypass AS-983163327, CN = Buypass Class 2 CA 5
verify return:1
depth=0 CN = www.fioraioperugia.it
verify return:1
---
Certificate chain
 0 s:/CN=www.fioraioperugia.it
   i:/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 CA 5
 1 s:/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 CA 5
   i:/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGxDCCBKygAwIBAgILBGznQMQfVFN2pOkwDQYJKoZIhvcNAQELBQAwSzELMAkG
A1UEBhMCTk8xHTAbBgNVBAoMFEJ1eXBhc3MgQVMtOTgzMTYzMzI3MR0wGwYDVQQD
DBRCdXlwYXNzIENsYXNzIDIgQ0EgNTAeFw0yMzAxMDIwODU5MThaFw0yMzA2MzAy
MTU5MDBaMCAxHjAcBgNVBAMMFXd3dy5maW9yYWlvcGVydWdpYS5pdDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOSqmprFGIqdDX3Lb6BNZG2FMVBqL4CU
8L1iA0HccR9tReT2sDCafyICYq091RaYBlFO4/AyH/EfFlr8GG8s7IYWqd8yOCQj
1DCKk2eSOrYR7V+KOYT8BcLYVCyvDsQH+liGUjjSoiakYhYdfwFqg5z/HQ3X0vm8
vEK4pJISy/XtcfQt9yhDlYL0UkiqqiR/Dpmq2MDj+IIWYEGBlp8FbWh9UT+6qy/B
vW8QmVXboIbpiASH0fAoWZIkY1YxnyFZtwAt6gzxTktzPPexLxk7tF4T6PYgEUVR
OtaojCcOBAYAujij8VsXNZ/TAKINV8g+Zy/XREqT6jnVAbA/9ywfmHkCAwEAAaOC
AtIwggLOMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUJ1Kkby0qq0CTkOzWacv+fGE7
fEIwHQYDVR0OBBYEFAScwszywPjU/M7TQnnG8HsOLMe6MA4GA1UdDwEB/wQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHwYDVR0gBBgwFjAKBghg
hEIBGgECBzAIBgZngQwBAgEwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2NybC5i
dXlwYXNzLm5vL2NybC9CUENsYXNzMkNBNS5jcmwwgYEGA1UdEQR6MHiCFXd3dy5m
aW9yYWlvcGVydWdpYS5pdIIcd3d3LmZpb3JhaW9yZWdnaW9jYWxhYnJpYS5pdIIU
d3d3LmZpb3JhaW9yaXZvbGkuaXSCFXd3dy5maW9yYWlvc2FtYXNzaS5pdIIUd3d3
LmZpb3JhaW9zYXZvbmEuaXQwagYIKwYBBQUHAQEEXjBcMCMGCCsGAQUFBzABhhdo
dHRwOi8vb2NzcC5idXlwYXNzLmNvbTA1BggrBgEFBQcwAoYpaHR0cDovL2NydC5i
dXlwYXNzLm5vL2NydC9CUENsYXNzMkNBNS5jZXIwggEDBgorBgEEAdZ5AgQCBIH0
BIHxAO8AdgDoPtDaPvUGNTLnVyi8iWvJA9PL0RFr7Otp4Xd9bQa9bgAAAYVxtO2E
AAAEAwBHMEUCICCPwGx7SjqTM0buA9hGiX10dyiqJwt9BhCW9JY+5AR3AiEA9y8M
XN0Q62jGe4dH8K5jrMq5X7Aj1HixYIH+3ymyoJgAdQB6MoxU2LcttiDqOOBSHumE
FnAyE4VNO9IrwTpXo1LrUgAAAYVxtOuiAAAEAwBGMEQCIBYU3MIoG0Mr7egRxyv7
FwXEvFcb0/Uulqp3CiKo+zF1AiBPGslE3GEwJJsrcxU/J8b5GjBTGOSF70FXP+8h
gQJrYDANBgkqhkiG9w0BAQsFAAOCAgEAhxTHo2pl0ZUjtJbssngM3mF4c8xCYPX2
swj1LsgttV+9wYzcnK57+cfXbVnI38bc5SIG11Yj6wqoC8K0Yow2cxPnuHalzZE4
mhqUeZpklGc8rP4PKLPwtSXBiNe7XhAAb/AXEuIANXeQVKCb34oWO3MS5DIOfIg8
XufTjZN1701VncHzZG7TMmDmKH0t0Uw8YdwjkTG2l1+DZqU5LITerSnB5V7U1nhF
70G2KDoNex3+bhssupD05hItGzTH/unpd6xlgkp1r836DTOA3zwyg+HMyqdF2Sbt
lT5T+VtSeY4OVkRqEtrN1+/6BshnH7PuFuLGBWPzsqTBXpsoL8JSdZEA8i3TUFYy
lmSkSAzb9dH5DQ9vbeevJap2Zph+6KCebQ/ee4oKVplTZ2rTYgC6L+o9JAc72NDv
rYsBysDX9BT+UieucHwTTC0wTj73YNiMzqdjN8lxCNU2vmcN2pRnmLixvnbl209Q
pvOLjShwLnQWCMQqMe6G8ZO6GZ3PMPqWBRiM0iDc+cr4fpsyFhpMqV0+PhkuznHw
ojvSYff20sfdNs+ioDJKaHt6UzktQoRBqwCjcpRZHAqkVHvsvrsu77Rg1Qn2gtdj
ncwCtP3ByZCByv3YRhBROr4fM5ST4q5OPW1qMImVBxW3LE5Dvf+S4owS7jFsKOM6
KQz4KN1GJtw=
-----END CERTIFICATE-----
subject=/CN=www.fioraioperugia.it
issuer=/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 CA 5
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 3821 bytes and written 462 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 6D3F000018B088F84B6C1487F5EBDD54003956DFC113B7653EEA5DE80AFEF213
    Session-ID-ctx: 
    Master-Key: B35EA411FCAEC6479E0D56B38E575513C71726E6C9BB28274F2E464BA45B3F20D00B0BD8EDABC5F3D4695FC86E2A2CDD
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1674497399
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=104
```
  1. openssl s_client -connect www.pianomobil.com:443 -servername www.pianomobil.com -trusted_first
    
Output for www.pianomobil.com which does not work on iOS 9.3.5
CONNECTED(00000003)
depth=2 C = NO, O = Buypass AS-983163327, CN = Buypass Class 2 Root CA
verify return:1
depth=1 C = NO, O = Buypass AS-983163327, CN = Buypass Class 2 CA 5
verify return:1
depth=0 
verify return:1
---
Certificate chain
 0 s:
   i:/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 CA 5
 1 s:/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 CA 5
   i:/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGUzCCBDugAwIBAgILBLBkDX6dxo/fTVMwDQYJKoZIhvcNAQELBQAwSzELMAkG
A1UEBhMCTk8xHTAbBgNVBAoMFEJ1eXBhc3MgQVMtOTgzMTYzMzI3MR0wGwYDVQQD
DBRCdXlwYXNzIENsYXNzIDIgQ0EgNTAeFw0yMzAxMjEwNTU2MjBaFw0yMzA3MTky
MTU5MDBaMAAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCP4B455b
tYXGzsKF9Kitr1O5rgfgKT+xkro55u3x8NX70hgfbidltlqdP1cGUm3jVhjHcuH/
S6fp4Ynluj6cVvBUM8+j0z6wQKp2jBlVmVjzsp9sW2slvedVuByTXsaYgsfEtjK8
zq43iIS/Ea2S8LlEw1IG9XPRWoiS6UBwWjZ/KFXEX2EHii/fsXeOKze9pB5aNzhO
TkwLSKi3gy8Khz9EtpUy1SCyCqyu6zKSPqefK/UQPFtPz8nkk8ewla3OzUm90ZGI
RKR90LmixLb8RtJkQGjyHXbtOqQ/M0gu0CQZxjJMsSBVtJ17OkEZHsKPXfIqGcMJ
PrgYetzY5gMzAgMBAAGjggKBMIICfTAJBgNVHRMEAjAAMB8GA1UdIwQYMBaAFCdS
pG8tKqtAk5Ds1mnL/nxhO3xCMB0GA1UdDgQWBBQM1+/nQmAvcpNa25Pl2xH3xEWu
4zAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MB8GA1UdIAQYMBYwCgYIYIRCARoBAgcwCAYGZ4EMAQIBMDoGA1UdHwQzMDEwL6At
oCuGKWh0dHA6Ly9jcmwuYnV5cGFzcy5uby9jcmwvQlBDbGFzczJDQTUuY3JsMDAG
A1UdEQEB/wQmMCSCDnBpYW5vbW9iaWwuY29tghJ3d3cucGlhbm9tb2JpbC5jb20w
agYIKwYBBQUHAQEEXjBcMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5idXlwYXNz
LmNvbTA1BggrBgEFBQcwAoYpaHR0cDovL2NydC5idXlwYXNzLm5vL2NydC9CUENs
YXNzMkNBNS5jZXIwggEEBgorBgEEAdZ5AgQCBIH1BIHyAPAAdwDoPtDaPvUGNTLn
Vyi8iWvJA9PL0RFr7Otp4Xd9bQa9bgAAAYXS5js+AAAEAwBIMEYCIQDg+ruyTHYM
gybgUUjvFhRecVSkoHCJk7OHfNWucTP6+QIhAK7qDxP3EdBgdqJ2cHq1sCIqZ2zx
B8MO6z/0JWhS6Av2AHUAejKMVNi3LbYg6jjgUh7phBZwMhOFTTvSK8E6V6NS61IA
AAGF0uY7RgAABAMARjBEAiAMiLypp8MfiUZrRMdpWUYY7lwck6iGi4eAOzvOWP/g
lgIgP1JGr4fPO8QMjd5xDYZ0FSr1GTYqSBwEjxfpNmCTAxQwDQYJKoZIhvcNAQEL
BQADggIBAEF1Fzh/8nEmC7oR7EvZOo6HoVx+cKZAC8W9cmFrlu+EWyASGVu+UzCM
SdR7fxJL6XVN7udxhxlRr5NxU+rt4aqPuEITeLGeoqBvk/S388n4PEMWJrbZc+9T
HtMzuVB3I1Hm+gwB/YXgr76cDvmf+pyb0Q5q4v5HrcDCxwgVWSyOB+RnJ9cWcbJo
Zimic1tgWJnsIN/gmdB3WWTsj5ltqHs6BL1jBtiBSVEbRtq67vEoonbQX7TaRL8d
fOw6KwkK1fg5Cz7b7hIm7xW8TaT8LwSHoTybjmRtb2l1t/QQOn744YN/4bBPLFxc
Y5fP1ewt9CuRsxXaH3F+Xi6bjf5EfYPfFEgMjenbRd7PHGtEL6KZKg9tVxnV2wki
Wmek7j+fqcxoi4tG5VzgpLJ1J97D6RY6oN41JhBcqaGCLWkJ4eWSd4tD9ICteIW3
8JjXLD9YXOaRaDIa7x8E/pleuPsS8g03eDFRuLlYYF46frDVMZj3EpV031HyjCyb
a3PkLXQjdACRil2CRMzHhSPf7UHjr/CyQbe3EUZAxh144jFr8E7a8Aei/X0RokYQ
Htwo2o9cBjlIQt0BcCv+OwiCwNOHX/npQnh9JkR0zpCUQR2GV0wPTIOTjfOVitUe
FQxr0+JRq4y8VnCgdYQXPqJohlWBwvxV0TTrhR/93NmNYbFMdWdy
-----END CERTIFICATE-----
subject=
issuer=/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 CA 5
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3699 bytes and written 428 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 0DDA6471EBE717166F76095BE1280FBA933ED348D5C3D984282C53DC7C51F9A5
    Session-ID-ctx: 
    Master-Key: BE089849280111B3FFB7860B5454E52E88563EE391537F33F493C36AD72329427A3AC2CE4A1CC57AADC1BC402739CDC7
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1674497686
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

^C

From what I'm seeing – unless I ran the command wrong or am looking in the wrong place –

  • both domains have identical Certificate chain entries
  • both use Buypass Class 2 CA 5 as intermediary, which indeed is valid Not Before May 23 12:57:38 2017 GMT (I couldn't figure out which command you used to get this output in command line, so I had to look up the cert details in my browser, the value I got is 23/05/2017 14:57:38 UTC+2, so same thing.)

Only obvious difference I'm seeing in the chains is the one that works on iOS 9.3.5 has the Subject CN.

Moreover, according to how my browser renders the Certificate Hierarchy, the Buypass Class 2 CA 5 is listed under Buypass Class 2 Root CA which is valid between 2010 and 2040.

Screen shot

I agree the 2017 date does look like it could be the reason, but apparently it's not that, but something else?

What does openssl version show?

1 Like
# openssl version
OpenSSL 1.0.2l  25 May 2017

(It's an old system I have in Virtualbox for local development.)

1 Like
# certbot --version
certbot 1.12.0
1 Like

I know some Apple systems use LibreSSL, thought it was worth a check.

2 Likes

It doesn't matter if an OS supports an intermediate or not, that's why it's an intermediate. Only the root matters.

5 Likes

I haven't maintained any iOS apps in a while, so my best advice right now is to track down some iOS people or talk to BuyPass and see if this may the cause:

Until LetsEncrypt faced the DST Root X3 Expiration, there were very little commonalities regarding what OpenSSL and various libraries did with Certificates and Certificate Chains. There still is a wide amount of variation and every browser/library handles things differently, but even as short as 3 years ago the industry was completely different.

The major behavior that current systems coalesced around, is that Certificate Chains are largely meaningless by default. Five years ago, a Certificate Chain may - or may not - have meant something. Today, the default standard is to pretty much ignore the chain and just focus on the trusted key pairings – as long as a client can build it's own path up to a Trusted Root, they really don't care what the server presents (expired intermediates, incorrect intermediates, etc). This is often called "short circuit logic" or "alternative pathbuilding".

The presence of BuyPass intermediates in the iOS, alongside their roots, in the iOS trust store makes me think there is some iOS specific behavior that required that. It is very rare to see intermediates in a trust store. I would not be surprised if that is tied to the "critical" configuration on the Certificate that is requiring an intermediate to be in the trust store or something similar.

4 Likes

add-cn-to-csr-v1.12.0.patch.txt (2.5 KB)

You can use the above patch for Certbot 1.12.0 to include the first SAN as a Common Name in the subject. Note: I haven't actually tested it with the Buypass (or Let's Encrypt) ACME servers, only Pebble.

For those who want one for Certbot 2.2.0:
add-cn-to-csr-v2.2.0.patch.txt (3.2 KB)
:stuck_out_tongue:

Both quick 'n dirty and WITHOUT ANY WARRANTY what so ever! MIT license :stuck_out_tongue:

4 Likes

This is really puzzling me. I just went through too many old docs.

In this field, "critical" is required by RFC 5280: 4.1.2.6 to be present when the Subject/CN is empty, to identify the SAN extension MUST be included.

I haven't found any old apple developer documents, mailing lists, or tech posts regarding empty CNs on older iOS versions. I feel like there would be a large digital paper trail on that issue if it were a concern.

3 Likes

I can confirm that with the above patch to Certbot, Buypass will gladly issue a cert with a Common Name in the Subject field and will not add a critical to the SAN extension.

3 Likes

Thank you for posting the patches!

My question is this then: I revisited the 1.12 documentation, as well as the latest stable documentation, where under -d DOMAIN, --domains DOMAIN, --domain DOMAIN it says this (emphasis mine):

Domain names to apply. For multiple domains you can
use multiple -d flags or enter a comma separated list
of domains as a parameter. The first domain provided
will be the subject CN of the certificate
, and all
domains will be Subject Alternative Names on the
certificate.

Why isn't the subject CN name already being picked automatically with the official certbot version? Is this worthy of a Github issue in the certbot repo?

1 Like