PKI与证书相关基本知识

1、PKI体系

PKI/CA与数字证书_J.D.的博客-CSDN博客_pki数字证书

PKI/CA与数字证书_J.D.的博客-CSDN博客_pki数字证书

PKI基础设施：CA，RA，KMC，CRL，OCSP用处

PKI组件：

1）认证中心-CA

作用：负责签发、管理和作废证书等操作

ps: 颁发证书使用CA的私钥对证书请求文件进行签名，颁发的证书浏览器要信任，浏览器 使用CA的公钥进行验签（浏览器要内置CA的公钥）

2）注册中心-RA

作用：建立证书持有者和证书之间的联系

3）证书库：　存储证书和证书作废表（CRL）.

4）证书验证软件：　验证证书合法性、有效性，如客户端验证程序、OCSP

5）证书持有者（Certificate Holder or EE）：人、设备、软件等等

6）安全策略：　设定企业最高层次的安全策略和安全方针，也包括密码系统的使用过程和原则。

7）密钥恢复服务：　KMC

为解决私钥的备份与恢复问题，PKI引入了KMC（Key Management Center）。

用户公私钥对由KMC产生，KMC对私钥做备份；公私钥也可由用户自己产生，并将私钥安全提交给KMC做备份。

8）时间服务：　时间服务器

9）签名服务：　签名验证服务器

• 信息的私密性(Privacy) ：----> 对称加密
• 信息的完整性(Integrity) ----> 数字签名
• 信息的源发鉴别(Authentication) ----> 数字签名
• 信息的防抵赖性(Non-Reputation) ----> 数字签名　＋　时间戳

1）关于数字证书

用户或系统只有拥有自己的公钥和私钥后，才能实现数字签名和加密解密功能，由于公钥是随机产生的，因此从公钥无法直接判断属于哪个用户。

为解决公钥与用户映射关系问题，PKI引入了数字证书。数字证书里包含了用户身份信息，用户公钥信息*（两者用于确定用户）和CA的私钥数字签名（使用CA的公钥可判断证书是否被篡改）*。

私钥一般被保存在硬件密码设备中（像U盾之类的）。

2）数字证书的管理

1、关于CA

为了解决数字证书的签发问题，PKI引入了CA（Certificate Authority）， 对数字证书进行集中签发。

它实际是一种特殊的公钥管理中心，对数字证书的全生命周期进行管理，包括：数字证书的签发和更新，数字证书的作废，冻结和解冻，查询或下载，状态查询等。

像广州CA，深圳CA就属于这类，可去他们的官网上进行相关了解。

2、关于KMC

为解决私钥的备份与恢复问题，PKI引入了KMC（Key Management Center）。

用户公私钥对由KMC产生，KMC对私钥做备份；公私钥也可由用户自己产生，并将私钥安全提交给KMC做备份。

3、关于双证书

为防止用户身份被冒用，应保证用户私钥的唯一性，不允许备份恢复；为防止公钥加密后的数据无法解密，应提供用户私钥的备份恢复机制。

为解决这两种矛盾需求，PKI引入了双证书机制：签名证书和加密证书。

签名证书的公私钥对由用户自己产生，KMC不备份私钥；加密证书密钥对由KMC产生，且KMC对加密私钥进行备份。

4、关于LDAP

为解决对CA证书的查询或下载的性能问题，PKI引入 LDAP（Light-weight Directory Access Protocol 轻量目录访问协议）技术。

DAP（Directory Access Protocol 目录访问协议）是对数据管理的读取功能进行特殊优化的技术，适合快速响应和大容量的查询服务，应用系统只需通过X.500协议就能对数据进行快速查询。但由于该协议过于复杂，国际组织对其进行简化，形成了LDAP标准。

5、关于CRL和OCSP

为解决对CA证书有效性方面的查询，PKI引入了CRL（Certificate Revocation List）和OCSP（Online Certificate Status Protocol） 技术。前者需要用户按时定期下载，可用于脱机使用；后者则可实时在线查询。

6、关于RA

为对用户提供 面对面 的证书业务服务，负责用户证书办理/作废申请，用户身份审核，制作证书并移交用户等功能。PKI引入了RA（Registry Authority）

7、关于电子认证服务机构

**为保证CA系统在数字证书管理方面的规范性、合规性和安全性，PKI引入了电子认证服务机构，**以第三方运营的方式对外提供数字证书相关服务。

3） 数字证书的应用

基于数字证书可实现四种基本安全功能：身份认证，保密性，完整性和抗抵赖性。

1、身份认证

如网络身份证。

2、保密性

如不泄露信用卡信息。

3、完整性

如已签订的合同不会被某一方私自修改。

4、抗抵赖性

如发生交易纠纷时，可通过验证对方的私钥签名来确认。

2、pkcs标准

PKCS是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。

到1999年底，PKCS已经公布了以下标准：

P1：RSA、raw签

P6：证书结构

P7：attach、detached签

P10：证书请求

P11：USBKey相关

P12：pfx

PKCS#1：定义RSA公开密钥算法加密和签名机制，主要用于组织PKCS#7中所描述的数字签名和数字信封。

PKCS#3：定义Diffie-Hellman密钥交换协议。

PKCS#5：描述一种利用从口令派生出来的安全密钥加密字符串的方法。使用MD2或MD5 从口令中派生密钥，并采用DES-CBC模式加密。主要用于加密从一个计算机传送到另一个计算机的私人密钥，不能用于加密消息。

PKCS#6：描述了公钥证书的标准语法，主要描述X.509证书的扩展格式。

PKCS#7：定义一种通用的消息语法，包括数字签名和加密等用于增强的加密机制，PKCS#7与PEM兼容，所以不需其他密码操作，就可以将加密的消息转换成PEM消息。

P7的结构-六种内容类型： Data内容类型 ----->明文信息 Data内容类型只是一字节串 Signed-data内容类型 ----->数字签名 由任意类型的内容和该内容的签名数据组成 Enveloped-data 内容类型 ----->数字信封 Signed-and-enveloped-data 内容类型 ----->带签名的数字信封 Digested-data内容类型 ----->信息摘要 Encrypted-data内容类型 ----->加密数据

PKCS#8：描述私有密钥信息格式，该信息包括公开密钥算法的私有密钥以及可选的属性集等。

PKCS#9：定义一些用于PKCS#6证书扩展、PKCS#7数字签名和PKCS#8私钥加密信息的属性类型。

