PKI（HTTPS）体系详解

PKI（HTTPS）体系详解
PKI是什么
百度百科:
PKI是Public Key Infrastructure的⾸字母缩写，翻译过来就是公钥基础设施；PKI是⼀种遵循标准的利⽤公钥加密技术为电⼦商务的开展提供⼀套安全基础平台的技术和规范。

X.509标准中，为了区别于权限管理基础设施(Privilege Management Infrastructure，简称PMI)，将PKI定义为⽀持公开密钥管理并能⽀持认证、加密、完整性和可追究性服务的基础设施]。

这个概念与第⼀个概念相⽐，不仅仅叙述PKI能提供的安全服务，更强调PKI必须⽀持公开密钥的管理。

也就是说，仅仅使⽤公钥技术还不能叫做PKI，还应该提供公开密钥的管理。

因为PMI仅仅使⽤公钥技术但并不管理公开密钥，所以，PMI就可以单独进⾏描述了⽽不⾄于跟公钥证书等概念混淆。

X.509中从概念上分清PKI和PMI有利于标准的叙述。

然⽽，由于PMI使⽤了公钥技术，PMI的使⽤和建⽴必须先有PKI的密钥管理⽀持。

也就是说，PMI不得不把⾃⼰与PKI绑定在⼀起。

当我们把两者合⼆为⼀时，PMI+PKI就完全落在X.509标准定义的PKI范畴内。

根据X.509的定义，PMI+PKI仍旧可以叫做PKI，⽽PMI完全可以看成PKI的⼀个部分。

PKI 既不是⼀个协议，也不是⼀个软件，它是⼀个标准，在这个标准之下发展出的为了实现安全基础服务⽬的的技术统称为 PKI。

PKI的组成部分
百度百科:
PKI（Public Key Infrastructure）公钥基础设施是提供公钥加密和数字签名服务的系统或平台，⽬的是为了管理密钥和证书。

⼀个机构通过采⽤PKI 框架管理密钥和证书可以建⽴⼀个安全的⽹络环境。

PKI 主要包括四个部分：X.509 格式的证书（X.509 V3）和证书废⽌列表CRL（X.509 V2）；CA 操作协议；CA 管理协议；CA 政策制定。

⼀个典型、完整、有效的PKI 应⽤系统⾄少应具有以下五个部分:
1）认证中⼼CA CA 是PKI 的核⼼，CA负责管理PKI 结构下的所有⽤户（包括各种应⽤程序）的证书，把⽤户的公钥和⽤户的其他信息捆绑在⼀起，在⽹上验证⽤户的⾝份，CA 还要负责⽤户证书的⿊名单登记和⿊名单发布，后⾯有CA 的详细描述。

2） X.500 ⽬录服务器 X.500 ⽬录服务器⽤于发布⽤户的证书和⿊名单信息，⽤户可通过标准的LDAP 协议查询⾃⼰或其他⼈的证书和下载⿊名单信息。

3）具有⾼强度密码算法(SSL) 的安全WWW服务器 Secure socket layer(SSL)协议最初由Netscape 企业发展，现已成为⽹络⽤来鉴别⽹站和⽹页浏览者⾝份，以及在浏览器使⽤者及⽹页服务器之间进⾏加密通讯的全球化标准。

4） Web（安全通信平台） Web 有Web Client 端和Web Server 端两部分，分别安装在客户端和服务器端，通过具有⾼强度密码算法的SSL协议保证客户端和服务器端数据的机密性、完整性、⾝份验证。

5）⾃开发安全应⽤系统⾃开发安全应⽤系统是指各⾏业⾃开发的各种具体应⽤系统，例如银⾏、证券的应⽤系统等。

完整的PKI 包括认证政策的制定（包括遵循的技术标准、各CA 之间的上下级或同级关系、安全策略、安全程度、服务对象、管理原则和框架等）、认证规则、运作制度的制定、所涉及的各⽅法律关系内容以及技术的实现等。

作为WEB开发者其实只需要关注pki组成部分中的后三部分,⾼强度密码算法SSL⽬前已经包含在https中,下⾯对https有专门的讲解；web安全通信平台可以理解为我们的浏览器和服务器,即可以建⽴https连接的两个端点；⾃开发安全应⽤系统即是我们开发的⽀持pki验证的系统。

