IT点滴

我不去想是否能够成功 既然选择了远方 便只顾风雨兼程
  博客园  :: 首页  :: 联系 :: 订阅 订阅  :: 管理

[转]X.509证书DN之详解

Posted on 2009-03-17 12:14  Ady Lee  阅读(3339)  评论(0编辑  收藏  举报

 

X.509证书DN之详解

十二月 4th, 2008 by Soloman | Print X.509证书DN之详解 | 823 views

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 的测试:

原文 http://blog.ipattern.org/archives/653