【ssl认证、证书】SSL 证书基本概念、证书格式、openssl和keytool的区别

不念不忘少年蓝@ 2024-03-24 11:42 63阅读 0赞

#### 文章目录 ####

*  1. keytool VS openssl
 *  2. X.509 VS PKCS
 *   *  2.1 PKCS
     *  2.2 X.509
     *   *  2.2.1 证书编码格式
         *   *  2.2.1.1 DER 证书编码格式二进制
             *  2.2.1.2 文本格式 pem
         *  2.2.2 文件后缀名
 *  3. 常见Web服务软件及证书格式
 *  参考

相关文章：  
//-----------Java SSL begin----------------------  
[【ssl认证、证书】SSL双向认证和SSL单向认证的区别(示意图)][ssl_SSL_SSL]  
[【ssl认证、证书】java中的ssl语法API说明(SSLContext)、与keytool 工具的联系][ssl_java_ssl_API_SSLContext_keytool]  
[【ssl认证、证书】SSL双向认证java实战、keytool创建证书][ssl_SSL_java_keytool]  
[【ssl认证、证书】Wireshark抓包分析][ssl_Wireshark]  
[【ssl认证、证书】 查看keystore文件内容][ssl_ _keystore]  
//------------Java SSL end--------------------------

//-----------下面的是CA证书和openssl相关的知识--------------  
[【ssl认证、证书】TLS/SSL双向认证概念、openssl genrsa示例][ssl_TLS_SSL_openssl genrsa]  
[【ssl认证、证书】openssl genrsa 命令详解][ssl_openssl genrsa]  
[【ssl认证、证书】SSL 证书基本概念、证书格式、openssl和keytool的区别][ssl_SSL _openssl_keytool]

## 1. keytool VS openssl ##

keytool 和 openssl 是俩个证书管理`工具`。

首先要确认一个前提，keytool生成的证书和Java语言的ssl通信是强相关的，OpenSSL生成的证书，需要先按照相应的格式转换为Java能识别的格式之后，才能使用。

*  keytool 是 java JDK 自带的证书管理工具，使用 keytool 可以生成密钥，创建证书。只要装了 jdk，并正确设置了环境变量，就可以之间通过命令行执行 keytool 命令来管理证书。
    
    keytool只能生成自签名的数字证书。所谓的自签名证书就是没有经CA签发机构签发，而是自己签发的，由于无法利用CA根证书进行判断证书的合法性，只能通过白名单形式进行证书验证，对于每一个要连接的服务器，都要提前拷贝一个证书的副本，放入trust key store(简称TKS)，TKS内的证书就是已授信证书的白名单，即Java SSL通信与标准的SSL相比，JAVA定制化了证书的验证，TKS的设计替代了CA\_ROOT检测证书。 因此Keytool存在这样的缺点：需要提前拷贝，并导入到TKS作为白名单。
 *  openssl 则是一个开源的安全套接字层密码库，功能比 keytool 更加丰富。
    
    OpenSSL是标准的SSL实现，利用证书链进行双向认证或单向认证。证书链是指对证书的签名有一个预先部署的，众所周知的签名方签名完成，这样每次需要验证证书时只要用这个公用的签名方的公钥(根证书本质就是这个公钥)进行验证就可以了。比如我们使用的浏览器就保存了几个常用的CA\_ROOT(即常说的根证书)。每次连接到网站时只要判断这个网站的证书是经过这些CA\_ROOT签名过的，就认可通过验证了。
    
    并且证书是通过网络发送到对端的，不需要提前拷贝至对端，CA\_ROOT是预置的，都是知名CA机构的，非常可靠。
    
    共用的CA\_ROOT的服务不是免费的，而且价格不菲，如果是企业内部的通信，可以使用自签发的CA\_ROOT，进而生成自签名的证书，同时把CA\_ROOT提前发至对端，那么后续流程是和标准的SSL流程就一样了

## 2. X.509 VS PKCS ##

在计算机界，有各种密码学标准，它们表示了如何在计算机中计算、存储、传输（等）各种算法，这些标准由 IEFT、ITU-T、ISO 等标准组织机构编写。

在探讨这些东西之前，这里先提醒一件事情，下文中有些地方提到的私钥，实际上并不是纯粹的私钥（例如 RSA 中的  
），而是包含了整个密钥对全部必要信息的密钥（自然也包含公钥），这就是为什么在私钥中可以提取出公钥。

