https原理-明文、对称加密、非对称加密、CA

为了保证数据传输过程中的数据安全，目前都使用https协议。https全称：HyperText Transfer Protocol over Secure Socket Layer。其实https不是一个新的东西，我们可以理解为https=http+SSL/TLS。

SSL(Secure Socket Layer)：安全套接字层协议

TLS(Transport Layer Security)：传输层安全协议，其前身是SSL

上述SSL/TLS协议只是定义了一种协议，如果需要支持SSL协议，首先操作系统需要安装这个协议的某个具体实现。比较出名的SSL/TLS开源实现是openssl。

这个协议会占用443端口。

下面探究一下https的实现过程，会从明文传输到使用ca机构颁发证书等由浅入深的进行讲解。

1 明文

在刚开始，人们还未意识到网络环境的复杂性的时候往往使用明文传输，请求和响应过程都会遭到黑客攻击(因为网络传输会经过各种各样的防火墙、路由器、网络运营商，这里的黑客就是伪装成其中一个节点，对请求进行拦截和转发、同时进行篡改)。

这种情况下，数据基本上是处于裸奔状态，如果某一跳节点想看你的数据，他就可以看的到

2 对称加密

为了解决明文传输的问题，很简单的想法是对数据进行加密。比如客户端和服务端约定一个秘钥，使用这个秘钥进行加密就是对称加密。

使用对称加密，黑客同样可以伪装成良民请求密钥，使用该密钥在请求和响应的过程中对数据进行窃听和篡改。

由此可见，对称加密不能解决我们的数据传输安全问题。

3 非对称加密

既然对称加密不安全，那我们使用非对称加密，即加密秘钥和解密秘钥不同。服务端有一对公钥和私钥，

公钥加密，私钥解密；私钥加密，公钥解密。

请求的过程：

  • 首先，客户端请求公钥。
  • 然后使用公钥加密，传输数据，
  • 服务端使用私钥解密，获取到原文。

响应的过程：

  • 首先，服务端使用私钥加密，返回数据。
  • 客户端使用公钥解密，获取响应报文。

存在的问题：

  • 黑客同样可以获取到公钥，在响应阶段，黑客介入，使用公钥对密文解密；
  • 但是请求阶段，因为是公钥加密，公钥不能解密，所以请求是安全的。响应是不安全的。

4 对称加密+非对称加密混合使用

看来非对称加密也不够安全，继续探究另外一种场景

过程：

  • 首先，使用非对称加密的方式获取到公钥pk
  • 其次，客户端生成随机串num1，使用公钥加密后生成X传给服务器，
  • 然后，服务器使用私钥解密X得到num1
  • 然后，服务器返回客户端OK
  • 然后后续的通信都使用num1对数据进行对称加密。

解决了什么问题？

这种方式解决了3中使用非对称加密，响应报文，黑客可以使用公钥解密的问题。

存在的问题：

中间人攻击问题。

  • (1)在客户端请求服务端获取公钥时，黑客就介入。伪装成服务器和客户端通信。客户端得到的公钥是黑客的公钥pk1。而同时，黑客伪装成客户端和服务器通信，获取公钥pk。
  • (2)客户端发送num1到黑客，黑客发送num1到服务端。后续通信使用num1对数据进行对称加密通信。
  • (3)整个过程中，客户端觉察不到黑客的存在，客户端以为和它通信的是真正的服务端。为了解决这个问题引入可信认证机构(CA)见下面分析。

5 对称加密+非对称加密+CA公钥

既然会有中间人攻击问题，我们得出结论：只要传递公钥，就不安全，因此公钥不传才安全。那怎么不传公钥呢？我们引入第三者，这个第三者是一个公信力比较强的机构，即CA机构。此处需要操作系统的支持，操作系统需要内嵌这个CA机构的公钥cpk。

这个CA机构有一对公私钥cpk/csk。服务端也有一对公私钥pk/sk。服务端(需要花钱)把自己的公钥传递给CA机构，CA机构使用csk对pk进行加密得到ca.密文，CA把这个ca.密文返回给服务端。后续客户端请求服务端时，不传这个pk了，改传ca.密文，客户端得到这个ca.密文后，因为操作系统会内嵌这些大牌CA机构的公钥cpk，因此，客户端拿到服务端证书之后，根据自己操作系统中内嵌的CA机构的公钥cpk就能解开这个ca.密文，解开这个密文得到的就是服务器公钥pk，因此达到了不传pk服务端和客户端都知道这个pk的目的。