PKCS#10：描述证书请求语法。

PKCS#11：称为Cyptoki，定义了一套独立于技术的程序设计接口，用于智能卡和PCMCIA卡之类的加密设备。

PKCS#12：描述个人信息交换语法标准。描述了将用户公钥、私钥、证书和其他相关信息打包的语法。

PKCS#13：椭圆曲线密码体制标准。

PKCS#14：伪随机数生成标准。

PKCS#15：密码令牌信息格式标准。

3、国标

中国自己的标准，GB/T xxxxxx

4、算法

1）RSA算法和国密算法

2）按密钥类型划分：对称，非对称

3）按用途划分：摘要算法，签名算法，加密算法

4）算法强度：根据破译难度等进行区分，弱算法会被淘汰或屏蔽

对称和非对称：速度、安全性、密钥是否相同等方面

1）对称加密算法

• 1. 介绍：加密和解密都使用同一种密钥，这把密钥可以加密明文，也可以解密加密后的密文，即加密密钥和解密密钥是相同或等价的
  2. 类型：DES、3DES、RC2、RC4、AES、SM1、SM4
  3. 特征：
  4. 优点：算法公开、计算量小、加密速度快、加密效率高。
  5. 缺点：秘钥的管理和分发非常困难，不够安全。在数据传送前，发送方和接收方必须商定好秘钥，然后双方都必须要保存好秘钥，如果一方的秘钥被泄露，那么加密信息也就不安全了。另外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。

2）非对称加密算法

• 1. 介绍：

• • • • • 两把密钥，分别是公钥和私钥，公钥加密的密文只有对应的私钥才能解密，私钥加密的密文只有公钥才能解密。
        • 不需要首先共享秘密
        • 两个密钥同时产生 ：一把密钥（公钥）是公开的，任何人都可以得到。另一把密钥（私人密钥）只有密钥的拥有者知道。
        • 用其中一把密钥（公钥或者是私钥）加密的信息，只能用另一把打开。
        • 由已知的公钥几乎不可能推导出私钥
        • 强度依赖于密钥的长度

• 1. 类型：RSA算法，ECC（椭圆曲线）算法、SM2、DSA
  2. 特征:

• • • • 性能： 加密速度很慢-不适合加密大数据
      • 密钥管理： 公钥可以广泛地、开放地分发

• • • • 使用目的：

• • • • • • • 加密
            • 签名/校验
            • 密钥交换

• 1. 优点：安全性更高，公钥是公开的，秘钥是自己保存的，不需要将私钥给别人。
  2. 缺点：加密和解密花费时间长、速度慢，只适合对少量数据进行加密。

RSA和SM2的区别：(1条消息) SM2算法和RSA算法简介_weixin_30648963的博客-CSDN博客

对称加密和非对称加密的区别：对称加密算法相比非对称加密算法来说，加解密的效率要高得多。

但是缺陷在于对于秘钥的管理上，以及在非安全信道中通讯时，密钥交换的安全性不能保障。

所以在实际的网络环境中，会将两者混合使用.

3）散列算法（摘要算法）

• 1. 介绍: 把可变输入长度串转换成固定长度输出串的一种函数。称输出串为输入串的指纹，或者数字摘要；
  2. 类型：MD5、MD2、SHA1、SHA256、SHA384、SHA512、SM3
  3. 说明：
     1. 1. 不同明文的摘要相同的概要是非常非常小的；而同样明文其摘要必定一致；
        2. 明文的长度不固定，摘要的长度固定。
  4. 特点：
     1. 1. 散列函数单向不可逆（不可解密），对输入非常敏感，输出长度固定。
        2. 针对数据的任何修改都会改变散列函数的结果。
        3. 用于防止信息篡改并验证数据的完整性。
  5. 缺点：散列函数不能单独实现信息放篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密。

SHA与MD4和MD5的比较：

4）单向杂凑函数

1. 特征 ：没有密钥 ，不可回溯
2. 典型算法：MD5, SHA-1
3. 公钥算法使用杂凑函数的目的：（做摘要）

• • 完整性检测
  • 产生数字签名

5）各种算法的特点

• 对称密码算法 ：加/解密速度快，但密钥分发问题严重
• 非对称密码算法 ：加/解密速度较慢，但无密钥分发问题
• 杂凑函数 ：计算速度快，结果长度统一

解决方案：

• 使用对称算法加密大的数据
  • • • • 每次加密先产生新的随机密钥

• 使用非对称算法交换随机产生的密钥
• 用非对称算法做数字签名（对散列值即摘要做数字签名）
• 四条基本规则：

• • • • • 先签名，然后加密
        • 加密之前先压缩
        • 用你自己的私钥做签名
        • 用接收者的公钥做加密

组合加密：

组合解密：

5、国密算法

国密算法介绍 - 知乎 (zhihu.com)

• SM1：对称加密算法中的分组加密算法，其分组长度、秘钥长度都是128bit，算法安全保密强度跟 AES 相当，但是算法不公开，仅以IP核的形式存在于芯片中，需要通过加密芯片的接口进行调用。
• SM2：非对称加密算法 ，它是基于椭圆曲线密码的公钥密码算法标准，其秘钥长度256bit，包含数字签名、密钥交换和公钥加密，用于替换RSA/DH/ECDSA/ECDH等国际算法。可以满足电子认证服务系统等应用需求，由国家密码管理局于2010年12月17号发布。 SM2采用的是ECC 256位的一种，其安全强度比RSA 2048位高，且运算速度快于RSA。
• SM3：密码杂凑算法，杂凑值长度为32字节，和SM2算法同期公布，参见《国家密码管理局公告（第 22 号）》；用于替代MD5/SHA-1/SHA-2等国际算法，适用于数字签名和验证、消息认证码的生成与验证以及随机数的生成，可以满足电子认证服务系统等应用需求，于2010年12月17日发布。

它是在SHA-256基础上改进实现的一种算法，采用Merkle-Damgard结构，消息分组长度为512bit，输出的摘要值长度为256bit。