> 如 RSA 公钥包括在 RSAPrivateKey 中，ECC 公钥包括在 ECPrivateKey 中。

`PKCS 协议组和 X.509 协议均采用 ASN.1 来定义密钥或证书的数据结构`。都是 `ASN.1 协议`的具体实现。

关系总览：  
![在这里插入图片描述][b4a780fd5dd1492d95e641b5d16d7ef6.png]

### 2.1 PKCS ###

PKCS 全称 Public-Key Cryptography Standards ，即公钥标准，PKCS 已经发布了15个标准。

*  PKCS\#1 和 X.509比较接近
 *  …
 *  PKCS\#12 包含了公钥和私钥的二进制格式的证书形式，以 `.pfx` 作为证书文件后缀。其他类型的一般公钥和私钥不会放在一起，一般都是非 `.pfx` 格式。

> 虽然叫公钥标准，但是也含有私钥的标准

<table> 
 <tbody> 
  <tr> 
   <th>标准</th> 
   <th>版本</th> 
   <th>名称</th> 
   <th>简介</th> 
  </tr> 
  <tr> 
   <td>PKCS #1</td> 
   <td>2.2</td> 
   <td>RSA 加密规范（RSA Cryptography Standard）</td> 
   <td>提供了基于 RSA 算法的公钥加密实现的建议，包括加密原语、加密方案、带附录的签名方案，以及用于表示密钥和识别方案的 ASN.1 语法。参见 RFC 8017。</td> 
  </tr> 
  <tr> 
   <td>PKCS #2</td> 
   <td>-</td> 
   <td>弃用</td> 
   <td>原本是用以规范 RSA 加密摘要的转换方式，现已被纳入 PKCS #1 之中。</td> 
  </tr> 
  <tr> 
   <td>PKCS #3</td> 
   <td>1.4</td> 
   <td>Diffie-Hellman 协议标准（Diffie-Hellman key agreement Standard）</td> 
   <td>规范以 Diffie-Hellman 协议为基础的密钥协议标准。其功能可以让两方通过过协议，拟定一把会议密钥（Session key）。</td> 
  </tr> 
  <tr> 
   <td>PKCS #4</td> 
   <td>-</td> 
   <td>弃用</td> 
   <td>原本用以规范转换 RSA 密钥的流程。已被纳入 PKCS #1 之中。</td> 
  </tr> 
  <tr> 
   <td>PKCS #5</td> 
   <td>2.1</td> 
   <td>基于密码的加密规范（Password-based Encryption Standard）</td> 
   <td>参见 RFC 8018。</td> 
  </tr> 
  <tr> 
   <td>PKCS #6</td> 
   <td>1.5</td> 
   <td>证书扩展语法标准（Extended-Certificate Syntax Standard）</td> 
   <td>将原本 X.509 的证书格式标准加以扩充。</td> 
  </tr> 
  <tr> 
   <td>PKCS #7</td> 
   <td>1.5</td> 
   <td>密码讯息语法标准（Cryptographic Message Syntax Standard）</td> 
   <td>参见 RFC 2315。规范了以公开密钥基础设施（PKI）所产生之签章/密文的格式。其目的一样是为了拓展数位证书的应用。其中，包含了 S/MIME 与 CMS（英语：Cryptographic Message Syntax）。</td> 
  </tr> 
  <tr> 
   <td>PKCS #8</td> 
   <td>1.2</td> 
   <td>私钥信息语法规范（Private-Key Information Syntax Standard）</td> 
   <td>存储私钥信息的标准语法。参见 RFC 5208。</td> 
  </tr> 
  <tr> 
   <td>PKCS #9</td> 
   <td>2.0</td> 
   <td>选择属性格式（Selected Attribute Types）</td> 
   <td>定义 PKCS #6、7、8、10 的选择属性格式。</td> 
  </tr> 
  <tr> 
   <td>PKCS #10</td> 
   <td>1.7</td> 
   <td>证书申请标准（Certification Request Standard）</td> 
   <td>参见 RFC 2986。规范了向证书中心申请证书的 CSR（certificate signing request）的格式。</td> 
  </tr> 
  <tr> 
   <td>PKCS #11</td> 
   <td>2.20</td> 
   <td>密码装置标准介面（Cryptographic Token Interface (Cryptoki)）</td> 
   <td>定义了密码装置的应用程式介面（API）之规格。</td> 
  </tr> 
  <tr> 
   <td>PKCS #12</td> 
   <td>1.0</td> 
   <td>个人讯息交换标准（Personal Information Exchange Syntax Standard）</td> 
   <td>定义了<font>包含私钥与公钥证书</font>（public key certificate）的文件格式。私钥采密码（password）保护。常见的 <font>PFX格式 </font>就履行了 PKCS #12。</td> 
  </tr> 
  <tr> 
   <td>PKCS #13</td> 
   <td>–</td> 
   <td>椭圆曲线密码学标准（Elliptic curve cryptography Standard）</td> 
   <td>制定中。规范以椭圆曲线密码学为基础所发展之密码技术应用。椭圆曲线密码学是新的密码学技术，其强度与效率皆比现行以指数运算为基础之密码学演算法来的优秀。然而，该演算法的应用尚不普及。</td> 
  </tr> 
  <tr> 
   <td>PKCS #14</td> 
   <td>–</td> 
   <td>伪随机数生成器（英语：Pseudorandom number generator）标准</td> 
   <td>制定中。规范伪随机数生成器的使用与设计。</td> 
  </tr> 
  <tr> 
   <td>PKCS #15</td> 
   <td>1.1</td> 
   <td>密码装置讯息格式标准（Cryptographic Token Information Format Standard）</td> 
   <td>定义了密码设备内部数据的组织结构。</td> 
  </tr> 
 </tbody> 