但是，如下图所示，如果黑客作为中间人，它也生成一对公私钥，因为ca得公钥cpk是公开的，黑客也知道，很容易的就能对ca.密文进行截胡，也就能够知道服务端公钥pk，也就能够使用公钥解密数据，因此，在这里，黑客能够看到服务端发过来的所有明文数据。接着黑客也可以去ca申请自己的ca.黑客.密文，重新对数据进行加密后传给客户端，客户端使用ca.公钥解开的数据此时是黑客的公钥。效果上看，就是服务端看黑客是客户端，客户端看黑客是服务端，同样是中间人攻击。

 

 

 

 看来CA机构只对服务端公钥进行加密得到ca.密文还不够，CA机构还需要承担更大的责任。

6 对称加密+非对称加密+CA证书

如上所述，既然ca把自己的公钥能够放到操作系统里，那么ca应该有这个能力对合法的服务端做认证(也就是能够保证服务端是真正的服务端，不是伪造的)。当服务端把公钥给了ca机构，ca机构会对这个服务端做背景调查(域名、公司名、法人...)，然后ca机构会向服务端下发证书。最重要的一点是服务端公钥和域名绑定。客户端浏览器访问服务器时，首先通过ssl协议443端口获取服务端证书，浏览器会对证书做校验(最重要的一点是校验服务端域名和服务端公钥绑定关系)。

下面我们看一个网站证书的示例，比如博客园的证书示例如下，一二级证书在每台电脑的操作系统中都有的，而三级证书是没有的，但是其父证书操作系统中是有的。

 

下面我们来看看这种情况下请求和响应的详细过程。

过程：

  • (1)服务端生成一对公私钥sk和pk。服务端把pk传给CA机构CA机构使用cpk对pk加密，并加以一些其他东西(域名、公司名、颁发者、有效期、指纹等)生成证书，颁发给服务端。
  • (2)TLS第一次握手，客户端发送支持的加密算法列表给服务端
  • (3)TLS第二次握手，服务端返回客户端证书
  • (4)客户端浏览器在客户端的操作系统中查找该证书对应的CA机构根证书，找不到则弹出浏览器提示“不安全的访问连接是否继续”。找到CA根证书(根证书和服务端证书不一样)。在根证书中得到cpk，然后用cpk对服务端证书携带的加密的pk进行解密，解密得到pk
  • (5)TLS第三次握手，客户端使用pk对随机串num1进行加密得到密文X
  • (6)服务端使用sk对X解密得到随机串num1
  • (7)TLS第四次握手，服务端发送确认ok
  • (8)后续的通信，使用num1对数据进行对称加密，进行通信。

下图是操作系统自带的CA机构的根证书

 

 

注意，上面所有协商过程都是通过443端口进行的，这个端口是不能改的(有的人说能改啊，修改openssl代码，但是目前主流浏览器https请求都是发往443端口，除非浏览器也同步改)。

 

6 http和https关系

比较难于理解的一点是，http和https一点关系都没有，他们是两种不同的协议，http走80端口，https走443端口

比如我们访问 http://baidu.com 

 

 我们可以看到其访问的是80端口，接着有一次跳转，跳转到如下地址：https://www.baidu.com，如下

 

这个https请求走的443端口，不会走80端口。接下来的所有请求都是https请求，都走443端口

 

 

我们再看一下另外一种场景

我们访问http://baidu.com:443,看看能不能访问？我们先分析一下，这里我们使用http协议访问443端口，因为443端口只会处理https请求，理论上访问不通，我们看一下是否如此

 

 

 

我们再看另外一种场景

我们访问https://baidu.com:80,我们先分析一下，这里我们使用https协议访问80端口，因为https只能访问443端口，这是操作系统ssl协议写死的，也是主流浏览器写死的，理论上访问不了，我们看一下是否如此

 

 

从上面的分析示例我们可以看出，https走的是443端口，即使是请求完证书开始传递数据的情况下也是如此，和80端口没有1毛钱关系。

7 附：证书组成

我们可以导出某个网站的证书

image

弹出导出页面，这里有多个导出格式供我们选择，我们选择DER编码的二进制单证书

image

然后，我们使用如下命令查看证书的详细信息

C:\Users\root>certutil -dump C:\Users\root\Desktop\_.cnblogs.der
X509 证书:
版本: 3
序列号: 015305ac1e1261c98c6c8596edce878c
签名算法:
    算法 ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    算法参数:
    05 00
