【PKI】【CA】【证书签发】

1. PKI概念

PKI是 Public Key Infrastructure（公钥基础设施）的缩写，是一个包括硬件、软件、人员、策略和规程的集合，用来实现为公钥、相关的用户身份信息签发数字证书，为用户提供方便的证书申请、证书作废、证书获取、证书状态查询的途径，并利用数字证书及相关的各种服务（证书发布，黑名单发布，时间戳服务等）实现通信中各实体的身份认证、完整性、抗抵赖性和保密性。

PKI技术采用证书管理公钥，通过第三方的可信任机构CA认证中心把用户的公钥和用户的其他标识信息捆绑在一起，在互联网上验证用户的身份。目前，通用的办法是采用建立在PKI 基础之上的数字证书，通过把要传输的数字信息进行加密和签名，保证信息传输的机密性、真实性、完整性和不可否认性，从而保证信息的安全传输。

CA中心——CA系统——数字证书

CA 中心管理并运营 CA 系统，CA 系统负责颁发数字证书。

专门负责颁发数字证书的系统称为 CA 系统，负责管理并运营 CA 系统的机构称为 CA 中心。所有与数字证书相关的各种概念和技术，统称为 PKI。

在PKI机制的保障前提下，进行可信赖的网络通信，即安全的网络通信保障机制。PKI技术是信息安全技术的核心，也是电子商务的关键和基础技术。一个典型的PKI系统包括PKI策略、软硬件系统、证书机构CA、注册机构RA、证书发布系统和PKI应用等。

1.1 PKI安全策略

建立和定义了一个组织信息安全方面的指导方针，同时也定义了密码系统使用的处理方法和原则。它包括一个组织怎样处理密钥和有价值的信息，根据风险的级别定义安全控制的级别。

1.2 证书机构CA

证书机构CA（Certificate Authority）：是PKI的信任基础，它管理公钥的整个生命周期，是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。其作用包括：发放证书、规定证书的有效期和通过发布证书废除列表(CRL)确保必要时可以废除证书。

目前全球主流的CA机构有Comodo科摩多、Symantec赛门铁克、GeoTrust、DigiCert、Thawte、GlobalSign、RapidSSL等，其中Symantec、GeoTrust都是DigiCert机构的子公司，目前市场上主流的ssl证书品牌是Comodo证书、Symantec证书、GeoTrust证书、Thawte证书和RapidSSL证书，还有一些不知名的证书机构也是可以颁发数字证书的。

1.3 注册机构RA

注册机构RA：提供用户和CA之间的一个接口，获取并认证用户的身份，向CA提出证书请求。它主要完成收集用户信息和确认用户身份的功能。这里指的用户，是指将要向认证中心(即CA)申请数字证书的客户，可以是个人，也可以是集团或团体、某政府机构等。注册管理一般由一个独立的注册机构(即RA)来承担。它接受用户的注册申请，审查用户的申请资格，并决定是否同意CA给其签发数字证书。注册机构并不给用户签发证书，而只是对用户进行资格审查。因此，RA可以设置在直接面对客户的业务部门，如银行的营业部、机构认识部门等。当然，对于一个规模较小的PKI应用系统来说，可把注册管理的职能由认证中心CA来完成，而不设立独立运行的RA。但这并不是取消了PKI的注册功能，而只是将其作为CA的一项功能而已。PKI国际标准推荐由一个独立的RA来完成注册管理的任务，可以增强应用系统的安全。

1.4 证书发布系统

证书发布系统负责证书的发放，如可以通过用户自己，或是通过目录服务器发放。目录服务器可以是一个组织中现存的，也可以是PKI方案中提供的。

1.5 PKI的应用

PKI的应用非常广泛，包括应用在web服务器和浏览器之间的通信、安全电子邮件、电子数据交换(EDI)、**在Internet上的信用卡交易和虚拟私有网(VPN)**等。

2. 数字签名

2.1 数字签名生成、验证

数字签名是邮件、文件或其它数字编码信息的发件人将他们的身份与信息绑定在一起(即为信息提供签名)的方法。

它的作用跟手写签名其实是类似的，用来证明某个消息或者文件是本人发出/认同的。