</table>

### 2.2 X.509 ###

X.509 是密码学里公钥证书的格式标准。X.509 证书已应用在包括 TLS/SSL 在内的众多网络协议里，同时它也用在很多非在线应用场景里，比如电子签名服务。`X.509 证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构 CA 的签名，也可以是自签名）`

> 虽然叫公钥标准，但是也含有私钥的标准

#### 2.2.1 证书编码格式 ####

DER和perm是协议，前者是二进制，后者是文本；

##### 2.2.1.1 DER 证书编码格式二进制 #####

X.690 是一种 ITU-T 标准，指定了几种 ASN.1 编码格式：

*  基本编码规则（BER，Basic Encoding Rules） `抽象`的编码格式，一般不会实际使用作为后缀
 *  规范编码规则（CER，Canonical Encoding Rules） 二进制，常作为实际后缀名
 *  可分辨编码规则（DER，Distinguished Encoding Rules） 二进制，是BER的子集，常作为实际后缀名

`BER 是 ASN.1 标准制定的用于将数据编码为二进制格式的原始规则`。这些规则在 ASN.1 用语中统称为传输语法，指定用于编码数据的确切八位字节（8 位字节）。

`DER 是 BER 的子集`，提供了一种对 ASN.1 值进行编码的方式。DER 适用于需要唯一编码的情况，例如在密码学中，并确保需要数字签名的数据结构产生唯一的序列化表示。DER 可以被认为是 BER 的规范形式。

在密码学方面，可以简单理解为 `DER 就是 ASN.1 的二进制表达`，平常使用的后缀名为`.der`的密钥/证书文件里存储的就是 DER 规则的二进制，这些二进制可以被解析为 ASN.1 抽象结构。

举个例子，这是实际的一个 X.509 公钥的`.der`文件的字节内容：

30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01
    01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01
    00 B5 42 F1 89 F0 7D 0D 70 44 D3 CA 3D 6A 94 A8
    D8 5A A7 C9 CC 02 8A 23 F7 AB F8 87 A7 3A 60 FC
    EC DE 1D 25 8C 27 8D 19 C3 21 84 5C D4 D7 8A 2E
    32 BF 66 C1 51 8A 94 B3 72 06 BE D5 B8 41 15 DF
    7F C4 1B 55 F4 4A 60 CC 54 0B B8 AD 3F AF AF 71
    FC 17 42 78 72 AC 8D 5E BE C3 29 D8 98 6B AA DB
    90 86 AB 08 A7 19 FE 33 FB FB 56 23 EE 33 3E F3
    95 98 09 38 6C B9 A1 F9 F5 18 94 1B 8E CF D2 F0
    27 4B BC 24 52 0C 70 E4 A6 B9 EB 96 60 14 09 BB
    7C B7 FF E4 B0 17 A4 28 68 55 D5 1E 5E 84 57 CD
    9C E0 FC 35 31 A7 53 80 BE 30 82 94 34 15 C0 75
    DB EF A4 BB 01 D7 E6 17 83 52 8B 2E 0E B1 DA C5
    32 2D B6 F7 EB 2F AE 3A ED DE 3B FA 3A F8 F2 5D
    BC 84 BC E3 F8 BB 1B 5D 85 06 AB C2 B8 8A 82 8E
    9D 38 71 79 54 7E 91 FA 7A 14 CF 20 AF 5E 54 22
    F1 B6 D3 D2 89 21 43 75 65 3D 74 4B D7 2E 78 52
    03 02 03 01 00 01

