自签名证书和 CA 签名证书有什么区别
适用于
- ONTAP 9
- SSL 和 CA 签名证书
- Active IQ Unified Manager
回答
- 执行摘要和核心定义：
- 本文档提供了 NetApp ONTAP 环境中自签名 SSL/TLS 证书和证书颁发机构（CA）签名证书之间的高度技术性、深入的体系结构比较：
- 在 ONTAP 中，安全管理协议（HTTPS/REST、System Manager、Active IQ Unified Manager、SVM 对等和 KMIP/NSE）依赖于 TLS 握手。
- 选择正确的证书拓扑会直接影响安全态势、管理自动化、可审计性和集群互操作性。
自签名证书：
- 创建者是签名者的证书。
- 用于生成公钥结构的私钥也用于发布其身份确认。
- 没有外部的信任锚。
CA 签名证书：
- 由受信任的第三方或内部 公司层次结构（企业根 CA）颁发的证书，其公共验证密钥 预安装在客户端或应用程序的信任存储库中。
2.技术比较矩阵：
| 技术属性 | 自签名 SSL 证书 | CA 签名证书 |
| 信任模型 | 显式、手动每客户端信任（“首次使用时信任”/TOFU）。 | 分层：锚定到内部企业 PKI 或公共根/中间 CA 的自动化信任链。 |
| 浏览器和客户端验证 | TLS 握手验证失败。触发浏览器警报（ERR_CERT_AUTHORITY_INVALID，SEC_ERROR_UNKNOWN_ISSUER，“不安全”）。（注意：在任何 HTTP 状态代码（如 HTTP 403）之前在 TLS 层失败）。 |
跨企业浏览器、CLI 工具和后台 API 调用方进行本机验证，无警告（干净的锁图标）。 |
| 中间人（MitM）防御 | 高风险：习惯性警告绕过（“接受风险并继续”）训练用户和脚本忽略身份验证，使流量容易受到拦截/欺骗。 | 稳健： 如果证书签名、CN/SAN 或链与受信任的根不匹配，客户端将严格断开连接。 |
| 自动化兼容性 | 中断脚本和 CI/CD 管道，除非注入了不安全的绕过标志（例如，Ansible validate_certs: false、Python verify=False、curl -k）。 |
与 Ansible（netapp.ontap 集合）、ONTAP REST API 客户端以及启用了完整 TLS 验证的 PowerShell Toolkit 进行原生的安全集成。 |
| 生命周期管理 | 高运营开销。每个节点/集群/SVM 的证书需手动生成和续订；缺乏集中跟踪或自动续订挂钩。 | 集中式证书生命周期管理（CLM）。支持自动签发/续订工作流程和集中式到期跟踪。 |
| 吊销支持 | 无：无法通过 CRL（证书吊销列表）或 OCSP 吊销。如果泄露，必须手动删除证书并从 SVM 中解除绑定。 | 支持：客户端和 ONTAP 可以针对企业 CRL 分发或 OCSP 响应程序实时验证证书吊销状态。 |
| ONTAP CLI 和服务绑定 | 通过security certificate create即时在系统上创建。通过security ssl modify -vserver <admin_svm> -ca <ca> -serial <serial>绑定到 SVM SSL 服务。 |
需要结构化工作流： 生成带有 SAN 的 CSR（ |
| AIQUM 集成影响 | 续订或重新生成自签名证书会生成新的指纹，导致 AIQUM 后台采集线程失败，或停滞在“轮询失败”/“发现正在进行”状态，直到手动重新进行身份验证。 | 无缝续订：只要颁发的根/中间 CA 存在于 AIQUM 主机信任存储（Java cacerts）中，续订就会透明地进行，而不会破坏数据收集。 |
3.微架构与密码学深度探索：
当客户端（如 Web 浏览器或 AIQUM）在端口 443 上打开到 ONTAP 管理接口（LIF）的 HTTPS 连接时，集群将提供其 X.509 数字证书。
- 自签名握手的工作原理：
- 出示：ONTAP 会出示一个本地创建的证书，其颁发者与使用者相同。
- 验证失败：客户端检查其操作系统或浏览器根信任存储。由于自签名证书未由公认的证书颁发机构签名，因此自动信任失败。
- 手动例外：客户端或管理员必须手动接受并记录唯一的证书指纹（首次使用时信任）。
- 风险/不稳定性：如果证书过期、重新生成，或者在没有跨节点/SVM的同步证书配置的情况下发生故障转移，身份验证将立即中断。
- CA 签名的信任链的工作原理：
- 出示：ONTAP 提供其服务器证书以及任何中间证书（证书链）。
- 自动链验证：客户端以加密方式验证链中的每个链接，直至其本地信任存储中安装的企业或公共根 CA。
- 执行的检查：
- 有效期：当前日期/时间介于 NotBefore 和 NotAfter 之间。
- 加密完整性：数字签名与 CA 链匹配。
- 主机名匹配：访问的 URL 或 IP 与证书的使用者备用名称（SAN）中的条目匹配。
4.现代 ONTAP 要求：使用者备用名称（SAN）
现代 Web 浏览器（Chrome、Edge、Safari）和 REST API 框架会忽略旧版通用名称（CN）属性，并强制使用使用者备用名称（SAN）（RFC 2818）。
- 自签名默认值：当 ONTAP 自动生成自签名证书时，它仅使用集群名称或节点管理 LIF 填充 CN。
- 它不会生成多 IP 或多 FQDN SAN 属性，即使在手动信任证书后，也会导致持续的浏览器警告。
- CA 签名最佳实践：在 ONTAP 上创建证书签名请求（CSR）时，管理员应在 -
san参数中明确包含所有管理 FQDN、短名称和管理 IP 地址：::> security certificate generate-csr -vserver <admin_svm> -common-name cluster01.corp.example.com -san cluster01.corp.example.com,cluster01,10.0.1.10 -size 2048 -hash-function SHA256
5.对 NetApp 管理工具的影响（Active IQ Unified Manager）
AIQUM 使用连续的后台采集线程来轮询 ONTAP 集群的性能、运行状况和容量指标。
使用自签名证书的行为：
- 初始设置：在发现过程中，AIQUM 提示管理员接受不受信任的证书，并将其唯一指纹保存在 AIQUM 数据库中。
- 续订明细：当自签名证书过期并在 ONTAP 集群上重新生成时，指纹会发生变化。
- 症状：AIQUM 检测到指纹不匹配并停止数据采集，以防止潜在的欺骗。
- 集群状态锁定在“轮询失败”或“正在发现”，直到管理员手动重新验证数据源。
使用 CA 签名证书时的行为：
- 自动验证：根/中间 CA 捆绑包一次性导入到 AIQUM 主机/JVM 信任存储（cacerts）中。
- 无缝续订：当群集证书由相同的 CA 层次结构续订时，AIQUM 会自动验证新证书。
- 轮询和发现继续进行，不会中断、更改配置或需要管理员干预。