HTTPS 详解
HTTP VS HTTPS
使⽤HTTP有以下风险:
1. 窃听风险（eavesdropping）: 通信使⽤明⽂（不加密），内容可能会被窃听
2. 篡改风险（tampering）：不验证通信⽅的⾝份，因此有可能遭遇伪装
3. 冒充风险（pretending）：⽆法证明报⽂的完整性，所以有可能已遭篡改
当然,相对于HTTPS的安全性更⾼,HTTP也有⾃⼰的优势,即性能更好。

简单来说,HTTPS⽐HTTP增加了SSL握⼿和对于传输数据加密解密的过程,握⼿部分的耗时差不多为建⽴TCP连接耗时的3倍到6倍(取决于数字证书的加密强度),另外对于传输数据的加密解密也会占⽤设备⼀部分的性能。

HTTPS/HTTP的区别和联系
HTTPS = HTTP+SSL / TLS
对称加密和⾮对称加密
对称加密
所谓的“对称加密技术”，意思就是说：“加密”和“解密”使⽤相同的密钥。

就好⽐⽤ 7zip 或 WinRAR 创建⼀个带密码（⼝令）的加密压缩包。

当你下次要把这个压缩⽂件解开的时候，你需要输⼊同样的密码。

在这个例⼦中，密码/⼝令就如同刚才说的“密钥”。

缺陷:对称加密的密钥如何传输,第⼀次传输的时候肯定是明⽂,那么对称密钥还是会存在被窃取的风险,以及客户端如何确认服务端的⾝份。

对称加密经典算法：AES，DES，3DES，TDEA，Blowfish，RC5，IDEA。

⾮对称加密
百度百科
⾮对称加密算法需要两个密钥：公开密钥（public key）和私有密钥（private key）。

公开密钥与私有密钥是⼀对，如果⽤公开密钥对数据进⾏加密，只有⽤对应的私有密钥才能解密；如果⽤私有密钥对数据进⾏加密，那么只有⽤对应的公开密钥才能解密。

因为加密和解密使⽤的是两个不同的密钥，所以这种算法叫作⾮对称加密算法。

⾮对称加密算法实现机密信息交换的基本过程是：甲⽅⽣成⼀对密钥并将其中的⼀把作为公⽤密钥向其它⽅公开；得到该公⽤密钥的⼄⽅使⽤该密钥对机密信息进⾏加密后再发送给甲⽅；甲⽅再⽤⾃⼰保存的另⼀把专⽤密钥对加密后的信息进⾏解密。

另⼀⽅⾯，甲⽅可以使⽤⼄⽅的公钥对机密信息进⾏签名后再发送给⼄⽅；甲⽅再⽤⾃⼰的私匙对⼄⽅发送回来的数据进⾏验签。

⾮对称加密经典算法：RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）。

缺陷:⾮对称加密可以解决对称加密被窃取的问题,但依然⽆法验证服务器的⾝份信息。

⾮对称加密被劫持情况
对称加密和⾮对称加密算法效率对⽐
对称加密(AES):
1. AES加密的时间与被加密⽂件的⼤⼩正线性增长，加密1G的⽂件⼤概需要4分多钟，加密速度较快。

2. 加密后的⽂件⼤⼩是原始⽂件⼤⼩的两倍。

3. 解密⽂件所需时间是加密时间的两倍（这个应该是加密⽂件是原始⽂件⼤⼩两倍造成的）。

⾮对称加密(RSA):
1. RSA加密算法加密时间很短，基本可以忽略不计。

但是，在解密时，RSA显的⽐较慢，解密时间与解密⽂件的⼤⼩呈现线性增长趋势。

加密1M的⽂件⼤概需要5秒，但是
解密却需要4分钟。

2. 加密后的⽂件与原始⽂件的⼤⼩基本相同。

3. 解密的效率远低于加密效率，按照这个时间去计算，加密1G的⽂件需要1分钟，但是解密却需要65⼩时。

CA 认证
⽆论是对称加密还是⾮对称加密,都遗留了⼀个问题没有解决,那就是如何证明我们访问的⽹站就是我们要访问的⽹站,⽽不是他⼈伪造的,即中间⼈攻击和信息抵赖的问题,这⾥就⽤到了CA证书。

