打开加密之门的两把钥匙 ～公开密钥与私钥的原理以及守护互联网的加密技术

请想象，在你面前有一个“保险箱”。
这个保险箱用来存放诸如“银行账户密码”或“个人信息”等不容被他人看到的重要信息。
但是，这个保险箱有点特别。要打开或关闭，需要两把钥匙。

• 一把是“任何人都能使用的钥匙” → 这就是公钥
• 另一把是“只有自己持有的钥匙” → 这就是私钥

这两把钥匙有着一种神奇的联系。

• 用公钥给保险箱上锁（= 加密）后，只有私钥才能打开（= 解密）
• 反过来，如果用私钥上锁，就可以用公钥打开

于是，任何一方“上锁”后，只有另一方才能打开。
由于它们互补有益，这种加密方式称为**“非对称密钥加密”**。

“用一把钥匙开锁和锁门，不是更简单方便吗？”
这样想也无可厚非。实际上，在所谓的“对称密钥加密”方式中，只用一把钥匙就能完成加密和解密。
但是，这种方式存在一个大问题。那就是“如何将钥匙安全地交给对方？”

假设你想通过邮件把重要信息发送给某人。
如果对内容进行加密，就不用担心被窃听。
但对于“对称密钥加密”，需要有一种安全地将该钥匙传递给对方的方法。
如果钥匙被盗，将大大增加信息泄露和冒充的风险。
而且，如果有多个对象，就要对每个对象都分别用安全方式发送钥匙。

这时登场的就是“公钥加密方式”。
在这种方式中，公钥可以“分发给任何人”，是其优势所在。
例如，如果你用对方的公钥对邮件加密，只有该对方的私钥才能解密，因此可以安全地进行信息交换。

这两把钥匙不仅可以用于加密，还可以用于**“身份验证”。
举例来说，如果对某个文档（如：合同、邮件等）使用私钥进行签名**，则可以用对应的公钥来验证该签名。
由此就能证明“确实是本人发送了该文档”。
利用该机制的是“电子签名”和“数字证书”。

公钥加密有以下两种用途：

1. 安全隐藏（加密） → 使用公钥加密，使用私钥解密
2. 身份验证（签名） → 使用私钥签名，使用公钥验证

表格如下：

公钥和私钥——这两把钥匙支撑的不仅仅是邮件。
网上银行、网购、云服务……。
我们的互联网生活正是由这项加密技术所守护。

让我们用一个小故事来解释“加密”与“签名和认证”的机制吧。

在某个城镇里住着一个名叫“A子”的女性。
她有一个叫“B男”的恋人。
两人分居异地，又是没有电话的年代，通信手段仅限于书信。
一天，A子想给B男寄一封秘密信件。由于是秘密信件，如果在投递途中被人读到就麻烦了。
于是A子决定使用某位魔法师送给她的**“两把钥匙”**。

首先，A子拜托B男将那把“任何人都能用的B男的钥匙（公钥）”放在一个所有人都能看见的地方。
B男公布自己的“公钥”后，A子就拿到了它。
（这把公钥不仅A子，其他任何人都能获得。）
A子写好信件，使用B男的公钥给信件上锁（= 加密），然后像往常一样委托邮差寄给B男。
不久后，B男收到了A子的那封“用公钥上锁的信件”。
B男用仅自己持有的私钥打开锁（= 解密），阅读了A子的信件。
这里重点在于，即使途中有人偷了信件，没有私钥也无法读取信件内容。
也就是说，不用担心通信内容被第三方泄露。

话说，在城镇边缘住着一个名叫“C子”的坏女人。
如果C子靠近A子，谎称“这是B男的钥匙（公钥）”，并把C子的公钥交给她，会发生什么呢？
如果A子信以为真，用那把假钥匙写信并上锁后寄出……
C子就能在途中偷到信件，并用自己的私钥打开。
（因为A子使用的是C子的公钥，与之匹配的私钥也是C子的。）
当然，B男无法打开那封信，因为信是用C子的钥匙上了锁，而非他的钥匙。

为防止这一问题登场的就是**“证书”。
事实上，B男的公钥上有一份由可信第三方（CA）签名“这把钥匙属于B男”的声明。
将这一第三方称为Certificate Authority（CA，认证机构）。
A子通过验证这个签名，就能确认“这把钥匙确实属于B男”**。
反过来，C子没有从认证机构获得签名，所以A子能判定C子的钥匙“并不可信”。