颁发者:
    CN=Encryption Everywhere DV TLS CA - G2
    OU=www.digicert.com
    O=DigiCert Inc
    C=US
  名称哈希(sha1): f28a8952cd304b1a1f240c817cdd3739a78b390a
  名称哈希(md5): f43604786ec32da3cb7f9152c5570b03

 NotBefore: 2026/2/11 8:00
 NotAfter: 2027/2/11 7:59

使用者:
    CN=*.cnblogs.com
  名称哈希(sha1): 100ef71d1a52053de1350334ab823c94d3f6a535
  名称哈希(md5): 698e0e6a06c04171b7546b9fd2f0ba65

公钥算法:
    算法 ObjectId: 1.2.840.113549.1.1.1 RSA
    算法参数:
    05 00
公钥长度: 2048 bits
公钥: UnusedBits = 0
    0000  30 82 01 0a 02 82 01 01  00 d3 69 c0 a6 ef 78 83
    0010  f2 28 e4 2f 0a e0 fb 6e  a5 e6 9e 55 5b 6a 0c 4a
    0020  6f 81 b8 db 24 d5 14 c2  d2 d3 14 a4 5f c9 e1 2a
    0030  02 de 20 34 e8 84 b2 bd  a8 3c 33 db ed 7d cf 04
    0040  b3 00 91 13 f4 01 ec cc  8c 3a b4 4d 81 81 a4 2d
    0050  78 32 ad 9c 1b c9 cf c9  a1 b4 27 b0 b2 01 43 e0
    0060  26 c3 15 b6 ec 02 41 8f  3f 68 59 04 5d e2 52 13
    0070  8b e1 72 b6 a4 2d 6e 47  7e 90 dc 00 5b 7b 10 48
    0080  43 0f f7 10 3d 0b 0e bf  ff 5d 83 b2 1e 08 a1 08
    0090  6a 65 ef b7 6e 72 10 27  cb c6 25 17 e4 89 5d 6a
    00a0  b9 84 4f 94 95 0f c9 41  d6 a6 ba e2 fc 22 f9 59
    00b0  18 1c 61 21 63 6a dd 31  b8 a2 d4 5b 55 55 a3 2f
    00c0  e3 06 c6 b9 74 6b bd d9  f3 69 10 00 d3 e7 a9 82
    00d0  a7 69 f1 1e 28 af c0 82  a2 41 99 54 eb fc 91 c0
    00e0  14 3a 86 51 60 17 35 97  19 ec ed e6 13 7c 62 0c
    00f0  94 34 b7 1d 00 42 43 68  85 fe 7c c2 cb d6 a6 fe
    0100  e4 df 96 ff 2c f2 dc 57  5f 02 03 01 00 01