• 数字签名的生成：
  • 对于要传输的消息原文使用hash算法生成消息摘要MD，
  • 发送方使用自己的私钥 PVA，采用非对称加密算法—RSA，对数字摘要MD进行加密，即得数字签名DS。
  • 发方A用对称加密算法—DES的对称密钥SK对原文信息、数字签名DS及发方A证书的公钥PBA进行加密，得加密信息E
  • 发方A用收方B的公钥PBB，采用RSA算法对对称密钥SK加密，形成数字信封DE，就好像将对称密钥SK装到了一个用收方公钥加密的信封里；
• 数字证书的传输：
  • 发方A将加密信息E和数字信封DE一起发送给收方B；
• 数字签名的验证：
  • 收方B接受到数字信封DE后，首先用收方B的私钥PVB解密数字信封，取出对称密钥SK；
  • 收方B用对称密钥SK通过DES算法解密加密信息E，还原出原文信息、数字签名DS及发方A证书的公钥PBA；
  • 接收方对签名使用发送方的公钥解密还原摘要，
  • 并对得到的原文进行相同的hash算法计算出消息摘要，
  • 如果二者相等，说明数据没有被篡改，是保密传输的，签名是真实的；否则拒绝该签名。可以保证消息的完整性和抗否认性。

1. 用发送方私钥生成数字签名、用发送方公钥解密，可以证明消息确实是由公钥拥有者发出的。
2. 两份摘要的比对结果，可以证明消息在传输的过程中是否被改动。

2.2 数字签名分类

attach签名、detach签名、裸签名的区别是什么?

• Attach签名：数据原文、签名算法、签名数据、签名证书、 封装成签名结果，在进行签名验证的时候，直接将签名结果提交到服务器上进行验证就可以了

• detach签名：签名算法、签名数据、签名证书 封装成签名结果，在进行签名验证的时候，需要将数据原文和签名结果一并传入到服务器中进行验证即可

• RAW签名（裸签名）：将签名数据封装成签名结果，在进行签名验证的时候，需要将数据原文、签名算法、签名证书和签名结果一起提交到服务器进行验证。

3. 数字证书

数字签名要发挥作用，首先需要接收方获取发送方的公钥。如何证明获取的公钥确实是发送方的公钥而不是假冒的呢？数字证书提供了一种发布公钥的简便方法。所谓证书，其实是对公钥的封装，在公钥的基础上添加颁发者、有效期等信息。

• 数字证书的生成：CA收到数字证书申请并认证申请者的真实身份后，把申请者的公钥、身份信息、数字证书的有效期等信息作为消息原文，进行hash生成摘要，并用CA的私钥加密进行签名；数字签名与证书拥有者的公钥、身份信息、证书有效期等其他信息共同组成数字证书。
• 数字证书的验证：数字证书生成后，经历上图中3、4、5的传输过程，来到接收方。接收方收到消息证书后，使用CA公钥对数字签名解密生成消息摘要，对证书内容进行hash生成摘要，两份摘要进行比对可证明证书内容的完整性与真实性。

1. 使用CA私钥进行签名和解密，可以证明证书确实是由CA发布的；
2. 两份摘要的对比结果，可以证明证书内容是否在传输过程中被改动；
3. 如果消息原文中的公钥和身份信息是CA的，则是CA自签名的过程。

3.1 通信过程

数字证书提供了一种发布公钥的简便途径，大家通过向CA申请认证发布自己的公钥，通过向CA验证来确认自己获得了别人的公钥。下图展示了通信双方互相获得公钥以后的通信过程。

• 发送方对要传输消息原文进行hash，生成消息摘要，用发送方的私钥生成数字签名；
• 随机生成对称秘钥，对原文加密，生成密文；
• 用接收方公钥加密对称秘钥；
• 将加密后的对称秘钥、数字签名与密文一通发送；
• 接收方收到后，用自己的私钥解密对称秘钥；
• 用对称秘钥解密密文，得到原文；
• 对原文hash得到摘要，用发送方的公钥解密签名得到摘要，对方两份摘要。

非对称加密安全性高，但计算量大效率低，因此使用对称秘钥对通信的主要内容进行加密；对称秘钥每次使用随机生成，用完即丢弃，降低风险；

用接收方公钥加密对称秘钥，保证了只有接收方才能对密文进行解密；

用发送1方私钥进行签名，使得接收方可以验证消息的发送方和消息是否被修改过，保证了信息的完整性和抗否认性。

3.2 证书申请过程