※ 关于“签名与验证”的详细机制稍后解释。
在此只需理解“私钥和公钥的关系中，存在一种可实现身份验证的机制”。

我们每天访问的很多网站都是以 https://〜 （在“http”后面加了个“s”） 开头。
HTTPS是“Hypertext Transfer Protocol Secure”的缩写。
与普通HTTP相比，其最大特点是通信内容被加密了。
在这些网站中，“两把钥匙（公钥和私钥）”和“证书”扮演着重要角色。

支撑该机制的是作为可信第三方的CA（认证机构）。
CA的角色如下：

• 确保公钥的所有者确实是该人（或该域名）
• 发放数字证书（如：服务器证书）

浏览器和操作系统事先保有可信CA列表，自动信任该列表中CA所签发或签名的证书。
那么，让我们详细了解一下“证书”。

让我们来看看CA与证书之间的关系，以及信任机制。

证书（数字证书）具有如下结构。
X.509是ITU-T的公钥基础设施（PKI）标准，被采用为数字证书的标准格式。
※ ITU-T（International Telecommunication Union Telecommunication Standardization Sector）是“国际电信联盟电信标准化部门”。

证书链（信任链）是用来验证SSL/TLS证书是否可信的机制。
多个证书以**层次结构（链式）**相连。
最终通过到达“受信任的根证书”来保证整体的可信性。
例如，浏览器的信任列表（证书链）如下所示：

[浏览器的信任列表]
        ↓
  根CA（根认证机构）
        ↓（签名）
  中间CA（中间认证机构）
        ↓（签名）
  服务器证书（例如：example.com）

整理一下上文提到的认证机构与证书的关系。

• Root CA（根认证机构）
  • 信任的起点。预先集成在操作系统和浏览器中。（这非常重要）
  • 因使用极为重要的私钥，通常不会直接签发服务器证书。
• Intermediate CA（中间认证机构）
  • 是由Root CA委任信任的认证机构。
  • 承担实际签发服务器证书的角色。
• 服务器证书（例如：example.com）
  • 网站所使用的证书，由Intermediate CA签发和签名。

Root CA的私钥极为重要，因此从安全角度不会直接签发证书。
通过设置Intermediate CA，以分层方式分散信任，最大限度地降低风险。

证书是由作为“可信第三方”的**CA（认证机构）**进行“签名”的。
之所以可以信任这个第三方（CA），是因为它包含在OS和浏览器预先登记的“受信任CA列表”中。
要列入该列表，CA必须通过严格审核并满足高安全性要求。

即，这是一个“只要是该CA签名的公钥，就判断该公钥的持有者是真实可信的”机制。
该机制通过预先集成在我们的PC或智能手机中的“可信CA列表（信任列表）”来实现。

签名是保证“该证书是合法有效的”电子担保。
认证机构（CA）对整个证书进行签名，从而保证其内容的可信性。

打个比方，CA就像“由官方机关颁发的身份证”一样的存在。
个人无法自行签发，但如果机关证明“此人就是本人”，别人就能安心地信任他。

下面说明电子签名机制的概要。

1. 哈希生成

CA对证书的签名对象部分（TBSCertificate）进行哈希处理（例如：SHA-256）。
※SHA-256是一种哈希函数，用于从输入数据生成固定长度256位的哈希值，属于SHA-2家族。

签名对象部分包含的主要信息如下：

• 公钥（例如：example.com）
• 域名（CN：通用名）
• 有效期
• 签发者（Issuer）
• 标识信息（例如序列号）

2. 创建签名

将该哈希值使用CA的私钥加密。
此加密结果即为电子签名（signature）。

3. 证书的构成

将以下信息汇总并构造成证书（X.509证书）：

• TBSCertificate（签名对象部分）
• signatureAlgorithm（使用算法）
• signature（电子签名）

浏览器在收到上述证书后，如何验证其内容呢？
下面说明验证机制的概要。

1. 验证公钥的签名

浏览器用CA的“公钥”解密证书的签名部分，取出哈希值。

2. 两个哈希值

浏览器自行对证书的TBSCertificate（签名对象部分）进行哈希处理。
哈希处理使用signatureAlgorithm（例如SHA-256）。