证书扩展: 9
    2.5.29.35: 标志 = 0，长度 = 18
    授权密钥标识符
        KeyID=78df91905feedeacf6c575ebd54c5553ef244ab6

    2.5.29.14: 标志 = 0，长度 = 16
    使用者密钥标识符
        4359f97cd0fecfa7486e1a2ad8ef84fc67c43bb6

    2.5.29.17: 标志 = 0，长度 = 1e
    使用者可选名称
        DNS Name=*.cnblogs.com
        DNS Name=cnblogs.com

    2.5.29.32: 标志 = 0，长度 = 37
    证书策略
        [1]Certificate Policy:
             Policy Identifier=2.23.140.1.2.1
             [1,1]Policy Qualifier Info:
                  Policy Qualifier Id=CPS
                  Qualifier:
                       http://www.digicert.com/CPS

    2.5.29.15: 标志 = 1(Critical)，长度 = 4
    密钥用法
        Digital Signature, Key Encipherment (a0)

    2.5.29.37: 标志 = 0，长度 = 16
    增强型密钥用法
        服务器身份验证 (1.3.6.1.5.5.7.3.1)
        客户端身份验证 (1.3.6.1.5.5.7.3.2)

    1.3.6.1.5.5.7.1.1: 标志 = 0，长度 = 74
    授权信息访问
        [1]Authority Info Access
             Access Method=联机证书状态协议 (1.3.6.1.5.5.7.48.1)
             Alternative Name:
                  URL=http://ocsp.digicert.com
        [2]Authority Info Access
             Access Method=证书颁发机构颁发者 (1.3.6.1.5.5.7.48.2)
             Alternative Name:
                  URL=http://cacerts.digicert.com/EncryptionEverywhereDVTLSCA-G2.crt

    2.5.29.19: 标志 = 1(Critical)，长度 = 2
    基本约束
        Subject Type=End Entity
        Path Length Constraint=None

    1.3.6.1.4.1.11129.2.4.2: 标志 = 0，长度 = 170
    SCT 列表
        v1
        4c63dc98e59c1dab88f61e8a3ddeae8fab44a3377b5f9b94c3fba19cfcc1be26
        2026年2月11日 14:32:09
        SHA256
        ECDSA
        304502204bca58da6c7ba0903c3fbe646a64eb663392634983080c66cdb8d99f21cf8fe2022100f5a20b8ddc8a170e7b6c129313f82a592b49cee739e2ed96a1c955c42a888022

        v1
        1c9f682ce9faf0456950f81b968a87dddb3210d84ce6c8b2e382524ac4cf599f
        2026年2月11日 14:32:09
        SHA256
        ECDSA
        3046022100a45feeb8e54d5c01509559aae9fc236d399b8f7bfa34bc35565d12bfb3e0830f022100d767a3851dbdb6c8149e3e2bb0ffdeb9652050f8d8eb8cfe8e8c239069accfb7

        v1
        604c9aaf7a7f775f01d406fc920dc899eb0b1c7df8c9521bfafa17773b978bc9
        2026年2月11日 14:32:10
        SHA256
        ECDSA
        3046022100bc275d9ccd6de790a05e86c39923a70342ea638b49f91a65b43686733280afee022100fe0fa562ba0ecb21df7236e8ccf3094fe83a5a67f822376a4a74952fad908366
    CT[0]:
      版本: 1
      密钥 Id 哈希(log-sha256): TGPcmOWcHauI9h6KPd6uj6tEozd7X5uUw/uhnPzBviY=
      密钥 Id 哈希(log-sha256-hex): 4c63dc98e59c1dab88f61e8a3ddeae8fab44a3377b5f9b94c3fba19cfcc1be26
      签名时间: 2026/2/11 14:32
      扩展: 0000
      哈希算法: 4 (SHA256)
      签名算法: 3 (ECDSA)
      时长: 0047
0000: 30 45                                     ; SEQUENCE (45 字节)
0002:    02 20                                  ; INTEGER (20 字节)
0004:    |  4b ca 58 da 6c 7b a0 90  3c 3f be 64 6a 64 eb 66
0014:    |  33 92 63 49 83 08 0c 66  cd b8 d9 9f 21 cf 8f e2
0024:    02 21                                  ; INTEGER (21 字节)
0026:       00
0027:       f5 a2 0b 8d dc 8a 17 0e  7b 6c 12 93 13 f8 2a 59
0037:       2b 49 ce e7 39 e2 ed 96  a1 c9 55 c4 2a 88 80 22
    找不到: TGPcmOWcHauI9h6KPd6uj6tEozd7X5uUw/uhnPzBviY=
    CT[1]:
      版本: 1
      密钥 Id 哈希(log-sha256): HJ9oLOn68EVpUPgbloqH3dsyENhM5siy44JSSsTPWZ8=
      密钥 Id 哈希(log-sha256-hex): 1c9f682ce9faf0456950f81b968a87dddb3210d84ce6c8b2e382524ac4cf599f
      签名时间: 2026/2/11 14:32
      扩展: 0000
      哈希算法: 4 (SHA256)
      签名算法: 3 (ECDSA)
      时长: 0048
0000: 30 46                                     ; SEQUENCE (46 字节)
0002:    02 21                                  ; INTEGER (21 字节)
0004:    |  00
0005:    |  a4 5f ee b8 e5 4d 5c 01  50 95 59 aa e9 fc 23 6d
0015:    |  39 9b 8f 7b fa 34 bc 35  56 5d 12 bf b3 e0 83 0f
0025:    02 21                                  ; INTEGER (21 字节)
0027:       00
0028:       d7 67 a3 85 1d bd b6 c8  14 9e 3e 2b b0 ff de b9
0038:       65 20 50 f8 d8 eb 8c fe  8e 8c 23 90 69 ac cf b7
    找不到: HJ9oLOn68EVpUPgbloqH3dsyENhM5siy44JSSsTPWZ8=
    CT[2]:
      版本: 1
      密钥 Id 哈希(log-sha256): YEyar3p/d18B1Ab8kg3ImesLHH34yVIb+voXdzuXi8k=
      密钥 Id 哈希(log-sha256-hex): 604c9aaf7a7f775f01d406fc920dc899eb0b1c7df8c9521bfafa17773b978bc9
      签名时间: 2026/2/11 14:32
      扩展: 0000
      哈希算法: 4 (SHA256)
      签名算法: 3 (ECDSA)
      时长: 0048