百度百科
CA认证，即电⼦认证服务，是指为电⼦签名相关各⽅提供真实性、可靠性验证的活动。

证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。

是负责发放和管理数字证书的权威机构，并作为电⼦商务交易中受信任的第三⽅，承担公钥体系中公钥的合法性检验的责任。

CA中⼼为每个使⽤公开密钥的⽤户发放⼀个数字证书，数字证书的作⽤是证明证书中列出的⽤户合法拥有证书中列出的公开密钥。

CA机构的数字签名使得攻击者不能伪造和篡改证书。

在SET交易中，CA不仅对持卡⼈、商户发放证书，还要对获款的银⾏、⽹关发放证书。

CA是证书的签发机构,它是PKI的核⼼。

CA是负责签发证书、认证证书、管理已颁发证书的机关。

它要制定政策和具体步骤来验证、识别⽤户⾝份，并对⽤户证书进⾏签名，以确保证书持有者的⾝份和公钥的拥有权。

CA 也拥有⼀个证书（内含公钥）和私钥。

⽹上的公众⽤户通过验证 CA 的签字从⽽信任 CA ，任何⼈都可以得到 CA的证书（含公钥），⽤以验证它所签发的证书。

如果⽤户想得到⼀份属于⾃⼰的证书，他应先向 CA 提出申请。

在 CA 判明申请者的⾝份后，便为他分配⼀个公钥，并且 CA 将该公钥与申请者的⾝份信息绑在⼀起，并为之签字后，便形成证书发给申请者。

如果⼀个⽤户想鉴别另⼀个证书的真伪，他就⽤ CA 的公钥对那个证书上的签字进⾏验证，⼀旦验证通过，该证书就被认为是有效的。

为保证⽤户之间在⽹上传递信息的安全性、真实性、可靠性、完整性和不可抵赖性，不仅需要对⽤户的⾝份真实性进⾏验证，也需要有⼀个具有权威性、公正性、唯⼀性的机构，负责向电⼦商务的各个主体颁发并管理符合国内、国际安全电⼦交易协议标准的电⼦商务安全证，并负责管理所有参与⽹上交易的个体所需的数字证书，因此是安全电⼦交易的核⼼环节。

解决上述⾝份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的⾝份信息，为此需要引⼊权威的第三⽅机构CA(如沃通CA)。

CA 负责核实公钥的拥有者的信息，并颁发认证"证书"，同时能够为使⽤者提供证书验证服务，即PKI体系(PKI基础知识)。

基本的原理为，CA负责审核信息，然后对关键信息利⽤私钥进⾏"签名"，公开对应的公钥，客户端可以利⽤公钥验证签名。

CA也可以吊销已经签发的证书，基本的⽅式包括两类 CRL ⽂件和 OCSP。

CA使⽤具体的流程如下：
1. 服务⽅S向第三⽅机构CA提交公钥、组织信息、个⼈信息(域名)等信息并申请认证;
2. CA通过线上、线下等多种⼿段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
3. 如信息审核通过，CA会向申请者签发认证⽂件-证书。

证书包含以下信息：申请者公钥、申请者的组织信息和个⼈信息、签发机构CA的信息、有效时间、证书序列号等信息的明⽂，同时包含⼀个签名;
签名的产⽣算法：⾸先，使⽤散列函数计算公开的明⽂信息的信息摘要，然后，采⽤CA的私钥对信息摘要进⾏加密，密⽂即签名;
4. 客户端 C 向服务器 S 发出请求时，S 返回证书⽂件;
5. 客户端 C 读取证书中的相关的明⽂信息，采⽤相同的散列函数计算得到信息摘要，然后，利⽤对应CA的公钥解密签名数据，对⽐证书的信息摘要，如果⼀致，则可以确认证书的合法性，即公钥合法;
6. 客户端然后验证证书相关的域名信息、有效时间等信息;
7. 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定⾮法。

8. 在这个过程注意⼏点：
a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握;
b.证书的合法性仍然依赖于⾮对称加密算法，证书主要是增加了服务器信息以及签名;
c.内置 CA 对应的证书称为根证书，颁发者和使⽤者相同，⾃⼰为⾃⼰签名，即⾃签名证书（为什么说"部署⾃签SSL证书⾮常不安全"）
d.证书=公钥+申请者与颁发者信息+签名;
即便有⼈截取服务器证书，再发给客户端，想冒充服务器，也⽆法实现。