• SM4：分组对称加密算法，随WAPI标准一起公布，可使用软件实现，用于替代DES/AES等国际算法。SM4算法与AES算法具有相同的密钥长度、分组长度，都是128bit。于2012年3月21日发布，适用于密码应用中使用分组密码的需求。
• SM7：分组加密算法，该算法没有公开。SM7适用于非接IC卡应用包括身份识别类应用(门禁卡、工作证、参赛证)，票务类应用(大型赛事门票、展会门票)，支付与通卡类应用(积分消费卡、校园一卡通、企业一卡通、公交一卡通)。
• SM9：基于标识的非对称密码算法，可以替代基于数字证书的PKI/CA体系。 SM9主要用于用户的身份认证。据新华网公开报道，SM9的加密强度等同于3072位密钥的RSA加密算法，于2016年3月28日发布。

国密即国家密码局认定的国产密码算法。主要有SM1，SM2，SM3，SM4。密钥长度和分组长度均为128位。

由于SM1、SM4加解密的分组大小为128bit，故对消息进行加解密时，若消息长度过长，需要进行分组，要消息长度不足，则要进行填充。

SM1：对称加密算法，不公开，只能通过加密设备运算

SM2：签名算法

SM3：摘要算法

SM4：对称加密算法

6、.p12和.keystore的区别

当我们需要SSL证书时，可以自动生成SSL证书，但是每个系统都申请一次证书会比较麻烦，所以用到了如下几个文件格式：

