SSL证书相关的加密算法有哪些？

更新时间：2026-01-29 来源：TopSSL技术团队

SSL/TLS 证书与 HTTPS 通信涉及的加密算法按功能分四大类：

国密算法体系（SM2、SM3、SM4）是国内政企、金融场景在国密 TLS 协议下的自主密码方案。

对部署者来说，真正需要主动选择的算法主要是证书公钥类型：RSA 兼容性最广、ECC 性能更高、SM2 面向国密合规，其余算法组合一般由 TLS 版本和服务器默认配置决定。本文逐类说明各算法的定位、现状与选择依据，供证书采购和 HTTPS 部署时对照参考。

证书公钥与签名算法

这一类决定证书本身的密钥类型，以及 CA 机构对证书的签名方式，对应证书的"身份"部分。

RSA 是最经典的非对称算法，兼容性最好，几乎所有新旧设备和系统都支持。目前通用标准的密钥长度是 2048 位或 4096 位，对兼容老旧终端有要求的站点仍然以它为主。

ECC（ECDSA）基于椭圆曲线，密钥更短、计算效率更高。256 位 ECC 的安全强度约相当于 3072 位 RSA，服务器 CPU 负载和握手延迟都更低，是现代网站的主流选择，适合高并发站点和移动端 API。

Ed25519（EdDSA）是高性能椭圆曲线签名算法，在 TLS 1.3 和部分新型证书场景中开始出现，目前普及度还在上升阶段。

证书里的密码参数结构，可以对照数字证书的内容构成理解。

这一类在 HTTPS 握手时协商出临时通信密钥，决定"这把锁怎么换成两个人共用的钥匙"。

ECDHE 基于椭圆曲线的临时 Diffie-Hellman 算法，核心优势是前向安全性：即使服务器私钥泄露，历史通信流量也无法被解密。TLS 1.2、TLS 1.3 都推荐使用。

DHE 是传统临时 DH 算法，性能低于 ECDHE，正在逐步退出主流。RSA 密钥交换是早期机制，不支持前向安全性，在 TLS 1.3 中已不再提供。

握手环节的算法组合实际由服务端 TLS 配置决定，部署后用TLS 配置检测可以确认当前协商结果和安全性评级。

握手完成后，网页内容、接口数据的实际加密靠这一类，对应"锁"本身。

AES 是全球通用的分组对称加密标准，配合 GCM 模式提供 AEAD 认证加密，现代 CPU 普遍有硬件指令集加速（AES-NI），是当前默认选择。

ChaCha20-Poly1305 是流加密算法，在没有 AES 硬件加速的低端移动设备上性能更好，TLS 1.3 中作为备用方案存在。

3DES、RC4 属于早期算法，存在已知安全缺陷，已被现代浏览器和标准淘汰，不应再启用。

哈希算法用于完整性校验和证书指纹，保证"数据没被改过"。

SHA-2 系列（SHA-256、SHA-384）是当前公共 SSL/TLS 证书签名的标准哈希算法，所有新签发证书都使用它。

SHA-1、MD5 存在严重碰撞攻击风险，主流 CA 已停止签发 SHA-1 及以下级别的证书，浏览器也不信任。

国内政企、金融、国企场景在国密 TLS 协议（TLCP）下使用自主密码体系，对应关系很整齐：SM2 是国密非对称加密与签名算法（对应 RSA/ECC），SM3 是国密哈希算法（对应 SHA-256），SM4 是国密分组对称加密算法（对应 AES）。

国密证书的适用范围和 RSA/ECC 不同，需要配合国密协议栈和特定终端使用，具体边界可以参考证书类型怎么选。

对比维度	RSA 证书	ECC (ECDSA) 证书	国密 SM2 证书
安全机制	大整数因数分解难题	椭圆曲线离散对数难题	国家商用密码算法标准
常见密钥长度	2048 位 / 4096 位	256 位 / 384 位	256 位
运算效率	相对较低，握手消耗较多算力	高，CPU 与内存占用少	需硬件密码机或专用软解支持
客户端兼容性	覆盖主流平台与老旧设备	覆盖主流系统（Android 4.0+ 及现代系统）	仅限国密浏览器与特定客户端
适用场景	需兼容老旧终端的站点	高并发站点、移动端 API、云原生应用	政企、金融、密评合规项目