我有一个网站，其中包含多个Web应用程序，这些应用程序依赖于最终用户使用其x509客户端证书进行身份验证。我们观察到，当.Net应用程序处理时，相同的证书显示与DN应用程序处理时不同的主题DN，当DN包含电子邮件地址属性时。
在.Net中，我看到服务器变量CERT_SUBJECT如下：
C=US, S=Delaware, L=Wilmington, O=IDFC Dev, OU=Test, CN=Richard Sand, E=rsand@idfconnect.lan
在Java中，当我探索相同证书（相同浏览器会话）的x509证书对象时，主题是：
EMAILADDRESS=rsand@idfconnect.lan, CN=Richard Sand, OU=Test, O=IDFC Dev, L=Wilmington, ST=Delaware, C=US
忽略属性的颠倒顺序（这是已知现象），我们遇到的问题是，在Java中，电子邮件地址属性是 EMAILADDRESS ，而在.Net中具有相同的属性显示为 E 。
进一步深入研究，OpenSSL显示了这个输出：
openssl.exe pkcs12 -in my.pfx -info
subject=/C=US/ST=Delaware/L=Wilmington/O=IDFC Dev/OU=Test/CN=Richard Sand/emailAddress=rsand@sidfconnect.lan
当我在IE或Firefox证书库中查看相同的证书时，它们显示E =，例如：
E = rsand@idfconnect.lan
CN = Richard Sand
OU = Test
O = IDFC Dev
L = Wilmington
S = Delaware
C = US
我知道只是简单地用一些代码来改变主题DN对另一个的“解释”，但问题是我们有两个我们无法改变的COTS产品，并且在我们开始黑客攻击之前问题我想了解哪个（或两个都是？）正确，如果某个层上有某些东西导致了这种差异。 RFC似乎都引用了EMAILADDRRESS，但正如所说IE和FF以及.Net应用程序似乎都在使用“E”
任何人都可以解释为什么会这样吗？
谢谢！
答案 0 :(得分：3)
E和EMAILADDRESS是同义词。
当电子邮件地址嵌入主题专有名称（不建议使用，应使用主题替代名称扩展名）时，它使用PCKS＃9（RFC2985）中定义的标识符pkcs-9-at-emailAdress。
这意味着emailAddress不存储字符串E或EMAILADDRESS，而是存储为标识符为1.2.840.113549.1.9.1的ASN.1结构，以及.NET，Java或IE是什么显示是此属性的表示。
如果要检查证书的主题是否匹配，则需要比较每个RDN字段，而不是字符串。