此时会得到以下两项：

• 从证书的“签名”中提取的“哈希值”
• 对证书的TBSCertificate进行哈希处理得到的“哈希值”

3. 对比和链式验证

如果两个哈希值一致，就判断证书未被篡改且可信。
同时，浏览器还会确认证书链是否可信（是否能追溯到根证书、中间证书是否有效等）。

电子签名保证“该公钥确实属于example.com，并由可信的认证机构验证和签发”。

我们将以上内容汇总成表格。

下面是公钥和私钥的对比表：

公钥、私钥与证书的关系如下：

当你在浏览器中访问https://example.com时，会进行如下交互。

• 浏览器向服务器发出“想使用TLS通信！”的通知。
• 并提供支持的TLS版本及密码套件（加密方式组合）。
  ※TLS（Transport Layer Security）是一种在互联网上对通信进行加密、确保安全的协议。主要用于网站通信及邮件等的安全通信。

• 服务器发送公钥和由CA（认证机构）签名的证书。
• 证书中写明“此公钥属于 example.com”，并通过CA的签名保证真实性。

• 验证证书的发行者（CA）是否可信（是否有注册在操作系统或浏览器中的根CA签名）。
• 还会检查有效期和域名是否匹配。
• 若无问题，就判定“此公钥可信”。

• 浏览器生成对称密钥（会话密钥），并用服务器的公钥加密后发送。
  ※由于用公钥加密的信息，若无对应私钥就无法解密，因此可安全地传递对称密钥。

• 服务器用私钥解密对称密钥，获取与浏览器相同的对称密钥。

• 之后的通信都用**对称密钥加密（例如：AES）**进行加密和解密。
• 可以高速高效地交换大量数据。

也就是说，公钥加密用于最初的密钥交换，之后使用高速的对称密钥加密进行通信。

对称密钥加密（共钥加密）是指用相同的密钥进行加密和解密的方式。
典型例有AES。
例如，若发送者和接收者事先共享了对称密钥，就可使用该密钥进行加密和解密。

在现代通信（如HTTPS）中，先用公钥安全地进行密钥交换 → 再用对称密钥进行主体加密的混合方式最为普遍。

Root CA证书到底存放在哪里呢？
Windows、macOS、Linux等操作系统中都有“受信任的根证书存储区”，主要的Root CA证书已预装其中。
浏览器会引用操作系统的存储区，或使用自己的存储区。

操作系统或浏览器的开发者（如Microsoft、Apple、Google、Mozilla等）会对Root CA进行审核，仅将被认可安全的CA纳入。
添加或移除都需严格审核和日志管理。
普通用户很难擅自篡改该存储区（需要管理员权限）。

信任基础被破坏，所有通信的安全都将受到威胁（例如：DigiNotar事件）。
为此，引入了以下机制：

• 证书透明度（Certificate Transparency）日志
• OCSP / CRL（证书吊销列表）
• 证书固定（只信任特定证书）

Root CA是将人类社会的信任关系反映到数字世界的存在。归根结底，技术上的信任也基于人的判断。

在大致理解了HTTPS机制之后，我们来实际搭建一个Web服务器试试看。
首先，使用“自签名证书”搭建服务器。

自签名证书（self-signed certificate）是证书的发行者（CA：认证机构）与证书所有者相同的数字证书。
也就是说，对自己的公钥自行签名，以此证明其合法性的一种证书形式。
（※俗称：伪造证书）
由于此类证书不存在可信第三方的认证，因此在浏览器等客户端中会被视为“不可信证书”。
因此，从认证角度来看并不充分，但可以通过自签名证书体验HTTPS的加密通信机制本身。

首先，创建自签名证书。
执行以下命令：

openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365

命令说明如下：

• openssl：启动OpenSSL命令行工具，它是一个用于处理SSL/TLS协议及各种加密技术的开源库。
• req：该子命令用于创建和管理证书签名请求（CSR - Certificate Signing Request），以及生成自签名证书。“req”即“request”的缩写。
• -x509：指示创建自签名证书（self-signed certificate），不经过CA（认证机构）签名。
• -newkey rsa:2048：生成新的RSA密钥对（2048位），包含私钥和公钥。
• -nodes：以不加密的方式保存私钥，省去输入密码的步骤，不过安全性降低，适用于自动化场景。
• -keyout key.pem：指定将生成的私钥保存到名为key.pem的文件。
• -out cert.pem：指定将生成的证书保存到名为cert.pem的文件。
• -days 365：将证书的有效期设置为365天。