因为证书和url的域名是绑定的。

免费获取CA证书的⼏种⽅式
1. 从相关商业机构申请，以阿⾥云为例:
2. 使⽤证书⼯具⽣成(Keytool或者Openssl): 详见实操部分
SSL/TLS的联系与区别
SSL/TLS的背景
1994年，NetScape 公司设计了 SSL 协议的1.0版，但是未发布。

1995年，NetScape 公司发布 SSL 2.0版，很快发现有严重漏洞。

1996年，SSL 3.0 版问世，得到⼤规模应⽤。

1999年，互联⽹标准化组织 ISOC 接替 NetScape 公司，发布了 SSL 的升级版 TLS 1.0 版。

2006年和2008年，TLS 进⾏了两次升级，分别为 TLS 1.1 版和 TLS 1.2 版。

最新的变动是2011年 TLS 1.2的修订版。

对于⼆者的关系,可以说是同⼀事物在不同时期的表现。

TLS 1.0通常被标⽰为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2 为SSL 3.3。

SSL（Secure Socket Layer，安全套接字层）
SSL协议位于TCP/IP协议与各种应⽤层协议之间，为数据通讯提供安全⽀持。

SSL协议可分为两层，SSL记录协议层（SSL Record Protocol）：它建⽴在可靠的传输协议（如TCP）之上，为⾼层协议提供数据封装、压缩、加密等基本功能的⽀持。

SSL握⼿协议层（SSL Handshake Protocol）：它建⽴在SSL记录协议之上，⽤于在实际的数据传输开始前，通讯双⽅进⾏⾝份认证、协商加密算法、交换加密密钥等。

SSL协议提供的服务主要有：
1）认证⽤户和服务器，确保数据发送到正确的客户机和服务器；
2）加密数据以防⽌数据中途被窃取；
3）维护数据的完整性，确保数据在传输过程中不被改变。

SSL协议的握⼿流程：
以上⼯作流程分为五步:
第⼀步，爱丽丝给出协议版本号、⼀个客户端⽣成的随机数1（Client random），以及客户端⽀持的加密⽅法。

第⼆步，鲍勃确认双⽅使⽤的加密⽅法，并给出数字证书、以及⼀个服务器⽣成的随机数2（Server random）。

第三步，爱丽丝确认数字证书有效，然后⽣成⼀个新的随机数3（Premaster secret），并使⽤数字证书中的公钥，
加密这个随机数，发给鲍勃。

同时依据三个随机数根据指定算法⽣成对称密钥。

另如果开启了双向认证,那么在这⼀步客户端会将⾃⼰的证书的发送给服务器。

第四步，鲍勃使⽤⾃⼰的私钥，获取爱丽丝发来的随机数（即Premaster secret）。

服务器开始根据约定的加密⽅
法，使⽤前⾯的三个随机数，⽣成"对话密钥"（session key），⽤来加密接下来的整个对话过程。

第五步，爱丽丝和鲍勃⽤对话密钥将对话加密后开始传输。

TLS（Transport Layer Security Protocol，传输层安全协议）
是IETE（⼯程任务组）指定的⼀种新的协议，它建⽴在SSL 3.0协议规范之上，是SSL 3.0的后续版本,也⽤于在两个通信应⽤程序之间提供保密性和数据完整性。

该协议也由两部分组成：TLS记录协议（TLS Record）和TLS握⼿协议（TLS Handshake）。

TLS与SSL的差异:
1）版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使⽤的版本号为SSLv3.1。

2）报⽂鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。

TLS使⽤RFC-2104定义的HMAC算法。

SSLv3.0使⽤了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采⽤的是连接运算，⽽HMAC算法采⽤的异或运算。

但是两者的安全程度是相同的。

3）伪随机函数：TLS使⽤了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的⽅式。

4）报警代码：TLS⽀持⼏乎所有的SSLv3.0报警代码，⽽且TLS还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知
CA（unknown_ca）、拒绝访问（access_denied）等。

5）密⽂族和客户证书：SSLv3.0和TLS存在少量差别，即TLS不⽀持Fortezza密钥交换、加密算法和客户证书。

6）certificate_verify和finished消息：SSLv3.0和TLS在⽤certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输⼊有少许差别，但安全性相当。