0000: 30 46                                     ; SEQUENCE (46 字节)
0002:    02 21                                  ; INTEGER (21 字节)
0004:    |  00
0005:    |  bc 27 5d 9c cd 6d e7 90  a0 5e 86 c3 99 23 a7 03
0015:    |  42 ea 63 8b 49 f9 1a 65  b4 36 86 73 32 80 af ee
0025:    02 21                                  ; INTEGER (21 字节)
0027:       00
0028:       fe 0f a5 62 ba 0e cb 21  df 72 36 e8 cc f3 09 4f
0038:       e8 3a 5a 67 f8 22 37 6a  4a 74 95 2f ad 90 83 66
    找不到: YEyar3p/d18B1Ab8kg3ImesLHH34yVIb+voXdzuXi8k=

签名算法:
    算法 ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    算法参数:
    05 00
签名: UnusedBits=0
    0000  98 f5 54 25 16 cb 27 c1  e5 5c cb d4 ce 11 ff 41
    0010  00 8a 05 0c ae d4 05 cb  a0 9c a2 7f 56 8e 4c d9
    0020  22 83 e2 2e d5 31 d5 0b  a4 f0 67 ee 44 e6 d0 3f
    0030  f7 4d dd 10 ac c9 56 a9  94 6d bf 08 1d 41 84 06
    0040  7b 9c d6 35 04 2d 91 91  0e dd 6e 35 d5 68 42 34
    0050  c8 e1 93 c5 6c fd 6f 37  ba e6 8f 13 c3 18 17 a2
    0060  c7 0c ca b0 e2 b2 df de  83 6a 13 f5 16 a3 e9 25
    0070  fe 88 2c 99 dd 5c 3e 56  a0 4f e0 75 cb d0 85 db
    0080  d3 7d 62 65 65 75 5c e0  94 62 ad 30 ec 1c 44 6f
    0090  63 63 ee 4a 38 0e 7c d1  f6 03 5b 6f f3 da 03 6d
    00a0  09 e5 1c 34 03 be c8 d1  c5 04 57 88 83 4c 9f ab
    00b0  cf db 5f 7d 9e 09 49 af  2f f2 82 68 77 6a f3 33
    00c0  7b 04 a3 67 e6 2b e8 15  b1 8b 8f 4c d3 9a a4 94
    00d0  91 c6 d0 e0 cd de 73 5e  36 cf 95 21 ad 27 e8 23
    00e0  3b f6 93 92 4d f1 26 ae  30 de d3 06 d5 f5 59 a6
    00f0  a1 93 02 fe 67 6e 1c 29  4a b6 36 41 8f 6c 2e 23
非根证书
密钥 Id 哈希(rfc-sha1): 4359f97cd0fecfa7486e1a2ad8ef84fc67c43bb6
密钥 Id 哈希(sha1): 5b2d58e803f3a0ff393454e4b756121d2f899382
密钥 Id 哈希(bcrypt-sha1): f6646e8471180600501a64fcb43fba8957c408f2
密钥 Id 哈希(bcrypt-sha256): 0a330e6465d2c9fefe63c9d2863d13aa676be78ffbdad89378324dbe0a1f445b
密钥 Id 哈希(md5): 9493edb1b28c96476e00fa148374bb9b
密钥 Id 哈希(sha256): 72ece2f965e8d69e8815ba134e0d470113cc4c0bf914927b0a7159808f2cd25d
密钥 Id 哈希(pin-sha256): RHE2ObhiCwniauTBOuyK1r+VzozZKG+iYAXi3E2mmPI=
密钥 Id 哈希(pin-sha256-hex): 44713639b8620b09e26ae4c13aec8ad6bf95ce8cd9286fa26005e2dc4da698f2
证书哈希(md5): e907a0889fa2be37fe74be01e4f87b1c
证书哈希(sha1): 3b6338281e0c80b3cc8660d8b48a912723cf854d
证书哈希(sha256): ed6a37dff671ace855dde5a1471a9e8ae0f87d8baeb7175a710effc4c117f146
签名哈希: 562c53fc6b5916e5b238942b780b5b1c080529ccf703bfcebe2cbe0139aa6f49
CertUtil: -dump 命令成功完成。
View Code

