X.509被广泛使用的数字证书标准,是由国际电联电信委员会(ITU-T)为单点登录(SSO-Single Sing-on)和授权管理基础设施(PMI-Privilege Management Infrastructure)制定的PKI标准。X.509定义了(但不仅限于)公钥证书、证书吊销清单、属性证书和证书路径验证算法等证书标准。
X.509最初是在1988年的7月3日发布的,版本是X.509 v1,当时是作为ITU X.500目录服务标准的一部分。它设定了一系列严格的CA分级体系来颁发数字证书。和其他网络信任模型(譬如PGP)对比,任何人,不仅仅是特定的 CA,可以签发并验证其他密钥证书的有效性。
X.509 2 版引入了主体和签发人唯一标识符的概念,以解决主体和/或签发人名称在一段时间后可能重复使用的问题。大多数证书监视文档都极力建议不要重复使用主体或签发人名称,而且建议证书不要使用唯一标识符。版本 2 证书尚未得到广泛使用。
X.509 3 版是最新的版本(1996 年)。它支持扩展的概念,因此任何人均可定义扩展并将其纳入证书中。现在常用的扩展包括:KeyUsage(仅限密钥用于特殊目的,例如“只签”)和 AlternativeNames(允许其它标识与该公钥关联,例如 DNS 名、电子邮件地址、IP 地址)。扩展可标记为“极重要”,以表示应选中该扩展并强制执行或使用。例如,如果某一证书将 KeyUsage 扩展标记为“极重要”,而且设置为“keyCertSign”,则在 SSL 通信期间该证书出现时将被拒绝,因为该证书扩展表示相关私钥应只用于签写证书,而不应该用于 SSL。
现在的证书基本上都是v3版本
如上图所示,为签名过程和client端验证过程。中间方框为一个数字证书,在制作数字证书时,会将证书中的部分内容使用签名算法计算得到签名,然后CA使用私钥将该签名值加密为指纹信息。
当证书发送给客户端之后,客户端首先会使用同样的签名算法获得签名1。在用CA的公匙对签名指纹解密得到一个hash值H2。
比较签名1和签名2,如果值相同,则为可信赖的证书,否则则认为证书不可信。
域名型:DV
企业型:OV
增强型:EV
域名型仅确认域名
企业型和增强型需要企业的相关信息(增强型需要更多的信息)
在申请证书时,根据自己的需求,选择对应的级别。
证书是三个连串(SEQUENCE)的字段:tbsCertificate、signatureAlgorithm、signatureValue
tbsCertificate:这个字段含有主题和发行者的名字,主题联系起来的公开密钥,有效期和其他相关信息。
signatureAlgorithm:signatureAlgorithm字段含有CA签发证书使用的密码学算法标识符。
signatureValue:signatureValue字段包括对tbsCertificate的ASN.1 DER编码的数字签名。TbsCertificate
的ASN.1 DER编码作为签名函数的输入参数。这个签名结果值然后作为BIT STRING 类型*
的ASN.1*编码,并且包括在证书的签名字段中。
// X.509数字证书
Certificate
// 版本号
Version Number
// 序列号
Serial Number
// 证书签名算法
Signature Algorithm
// 证书发行者
Issuer Name
// 证书有效时间
Validity period
// 证书主体名称
Subject name
// 证书主体公钥信息
Subject Public Key Info
// 证书公钥算法
Public Key Algorithm
// 证书公钥
Subject Public Key
// 发行商唯一ID
Issuer Unique Identifier (optional)
// 主体唯一ID
Subject Unique Identifier (optional)
// 扩展
Extensions (optional)
// 证书签名算法
Certificate Signature Algorithm
// 证书签名值
Certificate Signature
v3版本中加入了证书扩展字段,对证书体系做了更加细致的规范
扩展字段可标记为及其重要:critical
当一个扩展字段被设置为critical时,在证书校验时,如果扩展字段校验失败,则证书校验失败
比较重要的扩展字段有以下几个:
id-ce-keyUsage:密钥使用
指定了这份证书包含的公钥可以执行的密码操作,例如只能用于签名,但不能用来加密。
id-ce-basicConstraints:基本约束
用于指示一份证书是不是CA证书。
id-ce-extKeyUsage:密钥使用扩展
Extended Key Usage{id ce 37},典型用法是指定叶子证书中的公钥的使用目的。它包括一系列的OID,每一个都指定一种用途。例如{id pkix 31}表示用于服务器端的TLS/SSL连接;{id pkix 34}表示密钥可以用于保护电子邮件。
CA是证书的签发机构,它是公钥基础设施(Public Key Infrastructure,PKI)的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。
CA 拥有一个证书(内含公钥和私钥)。网上的公众用户通过验证 CA 的签字从而信任 CA ,任何人都可以得到 CA 的证书(含公钥),用以验证它所签发的证书。
实际证书申请中,由于权威的CA机构数量不多,若所有的服务器证书都向权威CA机构申请,那么CA机构的工作量就会非常大,同时也考虑到安全因素,因此CA机构采取授权二级机构的方式来管理证书申请,经授权的二级机构也可以签发服务器证书。
中间证书与CA证书一样,也是负责签发证书、认证证书、管理已颁发证书,只不过中间证书的指纹是用CA的私钥加密。
服务器证书就是服务器自己的证书,不能签发下层证书,只能使用,服务器证书的指纹用的是上层证书的私钥加密,需要用上层证书的公钥进行解密
在浏览器的证书验证中,会从服务器证书开始,向上寻找上级证书,直到找到浏览器内置的CA证书。如果一个证书无法找到CA证书,则该证书会被认为是无效证书,浏览器会进行提示,继续访问有风险。
如图
1、根据服务器证书的签发组织找到中间证书(一般网站会将证书链中除了CA证书的其他证书全部发送给客户端)
2、根据中间证书的签发组织找到CA证书
3、用CA证书的证书公匙解密中间证书的签名指纹,如果能够解密并验证,则说明中间证书是由CA颁发,并且信息没有篡改
4、用中间证书的证书公匙解密服务器证书的签名指纹,如果能够解密并验证,则说明服务器证书是由中间证书颁发,并且信息没有篡改
5、还会对服务器证书的域名、证书期限等基本信息进行验证,全部验证通过则确认证书验证通过。