7）加密计算：TLS和SSLv3.0在计算主密值（master secret）时采⽤的⽅式不同。

8）填充：⽤户数据加密之前需要增加的填充字节。

在SSL中，填充后的数据长度哟啊达到密⽂快长度的最⼩整数倍。

⽽在TLS中，填充后的数据长度可以是密⽂块长度的任意整数倍（但填充的最⼤长度为255字节），这种⽅式可以防⽌基于对报⽂长度进⾏分析的攻击。

TLS的主要增强内容:
TLS的主要⽬标是使SSL更安全，并使协议的规范更精确和完善。

TLS在SSL v3.0的基础上，提供了以下增加内容：
1）更安全的MAC算法
2）更严密的警报
3）“灰⾊区域”规范的更明确的定义
TLS对于安全性的改进:
1）对于消息认证使⽤密钥散列法：TLS使⽤“消息认证代码的密钥散列法”（HMAC），当记录在开放的⽹络（如因特⽹）上传送时，该代码确保记录不会被变更。

SSLv3.0还提供键控消息认证，但HMAC⽐SSLv3.0使⽤（消息认证代码）MAC功能更安全。

2）增强的伪随机功能（PRF）：PRF⽣成密钥数据。

在TLS中，HMAC定义PRF。

PRF使⽤两种散列算法保证其安全性。

如果任⼀算法暴露了，只要第⼆种算法未暴露，则数据仍然是安全的。

3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。

然⽽，TLS将此已完成消息基于PRF和HMAC值之上，这也⽐SSLv3.0更安全。

4）⼀致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。

5）特定警报消息：TLS提供更多的特定和附加警报，以指⽰任⼀会话端点检测到的问题。

TLS还对何时应该发送某些警报进⾏记录。

综上所述,SSL和TLS 没有本质区别,⼆者的⼯作流程基本⼀致,只是TLS在SSL的基础上对于安全性做了⼀些增强。

双向认证和单向认证
单向认证是指客户端根据服务器传过来的证书信息校验服务器的合法性,上⽂的SSL握⼿流程就是单向认证。

服务器的合法性包括：
1.证书是否过期。

2.发⾏服务器证书的CA是否可靠。

3.发⾏者证书的公钥能否正确解开服务器证书的"发⾏者的数字签名"。

4.服务器证书上的域名是否和服务器的实际域名相匹配。

如果合法性验证没有通过,则浏览器会给⽤户⼀个警告提⽰访问⽹站不安全,让⽤户选择是继续访问还是终⽌访问。

服务器合法性通过,以淘宝为例:
服务器合法性校验不通过,原因是这个证书是⾃⼰签发,CA不受信:
双向认证是在单向认证的基础上,增加了⼀步服务器校验客户端证书的动作,这⼀步骤存在于SSL握⼿流程的第三步。

⼀般在对⽤户⾝份信息⽐较敏感的⽹站上会使⽤,⽐如银⾏系统的U盾,以及此次龙湾项⽬的PKI登陆。

如果服务器校验客户端证书成功,则正常访问,如果失败,浏览器则会直接提⽰⽆法访问该⽹站。

服务器获取客户端证书:
服务器校验客户端证书失败(服务器开启了强制校验,没有证书或者证书不符合):
服务器证书和客户端证书的区别与联系
服务器证书和客户端证书没有本质区别,都是⼀个包含公钥和私钥的⽂件。

但是并不建议⼆者交换使⽤,在上⽂的单向认证中的服务器合法性中会校验服务器证书上的域名和服务器的实际域名是否相匹配,⽽这个域名信息是服务器证书⾥⾯独有的,客户端证书中独有的信息是则是⽤户⾝份信息,如果⼆者交换使⽤,浏览器会提⽰服务器证书域名不匹配,那么该服务器证书则会不受信,也就失去了使⽤服务器证书的意义。

服务器证书和客户端证书如何建⽴信任关系
在了解这个问题过程中我曾经进⼊⼀个误区,以为服务器校验客户端证书是依赖于将每⼀个客户端证书的公钥导⼊服务器证书的证书库(即服务器证书⽂件)中。

⽽实际上服务器校验客户端证书是否合法是取决于服务器证书是否信任客户端证书的证书链。