• 用户申请：用户获取CA的数字证书（根证书），与安全服务器建立连接；生成自己的公钥和私钥，将公钥和自己的身份信息提交给安全服务器，安全服务器将用户的申请信息传送给RA服务器。
• RA审核：RA收到用户的申请，用户向RA证明自己的身份，RA进行核对。如果RA同意用户申请证书的请求，则对证书申请信息做数字签名；否则拒绝用户的申请。
• CA发行证书：RA将用户申请和RA签名传输给CA，CA对RA数字签名做认证，如果验证通过，则同意用户请求，颁发证书，然后将证书输出。如果验证不通过，则拒绝证书申请。
• RA转发证书：RA从CA得到新的证书，首先将证书输出到LDAP服务器以提供目录浏览，再通知用户证书发行成功，告知证书序列号，到指定的网址去下载证书。
• 用户证书获取：用户使用证书序列号去指定网址下载自己的数字证书，只有持有与申请时提交的公钥配对的私钥才能下载成功。

3.3 证书撤销过程

• 用户申请：用户向RA发送一封签名加密邮件，申请撤销证书。
• RA审核：注册机构同意证书撤销，并对申请签名。
• CA更新CRL：CA验证证书撤销请求的RA签名，如果正确，则同意申请，并更新CRL，并输出。
• RA转发CRL：注册中心收到CRL，以多种方式将CRL公布（包括LDAP服务器）。
• 用户告知：用户访问LDAP服务器，下载或浏览CRL。

3.4 证书的管理

认证中心CA负责维护和发布证书废除列表CRL（certificate revocation lists，又称为证书黑名单）。

当一个证书，特别是其中的公钥因为其他原因无效时（不是因为到期），CRL提供了一种通知用户和其他应用的中心管理方式。CA系统生成CRL以后，放到LDAP服务器中或Web服务器的合适位置，供用户查询或下载。

3.5 证书的结构

X.509标准：数字证书标准，规定了证书可以包含什么信息，并说明了记录信息的方法（数据格式）。

基本部分

1. 版本号
   识别用于该证书的 X.509 标准的版本，这可以影响证书中所能指定的信息。迄今为止，已定义的版本有三个（版本1、版本2或是版本3）。
2. 序列号
   标识证书的唯一整数，由证书颁发者分配的本证书的唯一标识符。发放证书的实体有责任为证书指定序列号，以使其区别于该实体发放的其它证书。此信息用途很多。例如，如果某一证书被撤消，其序列号将放到证书撤消清单 (CRL) 中。
3. 签名算法标识符
   用于识别 CA 签写证书时所用的算法。由对象标识符加上相关的参数组成，用于说明本证书所用的数字签名算法。
4. 颁发者
   签写证书的实体的 X.500 名称。它通常为一个 CA。 使用该证书意味着信任签写该证书的实体（注意：有些情况下（例如根或顶层 CA 证书），签发人会签写自己的证书）。
5. 有效期
   每个证书均只能在一个有限的时间段内有效。该有效期以起始日期和时间及终止日期和时间表示，可以短至几秒或长至一世纪。所选有效期取决于许多因素，例如用于签写证书的私钥的使用频率及愿为证书支付的金钱等。它是在没有危及相关私钥的条件下，实体可以依赖公钥值的预计时间。
6. 主体名/使用者
   证书可以识别其公钥的实体名。这个字段必须是非空的，除非你在证书扩展中有别名。此名称使用 X.500 标准，因此在Internet中应是唯一的。它是实体的特征名 (DN)，例如，
   CN=Java Duke，OU=Java Software Division，O=Sun Microsystems Inc，C=US（这些指主体的通用名、组织单位、组织和国家）。
7. 主体公钥信息
   这是被命名实体的公钥，同时包括指定该密钥所属公钥密码系统的算法标识符及所有相关的密钥参数。
8. 颁发者唯一标识符
   标识符—证书颁发者的唯一标识符，仅在版本2和版本3中有要求，属于可选项。
9. 主体唯一标识符
   证书拥有者的唯一标识符，仅在版本2和版本3中有要求，属于可选项。

扩展部分

1. 发行者密钥标识符
   证书所含密钥的唯一标识符，用来区分同一证书拥有者的多对密钥

2. 密钥使用

一个比特串，指明（限定）证书的公钥可以完成的功能或服务，如：证书签名、数据加密等。如果某一证书将 KeyUsage 扩展标记为“极重要”，而且设置为“keyCertSign”，则在 SSL 通信期间该证书出现时将被拒绝，因为该证书扩展表示相关私钥应只用于签写证书，而不应该用于 SSL。