.p12(PKCS #12)

我们的每一个证书都可以生成一个.p12文件，这个文件是一个加密的文件，只要知道其密码，就可以供给所有的系统设备使用，使设备不需要在重新申请开发和发布证书，就能使用。

注意：一般.p12文件是给予别人使用的，本机必须已经有一个带秘钥的证书才可以生成.p12文件

PKCS12是一种活动文件格式，用于将加密对象存储为单个文件。它可以用来存储密钥、私钥和证书。它是RSA实验室发布的标准格式，它不仅可以用于java，而且可以用于C、C++或C等的其他库。这种文件格式经常用于从和向其他密钥存储类型导入和导出条目。

.keyStore(密钥库)

keystore中一般保存的是我们的私钥，用来加解密或者为别人做签名用。

.truststore(信任库)

truststore中保存的是一些可信任的证书，主要是java在代码中访问某个https的时候对被访问者进行认证的，以确保其实可信任的。

truststore是必须的，如果我们没有显式的指定，那么java会默认指定为$JAVA_HOME/lib/security/cacerts 这个文件。

.p12一般存放的是生成的（服务器端或客户端）证书与密钥，类似打包存放。

.keyStore一般存放的是（服务器端或客户端）证书与密钥，或直接存放 .p12 文件包。

.truststore一般存放的是系统根证书与密钥信息。

7、公私钥

• 私钥自己保留，公钥以证书形式公开.
• 公钥和私钥是成对的，它们互相解密。
• 公钥加密，私钥解密。
• 私钥数字签名，公钥验证。

RSA公钥长度（单位：位） ：1024，2048

SM2公钥长度（单位：位）：512

SM2私钥长度（单位：位）：256

8、单位换算

1B=1字节=1byte=8bit=8比特=8位

9、摘要

1）几种称呼：摘要、哈希、hash、散列等

2）摘要算法和摘要值

3）摘要的目的：将原文换算成定长。

4）常见RSA摘要算法：MD5，SHA1，SHA256

5）常见国密摘要算法：SM3

6）常见摘要算法结果长度（单位：位）：SHA1=160，SHA256=256，SM3=256，SHA384=384，SHA512=512， MD5=128

7）摘要算法原文是否无限制？否，有最大长度限制。

消息摘要具有以下特点：

（1） 唯一性：数据只要有一点改变，那么再通过消息摘要算法得到的摘要也会发生变化。虽然理论上有可能会发生碰撞，但是概率极其低。

（2） 不可逆：消息摘要算法的密文无法被解密。

（3） 不需要密钥，可使用于分布式网络。

（4） 无论输入的明文有多长，计算出来的消息摘要的长度总是固定的。

原理

消息摘要，其实就是将需要摘要的数据作为参数，经过哈希函数(Hash)的计算，得到的散列值

10、asn1

证书相关的“一般”都属于asn1结构（包括一些PKCS和国标定义的标准），可以用此工具打开分析

具体规范可百度

ASN.1讲解数字证书_文档之家 (doczj.com)

1）ASN.1 协议是什么?

在不同设备节点进行通信的时候，通常要定义一个数据协议，用来定义要传输数据的信息结构。而ASN.1 就是定义数据协议的一种方法。即写一个文件，后缀名为 .asn

例如:写一个文件，文件名叫 data.asn文件内容为: People ::= SEQUENCE{ undefinedname OCTET STRING, age INTEGER } 即定义一个数据结构People,包含两个成员，一个为字节串 name, 一个为整数age。

那么不同节点就可以根据这个文件，得到要传输数据的信息结构。如果要传输这样的数据，那么还需要将这样类型的数据转化为二进制流，即编码。ASN.1提供一下几种编码方式:

BER、CER、DER、XER、OER、PER

可使用不同编程语言，根据编码方式将数据填入比特流中，比如C语言可定义一个char数组，存储比特流。

2）ASN.1数据类型及语法

ASN.1入门（超详细）_笑不语的博客-CSDN博客_asn.1

数据类型

INTERER

BOOLEAN

REAL

ENUMERATED

BIT STRING

OCTET STRING

NULL

SEQUENCE

SEQUENCE-OF

SET

SET-OF

CHOICE

语法

::=

组合类型：

3）编码方式介绍

BER编码：基础方案（类型+长度+内容），额外数据过多

CER编码：安全性高

DER编码：安全性高

OER编码：安全性高

PER编码：压缩能力强

11、证书格式

1）jks

1. 后缀名jks、keystore等
2. 密钥仓库，可以存多组公私钥

jks是Java密钥库(KeyStore)比较常见的一种格式(我所知道的共有5种，JKS, JCEKS, PKCS12, BKS，UBER)，是JAVA的keytools证书工具支持的证书私钥格式。

jks与keystore的区别：

keystore 是Eclipse 打包生成的签名

jks是Android studio 生成的签名！都是用来打包的，并保证应用的唯一性！这就是他们的最大的区别！

jks与pfx的区别：

jks(java key store)：

java用的存储密钥的容器。可以同时容纳n个公钥或私钥，后缀一般是.jks或者.keystore或.truststore等，千奇百怪。

不管什么后缀，它就是一个容器，各个公司或机构叫法不同而已。比如把只包含"受信任的公钥"的容器存成.truststore文件等。

用jdk\bin目录下的keytool.exe对其进行查看，导入，导出，删除，修改密码等各种操作。

可以对jks容器加密码，输入正确才可以操作此容器中密钥。

还有一个密码的概念与上者不同，是jks中存储着的私钥的密码，通常是绝密的。

pfx：

和jks功能相同但文件格式不同，pfx是浏览器用的。

可以用一些工具程序把pfx转化成jks格式供java程序使用(如银行只提供了pfx，但是我们想用httpclient模拟浏览器自动访问时)。

据说IE导出的pfx格式不标准，转化jks时往往报错，可以尝试用Netscape Navigator导入再导出，然后再转化。碰到过这样的情况。

2）pfx

1）只能保存一组公私钥

2）可导入/导出浏览器

pfx全称是Predecessor of PKCS#12, 是微软支持的私钥格式，二进制格式，同时包含证书和私钥，一般有密码保护。一般用于Windows IIS服务器。

3）PEM

pem全称是Privacy Enhanced Mail，格式一般为文本格式，以---BEGIN--- 开头，以 ---END--- 结尾，中间内容是base64编码

可保存公钥，也可保存私钥。有时候会将pem格式的私钥改后缀为.key以示区别

这种格式的证书常用于apache和nginx服务器，所以在配置Nginx SSL的时候就会发现这种格式的证书文件。

4）CER

1）公钥证书文件，用于公开，不保存私钥

2）证书编码格式：DER编码（二进制，文本打开看不懂），Base64编码（文本打开看得懂）

jks是JAVA的keytools证书工具支持的证书私钥格式。

pfx是微软支持的私钥格式。

cer是证书的公钥。

5）DER

以二进制方式存储，Base64编码的文件，一般Java和Windows服务器偏向于使用此种格式的文件，相当于PEM格式文件的二进制版本。

base64编码和der 编码区别？

DER，它是ASN.1编码标准的一种编码方式，该编码方式的输出是二进制而不是普通的文本。DER 编码二进制输出的文件将会是一个二进制文件，文件内容是x509证书数据，证书数据使用ASN.1的DER 编码规则编码。

Base64编码情况下，会对证书的ASN.1的DER 编码出来的二进制数据进行Base64编码，编码结果是文本数据，并且会在编码后的数据前后添加开始和结束tag,该tag为CERTIFICATE. 两者只是数据表示形式上不同

12、CRL和OCSP

CRL:

1. 浏览器校验证书吊销状态时，会通过CRL分发点找到CRLs文件的URL，然后去下载CRLs文件，从中寻找是否存在被校验证书的序列号等信息，以此判断证书的吊销状态
2. CRL的内容包括：
   1. 1. CRL的版本号
      2. 计算本CRL的数字签名所用的算法的标识符（如加密算法RSA、数字摘要算法MD5等算法的标识符）
      3. 颁发CRL的CA的可识别名（DN）
      4. CRL的发布/更新时间
      5. 被注销证书的列表（仅列出被注销证书的唯一序列号）
      6. 扩展项
3. CRL的问题
   1. 1. 随着CA机构签发的证书越来越多，CRLs文件将越来越大，导致浏览器校验服务器身份时，下载CRLs文件会越来越耗时，从而影响了TLS/SSL握手阶段的时间。
      2. 校验安全问题，CA机构在吊销一张证书后，不会立刻去更新CRLs文件，客户端定期缓存的CRLs文件也不是及时更新的，所以会导致一种情况是，某张证书被吊销后，由于CRLs文件没有及时更新的缘故，身份校验通过了，认为该张证书没有问题。
      3. CRL校验是同步操作，会阻塞TLS/SSL协议的握手，也就是说，如果CRL校验未完成，整个TLS/SSL握手阶段都会被阻塞。

OCSP（Online Certificate Status Protocol）

在线证书状态协议同样是用来做服务器身份校验，由CA机构管理，使用数字签名技术保护，浏览器可以从中获得证书的吊销状态和吊销原因，方式是由身份校验方浏览器发送OCSP请求，等待响应来完成证书状态获取。

OCSP和CRL的区别:

1、CRL是TLS/SSL协议标准的一部分，而OCSP属于TLS/SSL协议的一部分。

2、OCSP的更新更快速，由于是在线服务，一张证书的吊销会及时更新OCSP服务。

3、对于CRL校验，浏览器需要先下载完整的CRLs文件，再从中查找序列号来校验证书的吊销状态。OCSP则不需要下载，浏览器通过发送证书信息查询请求，由OCSP响应返回该证书的吊销状态。因此，OCSP校验速度要比CRL快很多。

4、OCSP比CRL快的原因还有一个是，由于CRL和CCSP都由数字签名技术确保完整性，那么在校验时，也要校验CRL或OCSP的完整证书链，对于CRL，校验证书链需要浏览器自行一级一级往上校验，而对于OCSP，完整的证书链由响应信息时一同提供，所以节省了浏览器的校验时间。

13、p7b和P10结构

P7B：

p7b以树状展示证书链(certificate chain)，同时也支持单个证书，不含私钥。

1）证书链文件，自带根证书

2）好处：给人p7b，避免缺少根证书的问题

P10:

一个base64文件，数据前后添加开始和结束tag

一段可以向CA申请证书的P10请求，该请求一般是通过硬件生成密钥对后，将私钥单独存放，但是将公钥放入p10中，CA受到该p10请求后，可以校验，并根据p10中的信息制作一张没有私钥的公钥证书

14、证书结构

数字证书的总体结构：待签名证书、签名算法tbs、签名值

数字证书的主体是代签名证书：包括了 版本号、证书序列号、签名算法标识符、颁发者、有效期、主体名称、主体公钥信息

数字证书中的DN号是可识别名(DN)，SN号是序列号。

1）证书的用途：签名、加密

2）证书内容含义：序列号，使用者，颁发者，有效期，密钥用途等

3）证书DN各个含义：C(国家),S(省份),O(组织名称),OU(组织单位名称),CN(名字)等

4）可用asn1打开查看

5）其中证书签名值是什么？答：上一级私钥对此证书内容做签名

6）不同证书的DN是否可以重复？答：可以，CA可配置

7）证书DN各项以什么形式存储？答：Oid

X.509证书DN详解_moonpure的专栏-CSDN博客_证书dn是什么意思

OID 则是 ASN1 对象的统一表示方法，这种方法采用树状结构，由国际组织统一管理。一个公司如果要增加一个字段类型，并希望被广泛采用，它必须像管理 OID 的组织提出申请，就像我们常用的域名申请一样。

8）签名算法以什么形式存储？答：Oid

9）DN能否自定义？答：可以，双方协商oid即可

10）证书签名值是对哪些做签名？答：除了签名值 和算法，其他所有

由CA签名的X509数字证书包含这两个字段.1、签名算法 2、签名值 "签名算法"字段包含CA用来签署证书的哈希算法。"签名值"是根据散列计算的签名

11）证书中密钥用法含义：加密解密，签名

12）证书不在有效期之内什么意思：证书失效

13）如何解决下面证书中的提示信息:

颁发者证书还没有被浏览器找到 1、复制出证书颁发机构的证书名称： 打开证书，选择"详细信息"标签页，选择"颁发者"，复制下面的CN内容 2、找到该证书颁发者的证书 在证书提供者的网站上寻找证书颁发者的证书，或通过其它途径找到证书颁发者的证书 3、下载安装证书

14）理解数字证书的作用

数字证书作用是身份认证机构盖在数字身份证上的一个印章。

由CA机构（证书授权中心）发行的，在网上用它来识别对方的身份。

15） 认证证书如何验证www.baidu.com 是否受信任？？

提示：1、查看证书结构

2、如何验证证书有效性

验证证书链、有效期、签名、CRL验证证书作废

1）验证证书是否是否在有效期内？

检查证书上有签发起始时间和过期时间，通过解析X.509对象很容易得到证书的有效期

2）根证书验证

先来理解一下什么是根证书？

普通的证书一般包括三部分：用户信息，用户公钥，以及CA签名

那么我们要验证这张证书就需要验证CA签名的真伪。那么就需要CA公钥。而CA公钥存在于另外一张证书（称这张证书是对普通证书签名的证书）中。因此我们又需要验证这另外一张证书的真伪。因此又需要验证另外证书（称这张证书是对另外一张证书签名的证书）的真伪。依次往下回溯，就得到一条证书链。那么这张证书链从哪里结束呢？就是在根证书结束（即验证到根证书结束）。根证书是个很特别的证书，它是CA中心自己给自己签名的证书（即这张证书是用CA公钥对这张证书进行签名）。信任这张证书，就代表信任这张证书下的证书链。

所有用户在使用自己的证书之前必须先下载根证书。

所谓根证书验证就是：用根证书公钥来验证该证书的颁发者签名。所以首先必须要有根证书，并且根证书必须在受信任的证书列表（即信任域）。

CA下发给网站的证书是分层的证书链，从根证书开始一层一层直到网站证书。要验证某一层证书是否确实由上级CA签发的，需要验证附带在该证书上由上级CA通过签名函数及私钥生成的数字签名。数字签名的解密需要上级CA的公钥，这个公钥的明文就就保存在证书链中的上层证书中。而根证书是自己给自己签名，也就是根证书的签名也是靠自己保存的公钥来解密。这就很好解决了证实真实性的问题，也就能够证明最底层的网站证书确实是证书中表明的CA发放的。

备注：证书检测不是强制的，如果ca机构的检测服务器宕机，只会检查本地的根证书列表。

3）CRL验证

CRL是经过CA签名的证书作废列表，用于证书冻结和撤销。一般来说证书中有CRL地址，供HTTP或者LDAP方式访问，通过解析可得到CRL地址，然后下载CRL进行验证。

并且证书中有CRL生效日期以及下次更新的日期，因此CRL是自动更新的，因此会有延迟性。

于是呢，还有另外一种方式OSCP证书状态在线查询，可以即时的查询证书状态。

验证证书是否被吊销了？

吊销的证书是无效的，一般有俩种方式：

CRL（Certificate Revocation List）,证书吊销列表，离线方式；

OCSP（Online Certificate Status Protocol ）,在线证书状态检查协议（RFC6960）。

两种证书状态查询方式的比较：

15）证书链

16）证书链是否完整

15、证书请求

1）通称p10（PKCS#10标准），常用后缀.csr；

2）A生成私钥和公钥，将公钥以证书请求的形式传给CA，CA返还给A公钥证书；

3）证书请求中包含：签名算法，公 钥，证书DN等；

4）可用asn1打开查看；

5）根据CA配置，返回的证书DN 和csr中证书DN可以不一致；

16、证书状态

1）证书有效性分为有效，过期，作废等；

2）作废为CA作废证书，发布CRL或OCSP，客户端通过检查CRL或OCSP验证证书是否作废

3）只有证书文件本身无法体现是否被作废

17、证书种类

SSL证书

WEB证书

SMIME证书

双证书

加密证书

签名证书

CFCA高级证书

SPKM证书

18、SSL

SSL/TLS

​ TLS在传输层对网络连接进行加密,前身是SSL协议,由网景公司1995年发布,用以保障数据在Internet上安全地进行传输,利用数据加密技术,确保数据在网络传输过程中不会被截取或窃听.

​ 数据加密用到了非对称加密和对称加密.TCP协议建立传输连接时,SSL首先对对称加密地密钥使用非对称加密地公钥进行非对称加密,连接建立好之后,SSL对传输内容使用对称加密.

​ 对称加密,速度高,可加密内容较大,用来加密会话过程中地消息.

​ 非对称加密,加密速度较慢,但能提供更好地身份认证,用对加密对称加密地密钥.

OSI模型

​ HTTPS和HTTP协议位于应用层,SSL/TLS位于传输层和应用层之间,TCP协议位于传输层,IP协议位于网络层

SSL/TLS协议握手流程

HTTPS的SSL单向验证和双向验证_学海无涯=回头是岸的博客-CSDN博客_ssl单向认证和双向认证

SSL协议握手过程报文解析_nicholas_duan的博客-CSDN博客_ssl握手协议

HTTPS的SSL单向/双向认证

使用wireshark观察SSL/TLS握手过程--双向认证/单向认证 - 程序员大本营

SSL协议即用到了对称加密也用到了非对称加密（公钥加密），在建立传输链路时，SSL首先对对称加密的密钥使用非对称加密，链路建立好之后，SSL对传输内容使用对称加密。

对称加密：速度高，可加密内容较大，用来加密会话过程中的消息

公钥加密：加密速度较慢，但能提供更好的身份认证技术，用来加密对称加密的密钥

一、SSL单向认证过程

SSL/TLS握手过程可以分成两种类型：

1）SSL/TLS 双向认证，就是双方都会互相认证，也就是两者之间将会交换证书。

2）SSL/TLS 单向认证，客户端会认证服务器端身份，而服务器端不会去对客户端身份进行验证。

我们知道，握手过程实际上就是通信双方协商交换一个用于对称加密的**的过程，而且握手过程是明文的。

这个过程实际上产生三个随机数:client random, server random, pre-master secret. 参考图解SSL/TLS协议 .

前两个随机数都是明文传送的，只有pre-master secret是加密的（RSA或者DH)。