也可以理解为服务器证书信任颁发客户端证书的CA。

在操作层⾯这个建⽴这个信任关系也是将签发客户端证书的CA的公钥导⼊服务器证书,但从原理层⾯来说,相较于上⾯的误区,信任证书链的话只需要导⼊⼀次CA的公钥即可,⽽不⽤单独将每个客户端证书的公钥导⼊服务器证书。

我在开发过程中,甲⽅只给我⼀个服务器证书,并没有给客户端证书,为了模拟测试只能⾃⼰签发客户端证书,但⾃⼰签发的证书没有CA信息通过校验证书链肯定是不⾏的,这时候只能使⽤上⾯的导⼊客户端公钥的办法了,即先将⾃⼰⽣成的客户端证书中的公钥导出,然后将该公钥导⼊服务器证书中使服务器证书信任该公钥,这⼀点可以看后⾯的操作部分。

另外还有⼀点就是校验客户端证书时并没有做业务层⾯的判断,假如某CA签发了N个客户端证书,⽽服务器证书⼜信任这个CA的证书链,那么对于服务器证书来说,这些客户端证书是没有任何区别(因为都是受信的),如果想建⽴证书与⽤户之间的关系,还需要在代码层⾯来操作。

证书链
百度百科:
证书链(certificate chain)
证书链可以有任意环节的长度，所以在三节的链中，信任锚证书CA 环节可以对中间证书签名；中间证书的所有者可以⽤⾃⼰的私钥对另⼀个证书签名。

CertPath API 可以⽤来遍历证书链以验证有效性，也可以⽤来构造这些信任链。

Web 浏览器已预先配置了⼀组浏览器⾃动信任的根 CA 证书。

来⾃其他证书授权机构的所有证书都必须附带证书链，以检验这些证书的有效性。

证书链是由⼀系列CA 证书发出的证书序列，最终以根 CA 证书结束。

证书最初⽣成时是⼀个⾃签名证书。

⾃签名证书是其签发者（签名者）与主题（其公共密钥由该证书进⾏验证的实体）相同的证书。

如果拥有者向 CA 发送证书签名请求 (CSR)，然后输⼊响应，⾃签名证书将被证书链替换。

链的底部是由 CA 发布的、⽤于验证主题的公共密钥的证书（回复）。

链中的下⼀个证书是验证 CA 的公共密钥的证书。

通常，这是⼀个⾃签名证书（即，来⾃ CA、⽤于验证其⾃⾝的公共密钥的证书）并且是链中的最后⼀个证书。

在其他情况下，CA 可能会返回⼀个证书链。

在此情况下，链的底部证书是相同的（由 CA 签发的证书，⽤于验证密钥条⽬的公共密钥），但是链中的第⼆个证书是由其他 CA 签发的证书，⽤于验证您向其发送了 CSR 的 CA 的公共密钥。

然后，链中的下⼀个证书是⽤于验证第⼆个 CA 的密钥的证书，依此类推，直⾄到达⾃签名的根证书。

因此，链中的每个证书（第⼀个证书之后的证书）都需要验证链中前⼀个证书的签名者的公共密钥。

Windows系统中的证书链:
服务器证书、中间证书与根证书在⼀起组合成⼀条合法的证书链，证书链的验证是⾃下⽽上的信任传递的过程。

⼆级证书结构存在的优势：
a.减少根证书结构的管理⼯作量，可以更⾼效的进⾏证书的审核与签发;
b.根证书⼀般内置在客户端中，私钥⼀般离线存储，⼀旦私钥泄露，则吊销过程⾮常困难，⽆法及时补救;
c.中间证书结构的私钥泄露，则可以快速在线吊销，并重新为⽤户签发新的证书;
d.证书链四级以内⼀般不会对 HTTPS 的性能造成明显影响。

证书链有以下特点：
a.同⼀本服务器证书可能存在多条合法的证书链。

因为证书的⽣成和验证基础是公钥和私钥对，如果采⽤相同的公钥和私钥⽣成不同的中间证书，针对被签发者⽽⾔，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;
b.不同证书链的层级不⼀定相同，可能⼆级、三级或四级证书链。

中间证书的签发机构可能是根证书机构也可能是另⼀个中间证书机构，所以证书链层级不⼀定相同。

