Runtime: X509Certificate2 Subject is empty on Linux in netcoreapp3.1

[TimHess]

Similiar to #29693, but using netcoreapp3.1, I'm seeing an empty subject parsing certificates that are provided by Cloud Foundry

The following code results in success on Windows, but an empty subject on Linux:

var certstring = @"-----BEGIN CERTIFICATE-----
MIIEBzCCAu+gAwIBAgIQLlpk6CS8R0Z09GPVciC2qjANBgkqhkiG9w0BAQsFADAyMTAwLgYDVQQD
EydEaWVnbyBJbnN0YW5jZSBJZGVudGl0eSBJbnRlcm1lZGlhdGUgQ0EwHhcNMjAwMjE5MTkzMjQy
WhcNMjAwMjIwMTkzMjQyWjCByDGBnjA4BgNVBAsTMW9yZ2FuaXphdGlvbjpkN2FmZTVjYi0yZDQy
LTQ4N2ItYTQxNS1mNDdjMDY2NWYxYmEwMQYDVQQLEypzcGFjZTpmMDNmMmFiMC1jZjMzLTQxNmIt
OTk5Yy1mYjAxYzEyNDc3NTMwLwYDVQQLEyhhcHA6MTA4ZmU0ZDUtYTgzZS00OGI5LWE1NDktMDU0
MmU3MWE0N2E2MSUwIwYDVQQDExw4OTE4MmE5Yi0wNjhmLTQ4NjgtNGYwZS01OWFhMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx+3DZQ6LvxB3wM7LWdfRQvj5X75aYMRip/bGlvJVBFvN
cKQqSjijtqHO0d71cLJbZPrtNrmBDLSKGjpzuEq3+EbA2rbL7Tl/WWxdV9dRq2nZQuNF4sh47o6o
ME4CA6S17E7dPBvXPXaRNIhvrGocoga6yhpYBT3iMXKSZnum5KI2qVLXNmCgQVN0G62QSzd3cjsv
+iEa/y3CntnZJ42elq+VfCECin0o35vOzA42GE5zqZokd/FEHg1Cl9flZknIHTxWgW5qQqYzPwZo
w+a26B/kQNJOR4yx1mgQgdmq+6KHdGKQqDhQ9I1I7hTWUXTLx4X0a5pwmWvM2aQKgC/dFwIDAQAB
o4GBMH8wDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAfBgNV
HSMEGDAWgBTv0ki5J6EjEz9YdOBuRe+m74pvXDAtBgNVHREEJjAkghw4OTE4MmE5Yi0wNjhmLTQ4
NjgtNGYwZS01OWFhhwQK/3mKMA0GCSqGSIb3DQEBCwUAA4IBAQB0Ao4jbowTGvF1jf5i+9oQBrsA
YKepkZkirIzhKIKVfZEEgMRzm4CVNhB0MG5NiGn7x8XZlCIAO7jVSGOlT51nFx5Q16iyoBHv1r9b
RJ8edDcaHcZ67VuCGppsAyPNobrsMCvNaW4OZsHqQ+H2Tq3btKYqxYw1foWHEJVTJ2ys0ltZ3/IM
phubW4vcUC2Cyn0CMQxZjJs0nMBFy2zgtGAQX7zE6+nKVkzviWjDprHWv90xax08SmPg/OHqYS1s
aBg2iHnjlg9taunpE2KGgPrbU0exPnaV+xYDqRxvoN0cC+mkGuehuVBy/DRtJ3WfevH6sdgqr4BP
cQxzGDwe9ata
-----END CERTIFICATE-----";

var cert = new System.Security.Cryptography.X509Certificates.X509Certificate2(System.Text.Encoding.UTF8.GetBytes(certstring));
System.Console.WriteLine("Certificate subject: {0}", cert.Subject);

[davidsh]

@bartonjs

[vcsjones]

