X.509证书DN之详解

文章原始出处和作者信息及本声明http://www.blogbus.com/sdjnzjliu-logs/52585243.html

 

• X.509使用DN（Distinct Name）来唯一标识一个实体，其功能类似我们平常使用的ID，不过不同的是，DN不再是类似 123456 这样得数字标识，而是采用多个字段来标识一个实体，例如”CN=老所,C=CN”，这样做的好处在于方便匹配到诸如LDAP一样的目录服务中。那么，DN的字段是否可以随意增加呢？比如我能否在”CN=老所,O=测试公司”这样一个DN上再增加一个ID属性，变成”CN=老所,O=测试公司,ID=123456″呢？

   

  动手测试。首先采用微软的 XEnroll 组件来进行测试。XEnroll 是微软平台下的 ActiveX 控件，提供证书的加入服务，比如创建 PKCS#10 证书请求。我们可以用 Javascript 来调用这个 ActiveX 控件：

  var sOID = '';
  var sDN = 'CN="老所",O="测试公司",ID="123456"';
  alert(sDN);
  var sPKCS10 = oXEnroll.createPKCS10(sDN, sOID);

  其中，createPKCS10 函数接受两个参数，第一个是字符串类型的DN，第二个是用以标识该证书请求的用途的OID，这里，我们不在乎该证书的用途，所以就设为空好了。通过 IE 运行该段代码后，我得到了 object Error，看来，不能这样简单地添加DN字段。

  于是开始搜索关于 X.509 DN 的信息。原来，X.509 证书里的 DN 属性，都是一些基于 ASN1 编码的对象，也就是说，对于我们熟知的 CN 属性，或者说 commonName 属性，程序是无法从证书里获得的，证书里是不会写诸如 CN=xxx 这样的信息的。所有字段都被表示为该字段类型的 OID 。OID 则是 ASN1 对象的统一表示方法，这种方法采用树状结构，由国际组织统一管理。一个公司如果要增加一个字段类型，并希望被广泛采用，它必须像管理 OID 的组织提出申请，就像我们常用的域名申请一样。

  在 www.oid-info.com 这个网站，我们可以查询所有注册过的 OID 信息。这个网站提供两种方式的查询：按树状结构展开各级 OID，或者直接填写诸如”2.3.4″这样的 OID 来进行查询。

  假如我们展开 2.5.4 这层 OID，我们就会发现很多我们常用的 DN 字段：

  • 2.5.4.3 - commonName
  • 2.5.4.4 - surname
  • 2.5.4.13 - description
  • 2.5.4.10 - organizationName
  • ……

  既然如此，那我们就采用 OID 形式来添加属性类型吧，比如我使用 OID=2.5.4.888，这是一个未被注册的 OID，可以用来测试：

  var sOID = '';
  var sDN = 'CN="老所",O="测试公司",2.5.4.888="123456"';
  alert(sDN);
  var sPKCS10 = oXEnroll.createPKCS10(sDN, sOID);

  运行该脚步，成功了，我们从机器里的证书申请库里找到该证书申请，查看其属性：

  

   

  可以看出，虽然用 OID 添加属性成功了，但这个 OID 并不能被翻译成方便我们阅读的形式，就像我们只能使用 IP 而无法使用域名一样。要让该证书显示 ID= 而不是 2.5.4.888=，我们必须要：

  • 向标准组织注册 2.5.4.888 为 ID;
  • 通知微软，修改其 Windows 程序，将该 OID 翻译为 ID

  显然，这非常不现实，呵呵。

  接下来，我们再用 openssl 来测试一下。我选用的是 pyOpenSSL，一个 openssl 的 Python 包装库：

  >>> from OpenSSL import crypto
  >>> req = crypto.X509Req()
  >>> subject = req.get_subject()
  >>> setattr(subject, 'CN', 'soloman')
  >>> setattr(subject, 'ID', '123456')
  Traceback (most recent call last):
  File "", line 1, in 
  AttributeError: No such attribute
  >>>
  

  看来，pyOpenSSL也只认识 CN，不认识 ID。查询了一下 pyopenssl 的源代码：

  static int
  crypto_X509Name_setattr(crypto_X509NameObj *self, char *name, PyObject *value)
  {
  int nid;
  int result;
  char *buffer;
  if ((nid = OBJ_txt2nid(name)) == NID_undef)
  {
  PyErr_SetString(PyExc_AttributeError, "No such attribute");
  return -1;
  }
  ......

  可以看出，pyOpenSSL 在设置 DN 的时候，首先调用 openssl 的 OBJ_txt2nid()函数来将方便我们记忆的对象名字翻译成 OID, 然后再翻译成 openssl 程序里自己的 NID。

  那么继续查询 openssl 的源代码，在 objects.h 文件里我们找到了所有 DN 字段的定义：

  ......
  #define SN_commonName			"CN"
  #define LN_commonName			"commonName"
  #define NID_commonName			13
  #define OBJ_commonName			OBJ_X509,3L
  #define SN_countryName			"C"
  #define LN_countryName			"countryName"
  #define NID_countryName			14
  #define OBJ_countryName			OBJ_X509,6L
  #define SN_localityName			"L"
  #define LN_localityName			"localityName"
  #define NID_localityName		15
  #define OBJ_localityName		OBJ_X509,7L
  ......

  这里，openssl 为每个常用的 DN 属性定义了4个内容：SN, LN, NID, OBJ。其中 SN 表示 Short Name, LN 表示 Long Name，都是一个 OID 方便我们阅读的名称的两个形式，而 OBJ 则定义了其 OID 信息。

  在 openssl/crypto/asn1/a_strnid.c 这个文件里，绑定了 openssl 能够支持并翻译的 DN 字段：

  static ASN1_STRING_TABLE tbl_standard[] = {
  {NID_commonName,		1, ub_common_name, DIRSTRING_TYPE, 0},
  {NID_countryName,		2, 2, B_ASN1_PRINTABLESTRING, STABLE_NO_MASK},
  {NID_localityName,		1, ub_locality_name, DIRSTRING_TYPE, 0},
  {NID_stateOrProvinceName,	1, ub_state_name, DIRSTRING_TYPE, 0},
  {NID_organizationName,		1, ub_organization_name, DIRSTRING_TYPE, 0},
  {NID_organizationalUnitName,	1, ub_organization_unit_name, DIRSTRING_TYPE, 0},
  {NID_pkcs9_emailAddress,	1, ub_email_address, B_ASN1_IA5STRING, STABLE_NO_MASK},
  {NID_pkcs9_unstructuredName,	1, -1, PKCS9STRING_TYPE, 0},
  {NID_pkcs9_challengePassword,	1, -1, PKCS9STRING_TYPE, 0},
  {NID_pkcs9_unstructuredAddress,	1, -1, DIRSTRING_TYPE, 0},
  {NID_givenName,			1, ub_name, DIRSTRING_TYPE, 0},
  {NID_surname,			1, ub_name, DIRSTRING_TYPE, 0},
  {NID_initials,			1, ub_name, DIRSTRING_TYPE, 0},
  {NID_serialNumber,		1, ub_serial_number, B_ASN1_PRINTABLESTRING, STABLE_NO_MASK},
  {NID_friendlyName,		-1, -1, B_ASN1_BMPSTRING, STABLE_NO_MASK},
  {NID_name,			1, ub_name, DIRSTRING_TYPE, 0},
  {NID_dnQualifier,		-1, -1, B_ASN1_PRINTABLESTRING, STABLE_NO_MASK},
  {NID_domainComponent,		1, -1, B_ASN1_IA5STRING, STABLE_NO_MASK},
  {NID_ms_csp_name,		-1, -1, B_ASN1_BMPSTRING, STABLE_NO_MASK}
  };

  可以看出，如果要让我们的基于 openssl 的程序支持一个我们自定义的属性，我们得修改 openssl 源代码，添加我们的新字段的”名称-OID” 绑定（可以只有Long Name），然后重新编译 openssl 和我们的程序，使其能使用新的属性。

  我们回过头来想想，为什么标准化组织没有为我们提供一个类似 ID 这样的属性呢？这是因为，DN本来就是作为 ID 来使用的，它把一些属性绑定起来，来标识一个实体，如果再有一个通用的 ID 属性，逻辑上就冲突了。当然针对具体的应用，你可以注册一个特殊的 ID 属性，比如 openID ，但这需要实力雄厚的公司来进行注册和推广。

  然而实际应用中，当我们想将证书系统与某个特别的应用中的某个 ID 进行绑定，而又不具备向国际组织进行 OID 注册和推广的能力时，我们完全可以利用现有的属性来进行实现，比如，针对这个需求，我可以设计出两个方案：

  • 方案一：CN=老所@123456
  • 方案二：CN=123456, surname=老, givenName=所
  • 方案三：CN=123456, name=老所
  • 方案四：CN=老所, description=123456

  方案一，通过一定的方式，将用户的姓名和ID组合到CN里，然后在应用中解析出ID，这个方法不是很便于用户书写，用户在填写证书申请资料的时候必须注意符合该规范。

  方案二与三的概念就是用CN来记录ID，毕竟，Common Name 嘛，随你如何定义。而用户的姓名由 surname + givenName 或者 name 来指定。该方法通过了 openssl 测试：

  >>> req = crypto.X509Req()
  >>> subject = req.get_subject()
  >>> setattr(subject, 'surname', 'Lao')
  >>> setattr(subject, 'givenName', 'Suo')
  >>> setattr(subject, 'name', 'Lao Suo')
  

  但是，XEnroll 仿佛不支持 surname + givenName 或者 name 属性，其文档上说明是支持 X.500 规范，而不是 X.509 规范。

  方案四，则利用了 description 属性来记录和具体应用相关的讯息，比如我们的 ID，该方法通过了 openssll 的测试：

  >>> req = crypto.X509Req()
  >>> subject = req.get_subject()
  >>> setattr(subject, 'CN', 'Lao Suo')
  >>> setattr(subject, 'description', '123456')
  

  和 XEnroll 的测试：