一般生成证书的时候，签名算法可以选择RSA或者DSA算法。

如果server使用RSA证书，RSA即可以用作签名也可以用作不对称加密，pre-master secret就是用server的RSA证书中包含的公钥加密的。

如果server使用DSA证书，DSA只能用作签名，所以还需要使用DH算法来交换**。

以下是其流程图（摘自rfc5246），括号中的步骤是可选的。

如果是单向认证，那么蓝色字体部分是不需要的。

4 server_key_exchange这一步只有在选择了某些**交换算法例如DH算法的时候才需要。

(一) 首先,客户端向服务器提供以下信息client_hello

（1）支持的协议版本，比如TLS 1.0

（2）支持的加密算法(Cipher Specs)

（3）客户端生成的随机数1(Challenge)，稍后用于生成"对话**"。

(二)服务器回答给客户端以下信息server_hello

（1） 确认使用的协议版本

（2） 服务器生成的随机数2，稍后用于生成"对话**"

（3） session id

（4） 确认使用的加密算法

certificate

服务器证书

server_key_exchange

如果是DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步。

certificate_request

要求客户端提供证书，包括（1） 客户端可以提供的证书类型（2）服务器接受的证书distinguished name列表，可以是root CA或者subordinate CA。如果服务器配置了trust keystore, 这里会列出所有在trust keystore中的证书的distinguished name。server_hello_done

