Appearance
RSA、ECC 与国密 SM1–SM4：算法分别负责什么？
申请证书时先选择服务器和客户端共同支持的公钥算法，再检查配套链及 TLS 配置。下文按证书选型、算法职责和国密协议分别介绍。
初次接触这些概念，可以先读公钥、私钥与数字证书。
RSA 与 ECC 证书如何选择？
| 实际需求 | 选择时看什么 |
|---|---|
| 沿用既有 RSA 环境 | 确认产品密钥长度、证书 KU、握手签名方案和目标客户端支持。RSA 配合 ECDHE 也可提供前向保密。 |
| 评估 ECC/ECDSA | 确认具体曲线、服务器及所有目标客户端支持，再测试完整证书链和业务连接。 |
| 同时兼容 RSA/ECDSA | 确认入口支持双证书选择，分别使用目标客户端测试两个分支。 |
| 需要国密 HTTPS | 确认客户端、服务端及中间网关支持目标协议，再准备对应 SM2 证书和配置。 |
RSA：关注密钥长度、签名与客户端能力
RSA 在网站证书和既有设备中应用广泛。申请时选择产品支持的密钥长度，并核对终端、网关和密码设备的能力。常见 RSA 证书可以用于 ECDHE_RSA 认证，也可以在 TLS 1.3 中配合相应签名方案使用。
传统 TLS_RSA_* 密钥传输与 ECDHE_RSA 是不同握手方式。需要前向保密时，应检查协商方式，参见前向保密与套件检测。
ECC：关注具体曲线与签名方案
ECC 是算法家族；网站产品常见的是 ECDSA 证书，曲线如 P-256、P-384。较短的 EC 密钥可以达到与更长 RSA 密钥相当的经典安全强度，证书和签名通常也更紧凑。
例如，NIST SP 800-57 Part 1 Rev. 5 的经典安全强度对照中，RSA 3072 位与 256 位级别的椭圆曲线约对应 128 位安全强度。密钥位数需要结合算法解释；运行性能还取决于签名或验签操作、实现及硬件。
选择时确认实际客户端支持目标曲线、签名算法、TLS 配置与信任链。需要同时提供 RSA/ECDSA 双证书时，还应核对服务端的双证书选择能力，并分别验收两种握手。
区分证书公钥算法与证书签名算法
查看证书时：
Public Key Algorithm描述证书主体持有的公钥。Signature Algorithm描述上级 CA 对这张证书进行签名的方法。
两者分别对应主体密钥与签发者密钥。部署时，按主体公钥确定匹配私钥，再检查链上签名算法的兼容性。
一张表看懂分工
以下按用途列出常见算法，其中 SM1–SM4 分别承担不同的密码运算职责。
| 名称 | 类型 | 主要作用 | 在证书或 TLS 中如何遇到 |
|---|---|---|---|
| RSA | 公钥密码体系 | 按具体方案用于签名或公钥加密 | RSA 证书；TLS 身份认证签名；旧 TLS 中也存在 RSA 密钥传输 |
| ECC | 椭圆曲线密码体系的统称 | 承载不同的签名或密钥协商算法 | 申请界面中的 ECC 通常指用于 ECDSA 认证的 EC 公钥证书 |
| ECDSA | 椭圆曲线数字签名算法 | 生成与验证签名 | CA 证书签名或握手身份认证 |
| ECDHE | 临时椭圆曲线密钥交换 | 协商共享秘密，支持前向保密 | 可与 RSA 或 ECDSA 身份认证配合 |
| SM1 | 对称分组密码算法 | 使用共享秘密密钥加解密数据 | 通常由相应密码芯片或设备提供能力 |
| SM2 | 椭圆曲线公钥密码算法系列 | 包括数字签名、公钥加密和密钥交换机制 | 国密证书公钥、签名及相应协议中的密码操作 |
| SM3 | 密码杂凑算法 | 生成 256 位摘要，参与签名、消息认证或密钥派生 | SM2/SM3 签名、国密协议的杂凑机制 |
| SM4 | 对称分组密码算法 | 使用 128 位密钥、128 位分组加解密数据 | 在支持的协议中配合 GCM、CCM 等模式保护业务数据 |
| SHA-256 | 密码杂凑算法 | 生成 256 位摘要 | 证书指纹、数字签名及 TLS 中的相关机制 |
什么是杂凑（哈希）算法？
杂凑算法用于把一段数据计算成固定长度的摘要，可以把摘要理解为数据的“指纹”。 同一份数据使用同一种算法计算，结果相同；数据发生变化时，摘要通常也会变化，因此可以用来辅助检查文件是否一致。
SHA-256 和 SM3 都生成 256 位摘要，但计算规则不同。杂凑用于单向生成摘要；验证文件来源时，将摘要与可信渠道提供的值比较，或检查数字签名。
在证书和 HTTPS 中有什么用？
| 使用场景 | 作用 |
|---|---|
| 核对证书指纹 | 对证书计算摘要，比较本地与线上证书是否一致；常用 SHA-256 |
| 数字签名 | 配合签名算法处理待签名的数据，帮助验证完整性和签名来源 |
| 消息认证 | 与秘密密钥结合，用于 HMAC 等机制 |
| 密钥派生 | 按 TLS 规则参与从共享秘密生成流量密钥 |
例如，比较线上与本地新证书的 SHA-256 指纹，可判断本次连接收到的是否为预期证书，命令见更新未生效排查。
国密 SM1–SM4 如何理解？
SM1：对称密码设备能力
SM1 是对称分组密码，算法细节未公开，通常通过相应密码芯片或设备接口使用。在证书部署中，应按设备文档确认其提供的密码能力和接口；网站证书的公钥类型通常讨论 RSA、EC 或 SM2。
SM2：证书与公钥密码机制
SM2 基于椭圆曲线，标准系列覆盖签名、密钥交换和公钥加密。SM2 签名有自身的计算规则和标识参数，使用时需确认协议栈明确支持 SM2。
SM3：摘要与完整性机制中的基础运算
SM3 将输入映射成 256 位摘要。摘要用于签名、消息认证或派生机制时，需要与对应密钥和协议规则结合。哈希是单向运算；文件是否可信还取决于摘要的来源以及签名或认证校验。
SM4：业务数据的对称加密
SM4 的密钥长度和分组长度均为 128 位。实际通信还需要选择工作模式、正确管理随机数或 nonce，并实现完整性保护。这些应由符合目标协议的密码库完成。
部署国密 HTTPS 时核对什么？
- 明确协议：确定目标环境使用 TLCP 还是支持国密算法的 TLS 1.3 等具体方案。
- 确认材料：TLCP 双证书部署通常分别使用签名证书、加密证书及对应私钥；按目标产品要求准备完整材料。
- 确认协议栈：客户端、代理、服务器及密码库均需支持所选协议、算法和证书用途。
- 确认信任链：目标客户端需接受适用信任锚，服务器提供配套中间链。
- 按实际客户端验收：分别验证公网入口和 HTTPS 回源链路。
RFC 8998 描述的是 TLS 1.3 的国密算法配置：SM2 签名用于认证，SM3 用于杂凑，SM4-GCM/CCM 用于记录保护，密钥交换采用 SM2 曲线上的 ECDHE。它是信息类 RFC，与 TLCP 双证书配置应分别理解。
KeyManager 目前支持的导出能力以下载指南为准，其中国密证书暂不支持导出为 JKS/PFX。格式封装、算法支持和协议兼容性需要分别确认。
下一步
- 选择交付文件：PEM、DER、PFX 与 JKS。
- 了解客户端信任：信任链构建与验证。
- 确认服务器加载方式：各环境证书维护逻辑。