3. CRL分布点

指明CRL的分布地点。

4. 私钥的使用期

指明证书中与公钥相联系的私钥的使用期限，它也有Not Before和Not After组成。若此项不存在时，公私钥的使用期是一样的。

5. 证书策略

由对象标识符和限定符组成，这些对象标识符说明证书的颁发和使用策略有关。

6. 策略映射

表明两个CA域之间的一个或多个策略对象标识符的等价关系，仅在CA证书里存在。

7. 主体别名

指出证书拥有者的别名，如电子邮件地址、IP地址等，别名是和DN绑定在一起的。

8. 颁发者别名

指出证书颁发者的别名，如电子邮件地址、IP地址等，但颁发者的DN必须出现在证书的颁发者字段。

9. 主体目录属性

指出证书拥有者的一系列属性。可以使用这一项来传递访问控制信息。

3.6 证书链和黑名单

3.6.1 证书链

证书链是一个有序的证书列表，包含SSL证书和CA证书，使接收方能够验证发送方和所有CA是否值得信任。链或路径以SSL证书开头，链中的每个证书都由链中下一个证书标识的实体签名。

链终止于根CA证书。必须验证链中所有证书的签名，直至根CA证书。根CA证书始终由CA本身签名。

最终的目的就是为了保证 end-user 证书是可信的，该证书的公钥也就是可信的。

从下往上介绍依次有

• 根证书：根证书（Root Certificate）的签名（Root CA’s signature）是用根私钥（Root CA‘s private key）签的。所以验证根证书签名（Root CA’s signature）要用根公钥（Root CA’s public key）才能验证通过。这种情况就叫做自签名（self-sign）。负责认证 intermediates 身份的合法性。

• 中介证书： 中介证书（Intermediate Certificate）里面包含了根证书的名称（Issuer’s /root CA’s name）。中介证书里面的签名（Issuer’s signature）是用根私钥（Root CA‘s private key）签的，所以需要根公钥（Root CA’s public key）才能验证通过。负责确认 HTTPS 使用的 end-user 证书来源。这类 intermediates 证书可以有很多级，也就是说 签发人 Issuer 可能会有有很多级。

• 终端实体证书：终端实体证书（End-entity Certificate）里面包含了中介证书的名称（Issuer’s / CA’s name）。终端实体证书里面的签名（Issuer’s signature）是用中介私钥（Owner‘s private key）签的，所以需要中介公钥（Owner’s public key）才能验证通过。该证书包含终端实体的公钥，访问者就是使用该公钥将数据加密后再传输给终端实体，即在 HTTPS 中使用的证书。

结合实际的使用场景对证书链进行一个归纳：

1. 为了获取 end-user 的公钥，需要获取 end-user 的证书，因为公钥就保存在该证书中；
2. 为了证明获取到的 end-user 证书是可信的，就要看该证书是否被 intermediate 权威机构认证，等价于是否有权威机构的数字签名；
3. 有了权威机构的数字签名，而权威机构就是可信的吗？需要继续往上验证，即查看是否存在上一级权威认证机构的数字签名；
4. 信任链条的最终是Root CA，他采用自签名，对Root CA的签名只能无条件的信任。

3.6.2 黑名单

黑名单就是拉黑即不再信任了。

4. PKI/CA架构

完整的PKI/CA系统如下部分：

• 安全服务器：安全服务器面向普通用户，用于提供证书申请、浏览、证书撤销列表、证书下载等安全服务；用户需要首先得到安全服务器的证书（该证书由CA颁发）
• 注册机构RA：在CA体系结构中起承上启下的作用，一方面向CA转发安全服务器传输过来的证书申请请求，另一方面向LDAP服务器和安全服务器转发CA颁发的数字证书和证书撤销列表（CRL）。
• LDAP服务器：Lightweight Directory Access Protocol（轻量目录访问协议），提供目录浏览服务，负责将注册机构服务器RA传输过来的用户信息以及数字证书加入到服务器上。用户通过访问LDAP服务器就能够得到其他用户的数字证书。
• CA服务器：整个证书机构的核心，负责证书的签发。CA首先产生自身的私钥和公钥，然后生成数字证书，并且将数字正常传输给安全服务器。CA还负责为安全服务器、RA服务器生成数字证书。
• 数据库服务器：CA中的核心部分，用于CA中数据（如密钥和用户信息等）、日志、统计信息的存储和管理。