server hello结束

(三)客户端发送给服务器

certificate客户端证书

client_key_exchange包含pre-master secret。客户端生成第三个随机数。如果是采用RSA算法，会生成一个48字节随机数，然后用server的公钥加密之后再放入报文中；如果是DH算法，这里发送的就是客户端的DH参数，之后服务器和客户端根据DH算法，各自计算出相同的pre-master secret。

certificate_verify发送使用客户端证书给到这一步为止收到和发送的所有握手消息签名结果。

change_cipher_spec客户端通知服务器开始使用加密方式发送报文。客户端使用上面的3个随机数client random, server random, pre-master secret, 计算出48字节的master secret, 这个就是对称加密算法的**。

finished客户端发送第一个加密报文。使用HMAC算法计算收到和发送的所有握手消息的摘要，然后通过RFC5246中定义的一个伪函数PRF计算出结果，加密后发送。

(四) 服务器发送给客户端

服务器端发送change_cipher_spec和finished消息。到这里握手结束。

服务端用自己的私钥解密出pre-master

根据三个随机数 使用同种加密算法 计算得到master secret，验证客户端的master secret

change_cipher_spec 告知客户端开始使用加密方式发送报文

finished 服务端发送第一个加密报文

1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息

2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书

3、客户端使用服务端返回的信息验证服务器的合法性，验证通过后，则继续进行通信，否则终止通信，验证内容包括:

     a、证书是否过期

     b、发行服务器证书的CA是否可靠

     c、返回的公钥是否能正确解开返回证书中的数字签名

     d、服务器证书上的域名是否和服务器的实际域名相匹配

4、客户端向服务器发送自己所能支持的对称加密方案，供服务器进行选择

5、服务器在客户端提供的加密方案中选择加密程度最高的加密方式

6、服务器将选择好的加密方式通过明文方式返回给客户端

7、客户端接收到服务器返回的加密方案后，使用该加密方案生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器

8、服务器收到客户端返回的加密信息后 ，使用自己的私钥进行解密，获取对称加密密钥。在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中的信息安全。

二、SSL双向认证过程

server证书签名算法DSA-双向认证

下面是一个server证书采用DSA算法的握手过程。由于采用了DH算法交换**，多了server_key_exchange这一步。

1、客户端向服务器发送连接请求（SSL协议版本号、加密算法种类、随机数等信息）

2、服务器给客户端返回服务器端的证书，即公钥证书，同时也返回证书相关信息（SSL协议版本号、加密算法种类、随机数等信息）

3、客户端使用服务端返回的信息验证服务器的合法性（首先检查服务器发送过来的证书是否是由自己信赖的CA中心所签发的，再比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户端认可这个服务端的合法身份），验证通过后，则继续进行通信，否则终止通信，具体验证内容包括:

     a、证书是否过期

     b、发行服务器证书的CA是否可靠

     c、返回的公钥是否能正确解开返回证书中的数字签名

     d、服务器证书上的域名是否和服务器的实际域名相匹配

4、服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端

5、验证客户端的证书，通过验证后，会获得客户端的公钥

6、客户端向服务器发送自己所能支持的对称加密方案，供服务器端进行选择

7、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式

8、将加密方式通过使用之前获取到的公钥（客户的公钥）进行加密，返回给客户端

9、客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后获取该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端

10、服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全

ssl双向认证_一篇文章讲述清楚SSL握手协议详细流程_weixin_39595085的博客-CSDN博客

概述

SSL(Secure Socket Layer)安全套接字协议是运行在应用层和TCP层之间的安全机制。保证上层应用数据传输的保密性、完整性以及传输双发身份的合法性。

• 传输加密性：握手协议定义会话密钥后，所有传输的报文被会话密钥加密。
• 消息的完整性：传输的报文中增加MAC(消息认证码)，用于检测完整性。
• 身份验证：客户端认证(可选)，服务端认证(强制)

SSL协议包括：握手协议(Handshake protocol)、SSLpassword变化协议(SSL change cipher spec protocol)、警报协议(Alert protocol)、记录协议(Record protocol)。

握手协议是SSL连接通信的第一个子协议也是最复杂的协议。

SSL分层结构

SSL握手协议

通过握手过程，客户端与服务端之间协商会话参数(包括相互验证、协商加密和MAC算法、生成会话密钥等)。