由此，我们可以看到该证书的证书类型为X.509证书。X.509 是国际电信联盟（ITU-T）制定的一套公钥证书标准。它规定了，证书里应该包含哪些字段（版本、序列号、颁发者、使用者、公钥、有效期、扩展、签名等）。这些字段用什么格式编码（ASN.1 + DER）。证书如何签名和验证。

‌ASN.1（Abstract Syntax Notation One，抽象语法标记一）‌ 是由国际电信联盟（ITU-T）制定的国际标准，核心作用是定义一套完全独立于编程语言、硬件架构的跨平台数据描述规则，解决不同系统间数据交换的一致性问题 。ASN.1是现代互联网安全体系的底层基石，几乎所有密码学相关的标准协议都依赖它，比如X.509数字证书、HTTPS/TLS协议、PKI公钥基础设施。

‌ASN.1+DER（Distinguished Encoding Rules）‌ 是现代信息安全、通信协议及数据交换领域的基石组合。简单来说，‌ASN.1 是定义数据结构的“蓝图”，而 DER 是将该蓝图转化为唯一二进制字节流的“严格施工规范”‌。

证书中包含了公钥，下面我们看看证书中的公钥信息

    0000  30 82 01 0a 02 82 01 01  00 d3 69 c0 a6 ef 78 83
    0010  f2 28 e4 2f 0a e0 fb 6e  a5 e6 9e 55 5b 6a 0c 4a
    0020  6f 81 b8 db 24 d5 14 c2  d2 d3 14 a4 5f c9 e1 2a
    0030  02 de 20 34 e8 84 b2 bd  a8 3c 33 db ed 7d cf 04
    0040  b3 00 91 13 f4 01 ec cc  8c 3a b4 4d 81 81 a4 2d
    0050  78 32 ad 9c 1b c9 cf c9  a1 b4 27 b0 b2 01 43 e0
    0060  26 c3 15 b6 ec 02 41 8f  3f 68 59 04 5d e2 52 13
    0070  8b e1 72 b6 a4 2d 6e 47  7e 90 dc 00 5b 7b 10 48
    0080  43 0f f7 10 3d 0b 0e bf  ff 5d 83 b2 1e 08 a1 08
    0090  6a 65 ef b7 6e 72 10 27  cb c6 25 17 e4 89 5d 6a
    00a0  b9 84 4f 94 95 0f c9 41  d6 a6 ba e2 fc 22 f9 59
    00b0  18 1c 61 21 63 6a dd 31  b8 a2 d4 5b 55 55 a3 2f
    00c0  e3 06 c6 b9 74 6b bd d9  f3 69 10 00 d3 e7 a9 82
    00d0  a7 69 f1 1e 28 af c0 82  a2 41 99 54 eb fc 91 c0
    00e0  14 3a 86 51 60 17 35 97  19 ec ed e6 13 7c 62 0c
    00f0  94 34 b7 1d 00 42 43 68  85 fe 7c c2 cb d6 a6 fe
    0100  e4 df 96 ff 2c f2 dc 57  5f 02 03 01 00 01

其遵循DER编码规范

30 SEQUENCE标签（构造类型，0x30 = 0b00110000）
82 这一字节表示长度编码方式，82表示后面用 2 个字节表示长度
01 0a 长度值：0x010a = 266 字节

image

02 INTEGER标签
82 长度编码方式：后面用 2 个字节 表示长度
01 01 长度值：0x0101 = 257 字节

image

 而上面得到的公钥为257字节，注意最开始1字节为00，因此去掉最开始的00填充，实际的公钥长度为256字节，256*8=2048位。也就是这个公钥是二进制2048位的。

副2 .der证书和.pem证书区别

首先，简单介绍一下什么是PEM编码，PEM编码就是把二进制数据（比如证书或密钥）转成纯文本格式，方便存储和传输。通常我们还加上头尾标志保存，比如证书就是-----BEGIN CERTIFICATE-----开头，-----END CERTIFICATE-----结尾。RSA私钥就是-----BEGIN RSA PRIVATE KEY-----开头，-----END RSA PRIVATE KEY-----结尾。

它们描述的是同一张证书的两种"存放方式"：
.der = 二进制格式（ASN.1 DER 编码）
.pem = 文本格式（把 DER 做 Base64 编码，再加头尾标记）
两者内容完全等价，可以无损互相转换。

相互转换示例

openssl x509 -in cert.pem -outform DER -out cert.der
openssl x509 -in cert.der -inform DER -outform PEM -out cert.pem

 

posted @ 2023-03-25 17:05  zhenjingcool  阅读(946)  评论(0)    收藏  举报