※这里的-nodes意为No DES encryption，即不加密私钥（server.key）。
通常私钥文件会用密码保护，加上-nodes后就会变成无需密码、任何人都能读取。
请仅在开发或本地环境使用-nodes选项，不要在生产环境使用，生产环境建议对私钥进行加密保护。

执行上述命令后，系统会要求输入一些信息。如下所示：

• Country Name (2 letter code) [AU]：要求输入国家代码（2位），例如JP（日本）、US（美国）等。
• State or Province Name (full name) [Some-State]：要求输入省/州名称，例如“Tokyo”或“California”。
• Locality Name (e.g., city) []：输入城市/地区名，例如“Tokyo”或“New York”。
• Organization Name (e.g., company) []：输入组织名称（公司或团体），个人可随意填写。
• Organizational Unit Name (e.g., section) []：输入组织部门名称，例如“IT部门”或“开发团队”。
• Common Name (e.g., server FQDN or YOUR name) []：输入服务器的完全限定域名（FQDN）或证书对应的名称，例如example.com，本地主机则填写localhost。
• Email Address []：输入电子邮件地址，可选，但可用作证书联系信息。

以上信息用于识别证书所有者。对于自签名证书，由于没有认证机构（CA）的签名，这些信息仅用于指示证书创建者。

回答完提示信息后，就会生成私钥和证书，并保存到key.pem和cert.pem。

如果你觉得逐一回答提示太麻烦，可以使用以下方式直接生成私钥和证书：

openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365 \
  -subj "/C=JP/ST=Tokyo/L=Shibuya/O=MyCompany/CN=localhost/emailAddress=you@example.com"

本次我们使用Python创建Web服务器应用。
首先，安装Web服务器框架Flask。

pip install flask

接下来创建Python程序（示例：sample.py）：

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
  return 'Hello, this is a secure HTTPS server!'

if __name__ == '__main__':
  app.run(
    ssl_context=('cert.pem', 'key.pem'), 
    host='0.0.0.0', 
    port=8443
  )

在Linux中，若端口号小于1024（例：443），需要root权限。由于是实验，改为使用8443端口以避免使用sudo。

在Flask应用中使用HTTPS时，如果证书或私钥文件权限不正确，可能会出现Permission denied错误。
要为证书文件设定适当权限，可执行以下命令：

chmod 600 cert.pem key.pem

运行应用：

python sample.py

通信时的交互大致如下：
cert.pem（证书）和 key.pem（私钥）的交换发生在称为TLS握手的过程中。下面是该机制的示意图：

在浏览器中访问 https://localhost:8443/ 时，页面显示“未受保护的通信”，如下所示：

“未受保护的通信”这一提示表示浏览器不信任该证书。
但在本地使用自签名证书时，这是正常现象。
由于这是“自签名证书”，自然不会被任何人“信任”。
仅用于开发和测试时，没有问题。

在企业内部搭建Web服务器时，很多人可能会认为“仅供内部使用，HTTP就足够了”。
然而，也可能会遇到其他部门指出“安全意识太低。即使是在内部，也有关联公司的员工常驻，应当全面使用HTTPS通信”。
更有可能的情况是，急忙将自签名证书作为HTTPS方案部署后，又被告知“自签名证书无法保证可信度，应走正规流程”，然后接受更多指导……。

因此，本次将演示在本地环境搭建私有认证机构（CA），并使用该CA签发的服务器证书（SSL证书）实现HTTPS通信的完整流程。
本章将在本地环境中实践以下步骤：

• 在个人PC（或内网服务器）上搭建“私有认证机构（本地CA）”
• 使用搭建的本地CA对服务器证书进行签名并发行
• 将发行的服务器证书应用到Flask服务器
• 让客户端（浏览器）信任本地CA的根证书
• 验证在浏览器访问时显示“已保护的通信”

除去搭建本地CA并由其签发证书这一点外，服务器端和客户端的通信设置基本思路与使用自签名证书时并无太大差别。

创建CA的私钥。
执行以下命令：

openssl genrsa -out myCA.key 2048