它对应的 ASN.1 为：

SEQUENCE {
        
      SEQUENCE {
        
        OBJECT IDENTIFIER 1.2.840.113549.1.1.1 rsaEncryption (PKCS #1)
        NULL
      }
      BIT STRING {
        
        SEQUENCE {
        
          INTEGER 228821442744892501318627381803596567786967739438082404228277133253533…
          INTEGER 65537
        }
      }
    }

##### 2.2.1.2 文本格式 pem #####

互联网上使用的几个安全相关标准定义了 ASN.1 数据格式，这些格式通常使用基本编码规则（BER）或可分辨编码规则（DER）进行编码，这是二进制的编码。二进制数据格式的一个缺点是不能在文本传输（如电子邮件或文本文档）中交换。基于文本的编码的一个优点是，它们很容易使用通用文本编辑器进行修改；例如，用户可以连接多个证书以形成具有复制和粘贴操作的证书链。

隐私增强邮件（PEM, Privacy Enhanced Mail）则可以追溯到 RFC 1421，这是基于 Marshall Rose 在消息封装（RFC 934）中提出的建议。最初被称为“PEM 封装机制”、“封装的 PEM 消息”或“PEM 可打印编码”，今天这种格式有时被称为“PEM 编码”。它指定了语法的标准格式，并将行尾字符声明为回车符/换行符对。

简单来说，它实际上就是把`二进制内容用 Base64 编码一下，然后加上-----BEGIN label-----形式的头部和-----END label-----形式的尾部`。

不过，RFC 是通过查看现有实现并记录它们所做的事情来编写的。RFC 不是首先编写的，也不是基于一些现有的权威文档编写的。因此，如果想要与某些实现进行互操作，则可能必须查看实现的源代码以确定它们支持的内容。

例如，OpenSSL 在crypto/pem/pem.h中定义了这些 `BEGIN` 和 `END` 标记。以下是头文件的摘录，其中包含它们支持的所有 BEGIN 和 END 标签。

# define PEM_STRING_X509_OLD     "X509 CERTIFICATE"
    # define PEM_STRING_X509         "CERTIFICATE"
    # define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE"
    # define PEM_STRING_X509_REQ_OLD "NEW CERTIFICATE REQUEST"
    # define PEM_STRING_X509_REQ     "CERTIFICATE REQUEST"
    # define PEM_STRING_X509_CRL     "X509 CRL"
    # define PEM_STRING_EVP_PKEY     "ANY PRIVATE KEY"
    # define PEM_STRING_PUBLIC       "PUBLIC KEY"
    # define PEM_STRING_RSA          "RSA PRIVATE KEY"
    # define PEM_STRING_RSA_PUBLIC   "RSA PUBLIC KEY"
    # define PEM_STRING_DSA          "DSA PRIVATE KEY"
    # define PEM_STRING_DSA_PUBLIC   "DSA PUBLIC KEY"
    # define PEM_STRING_PKCS7        "PKCS7"
    # define PEM_STRING_PKCS7_SIGNED "PKCS #7 SIGNED DATA"
    # define PEM_STRING_PKCS8        "ENCRYPTED PRIVATE KEY"
    # define PEM_STRING_PKCS8INF     "PRIVATE KEY"
    # define PEM_STRING_DHPARAMS     "DH PARAMETERS"
    # define PEM_STRING_DHXPARAMS    "X9.42 DH PARAMETERS"
    # define PEM_STRING_SSL_SESSION  "SSL SESSION PARAMETERS"
    # define PEM_STRING_DSAPARAMS    "DSA PARAMETERS"
    # define PEM_STRING_ECDSA_PUBLIC "ECDSA PUBLIC KEY"
    # define PEM_STRING_ECPARAMETERS "EC PARAMETERS"
    # define PEM_STRING_ECPRIVATEKEY "EC PRIVATE KEY"
    # define PEM_STRING_PARAMETERS   "PARAMETERS"
    # define PEM_STRING_CMS          "CMS"

PEM文件的文件格式：

-----BEGIN (label)-----
    /*　　data　　*/
    -----END (label)-----

label 决定了被编码消息的类型，通常这些类型有如下一些：  
“CERTIFICATE”, “CERTIFICATE REQUEST”, “PRIVATE KEY”, “ENCRYPTED PRIVATE KEY” and “X509 CRL”.

如，`X.509 公钥`的标记为：

-----BEGIN PUBLIC KEY-----
    -----END PUBLIC KEY-----

`X.509 证书`的标记为：

---- BEGIN CERTIFICATE----
    /* 证书 */
    ----END CERTIFICATE----

`X.509 证书请求`的标记为：

-----BEGIN CERTIFICATE REQUEST-----
    /*    CSR    */
    -----END CERTIFICATE REQUEST-----

`PKCS #1 公钥`的标记为：

-----BEGIN RSA PUBLIC KEY-----
    -----END RSA PUBLIC KEY-----

`PKCS #1 加密私钥`的标记为：

-----BEGIN RSA PRIVATE KEY-----
    -----END RSA PRIVATE KEY-----

`PKCS #8 未加密私钥`的标记为：

-----BEGIN PRIVATE KEY-----
    -----END PRIVATE KEY-----

PKCS \#8 加密后私钥的标记为：

-----BEGIN ENCRYPTED PRIVATE KEY-----
    -----END ENCRYPTED PRIVATE KEY-----

#### 2.2.2 文件后缀名 ####

前面我们知道了二进制和文本形式的证书格式，那么为了便于用户识别证书的协议等信息，约定了一些后缀，通过后缀，用户大概就知道了证书的一些信息

<table> 
 <thead> 
  <tr> 
   <th align="left">文件后缀</th> 
   <th align="left">文件类型</th> 
   <th align="left">说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">*.CRT</td> 
   <td align="left">二进制格式或文本格式</td> 
   <td align="left">Certificate的缩写，表示证书文件，且只含有证书信息，不包含私钥。 多用于linux系统</td> 
  </tr> 
  <tr> 
   <td align="left">*.CER</td> 
   <td align="left">二进制格式或文本格式</td> 
   <td align="left">和上面的crt几乎相同，表示证书文件，多用于windows</td> 
  </tr> 
  <tr> 
   <td align="left">*.PEM</td> 
   <td align="left">文本格式</td> 
   <td align="left">既是协议，又可作为后缀；文本格式IDE编码，一般存放证书或私钥，或同时包含证书和私钥。<br>.PEM文件如果只包含私钥，一般用.KEY文件代替。</td> 
  </tr> 
  <tr> 
   <td align="left">*.DER</td> 
   <td align="left">二进制格式</td> 
   <td align="left">既是协议，又可作为后缀；二进制格式IDE编码，一般存放证书或私钥，或同时包含证书和私钥。</td> 
  </tr> 
  <tr> 
   <td align="left">.PFX或.P12</td> 
   <td align="left">二进制格式</td> 
   <td align="left">同时包含证书和私钥，且一般有密码保护。</td> 
  </tr> 
  <tr> 
   <td align="left">.JKS</td> 
   <td align="left">二进制格式</td> 
   <td align="left">同时包含证书和私钥，一般有密码保护。</td> 
  </tr> 
 </tbody> 
</table>

从上面表格可看到：

*  CER或CRT 就是证书的代名词，并且不含私钥。
 *  der 和pem 是协议，又可以直接作为后缀名，让用户知道是用二进制还是文本存储的，但是具体的内容可以是证书，也可以是密钥
 *  pem格式，可以直接通过 cat命令查看 ，以”—–BEGIN…”开头, “—–END…”结尾
 *  二进制格式无法直接查看，可以通过 `openssl x509 -text -in server.cert` 进行查看，此时会转换为以”—–BEGIN…”开头, “—–END…”结尾
 *  二进制 和 文本之间PEM可以互相转换 ，因为只是 编码格式的转换 ，你也可以把pem转换为二进制格式
 *  PFX和JKS 是包含证书和私钥的，其他的一定都不含。
    
     *  利用Java的一个叫”keytool”的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS
     *  此外，证书含有私钥，那么别人获取证书时，要是导出私钥怎么办？很简单，在创建pfx时，有参数可以禁止导出私钥；即使允许导出私钥，你需要提供导出私钥的密码，这个密码保证了不是任何人都能随意导出私钥
 *  BER是编码的基础规范，一般不作为文件的具体后缀名
 *  .csr 是证书请求文件，由客户生成，然后提供给CA签发机构，是由 RFC 2986定义的PKCS10格式，包含部分/全部的请求证书的信息，比如，主题, 机构，国家等，并且包含了请求证书的公玥，这些被CA签发机构中心签名后返回一张证书。返回的证书是公钥证书（只包含公玥不含私钥）。
    
    也就是说公司名称等这些参数是放在请求文件中的，并且含有公钥，一并交给CA机构，公钥怎么来的？是利用私钥生成的，因此这个步骤入参需要私钥。虽然用到了私钥，但是产出的请求文件中，一定不含私钥。
    
    证书签名请求是申请人向证书颁发机构发送的一条消息，用于申请数字身份证书。
    
    有 CSR 必定有 KEY，是成对的，CSR 最终变成为证书 crt，和私钥 key 配对使用。证书下发后，CSR 就没有用了，只是在交时候需要。

## 3. 常见Web服务软件及证书格式 ##

证书的使用分为2种场景，一种是web服务器，就是我们通过浏览器访问web网站时，由网站侧开启Https，通过443端口进行安全通信，背后实际上是web服务器在起作用，而web服务器能只能识别指定的证书格式；另一个场景就是端到端通信，就是socket编码，此时需要根据不同的语言，来实现具体的证书格式。

常见的 Web 服务软件，通常都基于 OpenSSL 和 Java 两种基础密码库。

*  Tomcat、Weblogic、JBoss 等 Web 服务软件，一般使用 Java 提供的密码库。通过 Java Development Kit（JDK）工具包中的 Keytool 工具，生成 Java Keystore（JKS）、keystore 格式的证书文件。
    
    .keystore 和 .jks 都是 java 用来存放密钥的文件。它使用户能够管理自己的公钥/私钥对及相关证书，用于（通过数字签名）自我认证（用户向别的用户/服务认证自己）或数据完整性以及认证服务。它还允许用户储存他们的通信对等者的公钥（以证书形式）。
 *  Apache、Nginx 等 Web 服务软件，一般使用 OpenSSL 工具提供的密码库，生成 PEM、KEY、CRT 等格式的证书文件。
 *  IBM 的 Web 服务产品，如 Websphere、IBM Http Server（IHS）等，一般使用 IBM 产品自带的 iKeyman 工具，生成 KDB 格式的证书文件。
 *  微软 Windows Server 中的 Internet Information Services（IIS）服务，使用 Windows 自带的证书库生成 PFX 格式的证书文件。

## 参考 ##

[SSL 证书基本概念扫盲][SSL]  
[密码学浅谈（2）：密码学标准 - X.509 与 PKCS 系列][2_ - X.509 _ PKCS]  
[SSL/TLS数字证书各种格式解释][SSL_TLS]  
[详解关于SSL证书的多种格式][SSL 1]

[ssl_SSL_SSL]: https://blog.csdn.net/m0_45406092/article/details/114638087
[ssl_java_ssl_API_SSLContext_keytool]: https://blog.csdn.net/m0_45406092/article/details/129959801
[ssl_SSL_java_keytool]: https://blog.csdn.net/m0_45406092/article/details/129790663
[ssl_Wireshark]: https://blog.csdn.net/m0_45406092/article/details/129996514
[ssl_ _keystore]: https://blog.csdn.net/m0_45406092/article/details/129799296
[ssl_TLS_SSL_openssl genrsa]: https://blog.csdn.net/m0_45406092/article/details/128932842
[ssl_openssl genrsa]: https://blog.csdn.net/m0_45406092/article/details/128953005
[ssl_SSL _openssl_keytool]: https://blog.csdn.net/m0_45406092/article/details/129864618
[b4a780fd5dd1492d95e641b5d16d7ef6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/84920125def946238bf1ec6b4ecef31a.png
[SSL]: https://www.cnblogs.com/jmcui/p/17076655.html
[2_ - X.509 _ PKCS]: https://zhuanlan.zhihu.com/p/543707056
[SSL_TLS]: https://www.cnblogs.com/Brickert/p/16146118.html
[SSL 1]: https://www.jianshu.com/p/1ffe0749cc87