@bartonjs X500NameEncoder.ManagedDecode is throwing because it is validating that the SetOf is DER sorted, which for the subject of this certificate, it is not. The exception is getting eaten and an empty string is returned in it's place.

Changing rdnReaders.Add(x500NameSequenceReader.ReadSetOf()) to rdnReaders.Add(x500NameSequenceReader.ReadSetOf(skipSortOrderValidation: true)) in the managed X500DistinguishedNameDecode "fixes" it.

[bartonjs]

Sigh. Sometimes I wonder if standards exist only so that people can _not_ follow them.

If Windows already processes things without validating sort order, I guess we can, too.

[vcsjones]

@bartonjs I'll take it.

[TimHess]

Thanks for the quick response - this isn't exactly my area of expertise, could you point me at the standard in question so that I can relay it to the team/project that is responsible for creating these certificates so that they might fix the issue on their end as well?

[bartonjs]

@TimHess X.509 certificates are defined to use DER encoding.

Within the rules for DER encoding, ITU-T REC X.690 (2015/08):

11.6 Set-of components
The encodings of the component values of a set-of value shall appear in ascending order, the encodings being compared as octet strings with the shorter components being padded at their trailing end with 0-octets. NOTE – The padding octets are for comparison purposes only and do not appear in the encodings.

(For a homogenous SET-OF it means that the shortest items come first, because everything's length prepended, then "dictionary sort" the contents if the lengths are equal ("a" beats "aa")).

The canonical order for the repro is

• Subject (RDNSequence (SEQUENCE))
  
  
  
  • RelativeDistinguishedName (SET-OF)
  
  
  • AttributeTypeAndValue (SEQUENCE, 47 bytes)
    
    
    
    
    
    • type (OID) : 2.5.4.11
    
    
    
    • value (PrintableString): app:...
    
    
    
  
  
  • AttributeTypeAndValue (SEQUENCE, 49 bytes)
    
    
    
    
    
    • type (OID) : 2.5.4.11
    
    
    
    • value (PrintableString): space:...
    
    
    
  
  
  • AttributeTypeAndValue (SEQUENCE, 56 bytes)
    
    
    
    
    
    • type (OID) : 2.5.4.11
    
    
    
    • value (PrintableString): organization:...
    
    
    
  
  
  • RelativeDistinguishedName (SET-OF)
  
  
  • AttributeTypeAndValue (SEQUENCE, 35 bytes)
    
    
    
    
    
    • type (OID) : 2.5.4.3
    
    
    
    • value (PrintableString): (the CN)
    
    
    
  
  

But the encoded value is backwards in the multi-value OU (it was organization / space / app; which is exactly backwards).

Generally it doesn't come up, because multi-value RDNs aren't very common (I want to say they're discouraged, but I can't find a specific thing to quote for that...)

[vcsjones]

@bartonjs should this be serviced in to the 3.1 LTS branch? This "broke" in 3.0 because the ASN.1 decoding was using a different implementation. i.e. the subject decoding for this certificate works in 2.x but not 3.1 on Linux.

[TimHess]

I'm not sure the subject names _will_ be fixed from the other side in our case, so adding this change in 3.1 would allow the feature I'm working on to work cross-platform nearly a year sooner than having to wait for 5.0, so I would really appreciate it!

[bartonjs]

If it changed (broke) between 2.1 and 3.1, then yeah, it's probably good to service it. (@danmosemsft FYI).

If you want to open the PR against the release/3.1 branch I'll do the paperwork; or I'll open the PR and paperwork tomorrowish.

[vcsjones]

If it changed (broke) between 2.1 and 3.1, then yeah, it's probably good to service it.

Correct. It works in 2.1 but not 3.1:

It looks like this is because [2.1] uses DerSequenceReader, and [3.1] uses AsnReader, and the former did not perform sort validation at read time.

[vcsjones]

If you want to open the PR against the release/3.1 branch I'll do the paperwork

Done.