SSL握手协议过程

第一阶段：建立安全能力

客户端-client_hello：

• 客户端可以支持的SSL最高版本号；
• 客户端生成的32字节的随机数；
• 会话标识符ID；
• 客户端可以支持的密码套件列表；
• 客户端可以支持的压缩方法列表。

服务端-server_hello：

• SSL版本号，取收到的客户端SSL版本和服务端支持的最高版本中的较低者；
• 服务端生成的32字节的随机数；
• 会话标识符ID；
• 从收到的客户端密码套件列表中选择一个密码套件(包含密钥交换算法、对称加密算法、摘要算法)；
• 从收到的客户端压缩方法列表中选择一种压缩方法。

第二阶段：服务端验证和密钥交换

服务端-certificate：

• 含有公钥信息的服务端数字证书或到CA的完整证书链。

服务端-server_key_exchange：

• 可选，根据密钥协商算法而定，如果传送给客户端的服务端证书数据不足以按照第一阶段选定的密钥交换算法协商密钥，该步骤不足密钥协商元素。

服务端-certificate_request：

• 可选，请求验证客户端证书信息，单向数据认证(只认证服务端)无此步骤。

服务端-server_hello_done：

• 通知客户端版本号和加密套件协商结束。

第三阶段：客户端验证和密钥交换

客户端-certificate：

• 可选，客户端数字证书，双向数据认证中服务端要求验证客户端身份合法性。

客户端-client_key_exchange：

• 客户端交换密钥，视密钥交换算法而定，密钥协商参数或pre-master key(服务端公钥加密)。

客户端-certificate_verify：

• 可选，客户端将已交互的握手消息、会话密钥的摘要值用客户端私钥加密发送给服务端。

第四阶段：完成

客户端-change_cipher_spec：

• 改变密码格式信息，告诉服务端之后的报文消息用会话密钥加密。

客户端-finished：

• 向服务端宣布握手协议完成。

服务端-change_cipher_spec：

• 改变密码格式信息，告诉客户端之后的报文消息用会话密钥加密。

服务端-finished：

• 向客户端宣布握手协议完成。

三、SSL单向认证和SSL双向认证的区别

SSL单向认证只要求站点部署了SSL证书就行，任何用户都可以去访问（IP被限制除外等），只是服务器提供了身份认证。SSL双向认证则是需要服务端与客户端提供身份认证，只能是服务端允许的客户去访问，安全性相对高一些。

双向认证SSL协议要求服务器和用户双方都有证书。单向认证SSL协议不需要客户拥有CA证书，只需将服务器验证客户证书的过程去掉，以及在协商对称密码方案、对称通话密钥时，服务器发送给客户的是没有加过密的（这并不影响SSL过程的安全性）密码方案。这样，双方具体的通讯内容，就是加过密的数据，如果有第三方攻击，获得的只是加密的数据，第三方要获得有用的信息，就需要对加密的数据进行解密，这时候的安全就依赖于密码方案的安全。而幸运的是，目前所用的密码方案，只要通讯密钥长度足够的长，就足够安全，这也是强调使用128位加密通讯的原因。

一般Web应用都是采用SSL单向认证的，原因很简单，用户数目广泛，且无需在通讯层对用户身份进行验证，一般都在应用逻辑层来保证用户的合法登入。但如果是企业应用对接，情况就不一样，可能会要求对客户端（相对而言）做身份验证，这时就需要做SSL双向认证。

19、验证证书

1. 验颁发者：颁发者是否存在/受信任
2. 验有效期：证书是否在有效期内
3. 验证书签名值：用上一级公钥证书验证此证书签名，是否被篡改
4. 验证书状态：验证书是否被作废

20、证书一生

1. 生成一对密钥对，公私钥，私钥自己保存
2. 通过p10将公钥给ca，签发公钥证书
3. 私钥+公钥证书正常使用
4. （公钥证书被作废）
5. 公钥证书过期
6. （CA对公钥证书续期）

21、双证

1. 常用证书为单证，即签名证书；当需要做加密时，需申请双证（签名+加密）
2. A生成公私钥，公钥通过p10给CA，CA从p10中获取公钥生成签名证书signCert；CA连接KMC生成一对公私钥，加密公钥转化为加密证书encCert，加密私钥做数字信封得到env；A拿到签名证书signCert，加密证书encCert，数字信封env，解env获得加密私钥
3. Cert，sign，envelope，encrypt

22、签名流程

1. 签名目的：防篡改，为了让全世界都能验证这消息是“我”，所以用私钥签名
2. 签名算法：RSA，ECC，SM2
3. 几种签名方式：attach，detach，raw
4. attach包含签名值，签名证书，原文，遵从PKCS#7；
5. detach包含签名值，签名证书，PKCS#7;
6. Raw包含签名值， PKCS#1；
7. 实践记忆方法：找个验签接口，attach只需要传签名结果，detach需要传签名结果+原文，raw需要传签名结果+证书+原文

数字签名过程：

数字签名技术是利用算法（一般是非对称算法）通过hash函数对原文进行hash值私钥（仅个人所有）加密，生成数字签名，与原文一起传送给接收者。

接收者只有用发送者的公钥才能解密被加密的信息，然后对内容执行hash运算得到hash值，与解密得到的数字签名hash值比对。

如果比对结果一致，则说明收到的信息是完整的，在传输过程中没有被篡修改的，否则信息一定被修改过。

因此数字签名能够验证数据来源以及信息的保密性、完整性、真实性和不可否认性。

23、验签名值流程

• 从签名结果中取签名值，公钥证书+签名值做运算，得到摘要值A
• 原文+摘要算法做摘要，得到摘要值B
• A=B即可验签成功，A!=B验签失败
• 此页仅介绍验签名值，实际验签名时还需要验签名证书

验签过程：

收方首先使用发方的公钥来解密数字签名，导出数字摘要，并对电子文件原文做同样哈希算法得出一个新的数字摘要，将两个摘要的哈希值进行结果比较，相同签名得到验证，否则无效。

24、根据签名结果区分

区分方法：P7要求的签名结构，用asn1打开，有一节点为原文，此节点有值（图中的Context[0]）即为attach，无此节点即为detached，超短/结构打不开的是raw；

25、加密

