我正在编写一个简单的脚本来为我们的员工生成CSR，而不必担心openssl所需的所有小问题，并且我注意到了emailAddress的问题这个主题的一部分。
在填写CLI提供的选项时，我的主题大致是：
Subject: C=UK, L=London, O=Org, OU=Unit, CN=my.domain/emailAddress=me@my.domain
如果我在命令行中使用-subj选项并保持参数顺序相同，则结果相同：
$ openssl req -new -key my.key -out my.csr \
-subj="/C=UK/L=London/O=Org/OU=Unit/CN=my.domain/emailAddress=me@my.domain"
给出
Subject: C=UK, L=London, O=Org, OU=Unit, CN=my.domain/emailAddress=me@my.domain
但是，如果我把emailAddress放在前面
$ openssl req -new -key my.key -out my.csr \
-subj="/emailAddress=me@my.domain/C=UK/L=London/O=Org/OU=Unit/CN=my.domain"
我得到了
Subject: emailAddress=me@my.domain, C=UK, L=London, O=Org, OU=Unit, CN=my.domain
我想要了解的是：
my.domain/emailAddress=me@my.domain是有效的CommonName吗？emailAddress是否为有效的主题名称？证书是用于客户端身份验证的，从安全的角度来看，我认为这并不重要，但我很好奇。
（RFC5280要么缺少这些信息，要么我不理解......可能是后者了）
答案 0 :(得分：1)
> What is CommonName specifically for?
RFC5280, sec. 4.1.2.4是指X.520（......＆＃34; 标准属性集已在X.500系列规范中定义[X.520] ＆＃ 34）。 ITU-T recommendation on X.520（参见链接的PDF，第6.2.2节）给出了一些关于CommonName是什么的一般性讨论。一句话的引用可能是：
...它是一个（可能是模糊的）名称，通过该名称，对象在某些有限的范围（例如组织）中通常是已知的，并且符合与之关联的国家或文化的命名约定的
> Is my.domain/emailAddress=me@my.domain a valid CommonName?
CommonName可能包含任意字符串，因此这将是一个有效的CN。 但是您的CSR没有。您的两个CSR实际上都有CN=my.domain。 OpenSSL只是通过斜杠显示 emailAddress主题字段，这无疑令人困惑！ （OpenSSL常见问题解答calls this＆＃34;旧行为＆＃34 ;;我不知道为什么这样的行为出现在＆＃34;旧的＆＃34;。）OpenSSL req有选项{{1 }（在-nameopt中记录），例如man x509会在没有这种混淆的情况下向您展示主题。
openssl req [...] -nameopt RFC2253您是否打算询问＆＃34;电子邮件地址是否是主题名称表示的有效部分＆＃34;？
主题名称，根据RFC5280 4.1.2.6，＆＃34;。 ..必须包含X.500专有名称＆＃34;。反过来，根据RFC1779，可分辨名称是键值对的列表，任何具有OID的东西都可以是键。而不是数字OID，一个＆＃34;关键字＆＃34;可能用过了; RFC1779友好状态＆＃34;有效关键字的注册表由IANA维护。＆＃34; 好吧，> Is emailAddress a valid subject name?
有OID 1.2.840.113549.1.9.1，因此它应该算作＆ ＃34;有效＆＃34 ;. RFC2985中特别提到了这一点。 （当然，OpenSSL会识别它;它列在emailAddress标题中。）
objects.h对我来说，它看起来像前者！
现在，问题中的一件事对我来说仍然是一个问题：您展示的两个CSR有何不同，这使得> (RFC5280 is either lacking this information or I don't
> understand it... probably the later)
以两种不同的方式展示。