I have a website with multiple web applications that relies on the end user authenticating with their x509 client certificate. We are observing that the same certificate, when processed by a .Net application, shows a different Subject DN than when processed by a Java application, when the DN contains an e-mail address attribute.
In .Net, I see the server variable CERT_SUBJECT like this:
C=US, S=Delaware, L=Wilmington, O=IDFC Dev, OU=Test, CN=Richard Sand, [email protected]
In Java, when I explore the x509 certificate object for the same cert (same browser session), the subject is:
[email protected], CN=Richard Sand, OU=Test, O=IDFC Dev, L=Wilmington, ST=Delaware, C=US
Ignoring the reversed order of the attributes (which is a known phenomenon), the problem we're having is that in Java the e-mail address attribute is EMAILADDRESS whereas in .Net the same attribute shows as E.
Digging further, OpenSSL shows this output:
openssl.exe pkcs12 -in my.pfx -info
subject=/C=US/ST=Delaware/L=Wilmington/O=IDFC Dev/OU=Test/CN=Richard Sand/[email protected]
Whereas when I view the same certificate in either the IE or Firefox certificate stores, they show E=, e.g.:
E = [email protected]
CN = Richard Sand
OU = Test
O = IDFC Dev
L = Wilmington
S = Delaware
C = US
I know it may seem trivial to just shim in some code to change one "interpretation" of the Subject DN to the other, but the problem is we have two COTS products that we cannot alter, and before we start hacking around the problem I want to understand which (or are both?) correct and if there is something on some layer that is causing the discrepancy. The RFCs all seem to reference EMAILADDRRESS, but as said both IE and FF as well as the .Net app all seem to be using "E"
Can anyone explain why this is happening?
Thanks!
E
and EMAILADDRESS
are synonyms.
When an electronic mail address is embedded in the subject distinguished name (deprecated, should be used subject alternative name extensions) it uses the identifier pkcs-9-at-emailAdress
defined in PCKS#9 (RFC2985).
It means the emailAddress is not stored with a string E
or EMAILADDRESS
, but as an ASN.1 structure with the identifier 1.2.840.113549.1.9.1
, and what .NET, Java or IE are showing is a representation of this attribute.
If you want to check if the subject of a certificate match, you need to compare each RDN field, not the string.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With