命令说明如下：

• genrsa：生成RSA密钥对的命令。
• -out myCA.key：将生成的私钥保存到名为myCA.key的文件。
• 2048：密钥长度（此例为2048位，在安全性和性能之间有良好平衡，也有使用3072或4096位的情况）。

创建CA的自签名证书。（有效期10年）
执行以下命令：

openssl req -x509 -new -nodes -key myCA.key -sha256 -days 3650 -out myCA.crt

命令说明如下：

• -new：生成新的证书/CSR。
• -key myCA.key：指定用于自签名的私钥文件（即上一步创建的CA私钥）。
• -sha256：指定使用SHA-256作为证书签名的哈希算法（目前推荐的安全方式）。

如果你觉得逐一回答提示太麻烦，可以使用以下方式直接生成证书：

openssl req -x509 -new -nodes -key myCA.key -sha256 -days 3650 -out myCA.crt \
  -subj "/C=JP/ST=Tokyo/L=Shibuya/O=MyCompany/CN=localhost/emailAddress=you@example.com"

※ myCA.crt即为根证书。信任该证书后，浏览器将信任该CA签发的所有证书。

近年来的浏览器和客户端通常不仅检查CN（通用名），还要求**SAN**中包含主机名，否则会将证书视为无效。
SAN（Subject Alternative Name）是一个扩展字段，用于在证书中指定多个FQDN（主机名）或IP地址。

在使用OpenSSL生成SSL/TLS证书（特别是CSR）时，需要一个配置文件（*.cnf）来设置SAN扩展。
创建配置文件openssl-san.cnf：

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = v3_req
prompt             = no

[ req_distinguished_name ]
C  = JP
ST = Tokyo
L  = Shibuya
O  = MyCompany
CN = localhost

[ v3_req ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = localhost

使用以下命令生成服务器私钥(server.key)和带SAN的CSR(server.csr)：

# 创建服务器私钥
openssl genrsa -out server.key 2048
# 生成带SAN的CSR
openssl req -new -key server.key -out server.csr -config openssl-san.cnf

要发行服务器证书，需要将之前生成的CSR（证书签名请求：server.csr）使用本地CA（myCA.crt、myCA.key）的私钥进行签名，以生成正式的服务器证书。
此外，由于近年来浏览器将SAN视为必需项，因此还需指定包含SAN信息的配置文件（openssl-san.cnf）。
使用以下命令签发带SAN的签名证书（server.crt）：

# 生成带签名的证书（含SAN）
openssl x509 -req -in server.csr -CA myCA.crt -CAkey myCA.key -CAcreateserial -out server.crt -days 825 -sha256 -extensions req_ext -extfile openssl-san.cnf

至此，已获得签名过的证书server.crt。

将获得的server.key和server.crt应用到Web服务器。
示例程序如下（例如：sampleCA.py），其基本结构与之前使用自签名证书时的Flask应用相同：

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
    return "Hello from CA signed HTTPS server!"

if __name__ == '__main__':
    app.run(
        ssl_context=('server.crt', 'server.key'),
        host='0.0.0.0',
        port=8443
    )

双击myCA.crt或通过浏览器设置将其注册到“受信任的根认证机构”。
若浏览器为Chrome，使用的是操作系统的证书存储，只需在操作系统中注册即可。

以Windows为例，操作步骤如下：

• 按Win键+R → 输入 mmc → 回车
• “文件”→“添加/删除管理单元”
• 选择“证书”→“计算机账户”→“本地计算机”→ 确定
• 在左侧选择“受信任的根证书颁发机构”→右键“证书”→“所有任务”→“导入”
• 选择myCA.crt文件完成导入

查看已注册的证书：

运行应用：

python sampleCA.py

在浏览器中访问 https://localhost:8443/，页面显示“此连接已受保护”，如下：

至此，实现了“受保护的通信”。

使用的密钥和证书文件如下：

本地CA签名证书的要点如下：

• 可按实际HTTPS通信的流程创建并使用SSL证书。
• 在浏览器中信任本地CA后，显示“此连接已受保护”与真正CA的表现一致。

本次介绍了看似平常却易被忽视的技术“公钥与私钥”的机制。
公钥加密支撑着我们日常的网络生活。
希望本文能帮助你对**HTTPS的“锁形图标”**的含义有更深理解。