• 加密的目的：隐藏原文，为了让世界上唯一一个人能解密，所以用对方的公钥加密。
• 对称加密算法：AES，DES，3DES，SM1，SM4
• 原文+公钥证书+加密算法=加密结果
• 为什么加密不用非对称？速度慢

26、CA的功能

接收验证最终用户数字证书的申请；

确定是否接受最终用户数字证书的申请：证书的审批；

向申请者颁发、拒绝颁发数字证书:证书的发放；

接收、处理最终用户的数字证书更新请求:证书的更新；

证书的冻结、解冻；

接收最终用户数字证书的查询、撤销；

产生和发布证书废止列表(CRL)

数字证书的归档；

密钥归档；

历史数据归档。

27、数字信封

信息发送者（甲）首先利用随机产生的对称密钥 对信息进行加密，再利用接收方（乙）的公钥 加密对称密钥，将加密的报文密钥和加密的发送内容按PKCS#7标准，编码组成一个“数字信封”。发送方还可以为发送内容附加签名。

被公钥加密后的对称密钥被称为数字信封。

• 本质就是加密
• A和B通信，A随机生成【对称密钥】，用【对称密钥】对原文做对称加密得到密文；用B的公钥对【对称密钥】做非对称加密，将加密后的密文+对称密钥做成信封结构传给B
• B拿到数字信封，用B私钥做非对称解密得到【对称密钥】，用【对称密钥】对密文做对称解密得到原文

数字信封流程示意图：

1）信息发送方（甲）生成对称密钥

2）甲使用对称密钥 对需要发送的信息进行加密，得到密文

3）甲使用信息接收方（乙）的加密证书中的公钥 ，加密对称密钥，得到数字信封（将加密的报文密钥和加密的发送内容按PKCS#7标准，编码组成一个“数字信封”）

4）甲将密文和数字信封 发送给乙

5）乙使用自己的加密私钥对数字信封进行拆解，得到对称密钥

6）乙使用对称密钥解密密文，得到明文

在以上过程中，利用私钥的唯一性，保证只有唯一拥有私钥的乙 才能拆解数字信封，从而阅读明文信息。

据此，甲可以确认只有乙才能阅读信息，乙可以确认信息在传递过程中保持机密。

数字信封格式（不带签名）：

28、带签名的数字信封

• 本质就是加密
• 对原文做签名后，签名结果+原文一起做对称加密得到密文
• 先签名还是先加密？答：先签名后加密

带签名的数字信封流程：

带签名的数字信封格式：

29、解密

• 加密结果+私钥+加密算法=原文
• 理论上解密永远可以成功，但是测试时需要对比解密出来的原文和加密前的原文来判断加解密成功or失败

30、证书的发放

1. 用户信息注册
2. 用户申请

• • 填写申请表
  • 选择密钥强度、密钥产生地等
  • 提交申请

1. 用户申请审核

• • 身份确认

1. 证书颁发
2. 两种主要的发放方式

• • 集中式发放

集中式密钥产生：

1、CA的一个组件以软件或者硬件的方式产生密钥对

2、CA创建一张新的公钥证书，将私钥保存在文件中或者保存在Smart Card或者其它硬件设备中并用口令或者PIN保护起来

3、文件或者Smart Card与口令或者PIN一起给用户

4、用户的文件或者Smart Card在正常的环境中使用

• • 远程发放

远程密钥生成：

1、密钥对在最终用户端产生，可以使用软件、smart card或者其它硬件设备

2、公钥按照预先定义的格式（如：P10），使用适当的传输机制提交给CA，如：email 或者 http

3、CA合并公钥信息到用户的数字证书中

4、返还数字证书给最终用户

31、X.509证书

1. 数字证书的格式遵循X.509标准。
2. X.509是由国际电信联盟（ITU-T）制定的数字证书标准。
3. X.500系列标准：

• • 1988年制定
  • 其中X.500 和 X.509 是安全认证系统的核心
    • X.500定义了一种区别命名规则，以命名树来确保用户名称的唯一性
    • X.509 为X.500用户名称提供了通信实体鉴别机制，并规定了实体鉴别过程中广泛适用的证书语法和数据接口 。 X.509称之为证书。

1. X.509证书：

• • 用户公共密钥与用户标识符

• • 还包括版本号、证书序列号、CA标识符、签名算法标识、签发者名称、证书有效期等
  • 用户可通过安全可靠的方式向CA提供其公共密钥以获得证书。

1. 版本

• • 最新标准版本：V5 （2005年8月）
  • 使用最广泛：V3
  • 国家标准部门在V3基础上增加证书扩展项：X.509C V3

1. X.509 V3

该标准待用抽象语法表示法（ASN.1）的特定编码规则（DER），对证书域中的各项信息进行编码，组成特定的证书数据结构。

• 1. 证书总体结构
     1. 待签名证书 tbsCertificate
     2. 签名算法 signatureAlgorithm
     3. 数字签名 signatureValue

• 1. 证书主体结构: 待签名证书
     1. 证书版本号 Version

证书版本号V1 V2 V3区别

• • • • 1. v3: 包括有证书扩展项
        2. v2：没有扩展域，但是使用了UniqueIdentifer
        3. V1：证书中只有一些基本的域
    • 证书序列号 seriaNumber

• • • • • CA分配给每个整数的一个正整数，每张证书的序列号唯一。
        • 非负整数
        • 可以是长整数，证书用户必须能够处理长达20个字节的序列号值。
        • CA必须确保不使用长于20个字节的序列号

• • 1. 签名算法
    2. 证书签发者 issuer

标识了签发证书的实体，必须包含一个非空的甄别名称DN

• • • • DN的格式：
        • CN：名称（域名）
        • OU：组织单位
        • O：组织机构
        • L：区（县、市）
        • S：省（市）
        • C：国家

• • 1. 证书持有者（主体）subject
    2. 证书有效期 Validity
    3. 持有者公钥信息
    4. 证书扩展项 extensions ：只能出现在V3版证书中

公钥信息 subjectPublicKeyInfo： 标识证书持有者公钥和相应的公钥算法，公钥算法使用算法标识符结构来表示

签发者唯一标识 issuerUniqueId ：这个域只能出现在V2 V3版的证书中，主要用来处理签发者名称的重用问题。V3不建议使用此域。

持有者唯一标识subjectUniqueId：只能出现在V2 V3版的证书中，主要用来处理持有者名称的重用问题。V3不建议使用此域。