证书格式
根据不同的服务器以及服务器的版本，我们需要⽤到不同的证书格式，就市⾯上主流的服务器来说，⼤概有以下格式：
DER/CER，⽂件是⼆进制格式，只保存证书，不保存私钥。

CRT，可以是⼆进制格式，可以是⽂本格式，与DER格式相同，不保存私钥。

PEM，⼀般是⽂本格式，可保存证书，可保存私钥。

PFX/P12，⼆进制格式，同时包含证书和私钥，⼀般有密码保护。

JKS，⼆进制格式，同时包含证书和私钥，⼀般有密码保护。

DER
该格式是⼆进制⽂件内容，Java 和 Windows 服务器偏向于使⽤这种编码格式。

OpenSSL 查看:
openssl x509 -in certificate.der -inform der -text -noout
转换为 PEM：
openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
PEM
Privacy Enhanced Mail，⼀般为⽂本格式，以-----BEGIN-----开头，以-----END-----结尾。

中间的内容是BASE64 编码。

这种格式可以保存证书和私钥，有时我们也把PEM 格式的私钥的后缀改为 .key 以区别证书与私钥。

具体你可以看⽂件的内容。

这种格式常⽤于 Apache和 Nginx服务器。

OpenSSL 查看：
openssl x509 -in certificate.pem -text -noout
转换为 DER：
openssl x509 -in cert.crt -outform der -out cert.der
CRT
Certificate 的简称，有可能是 PEM 编码格式，也有可能是 DER 编码格式。

如何查看请参考前两种格式。

PFX/P12
Predecessor of PKCS#12，这种格式是⼆进制格式，且证书和私钥存在⼀个 PFX ⽂件中。

⼀般⽤于 Windows上的 IIS 服务器,window上可以直接安装。

改格式的⽂件⼀般会有⼀个密码⽤于保证私钥的安全。

OpenSSL 查看：
openssl pkcs12 -in for-iis.pfx
转换为 PEM：
openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
JKS/KEYSOTRE/TRUSTSTORE
Java Key Storage，这是 JAVA的专属格式，利⽤ JAVA 的⼀个叫keytool的⼯具可以进⾏格式转换。

⼀般⽤于 Tomcat 服务器。

实操部分
⽣成证书
⾃⼰签发证书可以通过JDK⾃带的⼯具Keytool或者Linux上的openssl来进⾏,⼆者都很容易百度到相关资料,本⽂只对keytool⽅式进⾏简单讲解。

⽣成服务器证书
keytool -genkey -v -alias tomcat -keyalg RSA -keystore
F:\baidu\keystore\tomcat.keystore -validity 36500
-alias 证书别名,可选,任意,但建议取有意义的值
-keyalg ⽣成证书所使⽤的算法
-keystore ⽣成的证书⽂件保存位置
-validity 证书有效期,36500表⽰100年，默认值是90天
注意:
1. 名字与姓⽒即为服务器的域名或者ip,如果是合法机构签发的证书,域名或者ip匹配不上会提⽰不受信,虽然我们⾃⼰签发的证书本来就是不受信的,但还是建议这⾥填有意义的
域名或者ip。

2. 密钥库⼝令需要记住,⽆论是配置https还是向密钥库中添加信任的公钥时都会⽤到。

⽣成客户端证书
keytool -genkey -v -alias mykey -keyalg RSA -storetype PKCS12 -keystore
F:\baidu\keystore\client.key.p12
⽣成证书后在windows系统中可以直接双击⽂件进⾏安装。

让服务器信任客户端证书
将客户端证书导出为⼀个单独的CER⽂件。

keytool -export -alias mykey -keystore F:\baidu\keystore\client.key.p12 -storetype
PKCS12 -storepass password -rfc -file F:\baidu\keystore\client.key.cer
注：password为客户端证书的密码,即第⼀步⽣成服务器证书时的密钥库⼝令。

将CER⽂件导⼊到服务器的证书库。

让客户端信任服务器证书
把服务器证书导出为CER⽂件,在windows中可以直接双击安装.cer⽂件。

keytool -keystore F:\baidu\keystore\\tomcat.keystore -export -alias tomcat -file
F:\baidu\keystore\tomcat.cer
Windows 系统中查看已安装的证书
Win+R 打开运⾏窗⼝,输⼊certmgr.msc。