Azure Stack Hub 证书管理：PKI / SAN / 信任链 / 验证 / 轮换

未经同意，请勿转载！

系列：第 3 篇（共 5 篇）— 部署前 2-4 周必读（与 CA 供应商并行） 对应 PPT：slide 13-16（推荐证书策略 / 就绪性检查器 / 证书与密钥轮换） 主题：Azure Stack Hub 部署前 + 部署后的证书生命周期管理责任团队：CA 工程师 + SME + 运维 输出：全部公网证书 PFX + 内部 CA 根证书 + AzsReadinessChecker PASS

0. 这篇解决什么

问题：Azure Stack Hub 部署需要两类证书——公网证书（每张服务器证书必须覆盖它所服务 Endpoint 的 DNS 名称SAN）+ 内部 CA 证书（节点间认证）。任何证书错误都会导致：

1. 部署失败（OEM 脚本校验证书失败）
2. 部署后门户访问失败（浏览器不信任证书）
3. 内部服务认证失败（节点间不互信）
4. 30 天后才暴露：证书快过期但没轮换流程

本文解法：

• §1推荐证书策略：PKI / SAN / 信任链 / 内部 CA
• §2AzsReadinessChecker 8 项证书验证：部署前发现所有证书问题
• §3证书与密钥轮换：30 天预警 + 三类证书轮换

1. ⭐ L1 证书策略

1.1 证书用途总览

[L1]Azure Stack Hub 需要两类证书：

1.2 公网证书策略 [L1]

[L1]微软硬要求（PPT slide 14）：

1. 每个公共终结点需要 PKI 证书，对应其 DNS 名称
2. Azure Stack Hub不提供开箱即用的默认证书——客户必须自行从内部 CA 或公共可信 CA 准备
3. 每个服务器证书的 SAN 必须根据目标的 FQDN 验证
4. 必须验证整个信任链
5. 必须验证证书到期日期
6. Azure Stack Hub 还使用内部 Active Directory 证书服务（ADCS）颁发的证书在节点之间进行身份验证（这部分由 Azure Stack Hub 内部管理，不需客户准备）

[L3]推荐：

• 用通配符证书（*.east.cloud.fabrikam.com）覆盖大多数终结点
• 或用单域名证书（为每个关键终结点单独颁发）
• 优先用公共可信 CA（避免用户浏览器弹出证书警告）
• ⚠️限制：部分 Azure Stack Hub 服务不支持通配符证书，必须用单域名证书，例如adminmanagement/portal/adminportal/management等管理类终结点，以及graph/adfs等身份认证类终结点；具体清单以 Microsoft Learn 官方轮换文档为准

1.3 SAN 列表（核心）

每个 Azure Stack Hub 实例的 SAN 至少包含：

[L3]通配符策略：

*.<region>.<external-domain>

可覆盖大多数，但部分终结点不能用通配符（如adminmanagement），需要单独颁发。

1.4 信任链要求 [L1]

[L1]必填项：

1. 证书链完整——客户端能验证到受信任的根 CA
2. 所有 Azure Stack Hub 基础结构计算机都信任内部 CA 的根证书——根证书添加到本地证书存储
3. CA 证书不能过期——CA 根证书有效期应覆盖 Azure Stack Hub 整个生命周期；Microsoft 官方未提供固定年限，企业根证书通常 5-10 年，公共可信 CA 根证书通常 10-20 年，建议规划 ≥ 5 年以避免轮换中断
4. 证书主题（Subject）与颁发者（Issuer）必须为可分辨名称（DN）——Subject 至少包含CN=<hostname>；Issuer 包含 CA 的 DN
5. Azure Stack Hub 不提供证书续期通知 API——客户需自建监控（如 Azure Monitor / Prometheus 抓取管理员门户 API 或 Azure Stack Hub PEP 的Get-AzsCertificate输出）
6. CRL（证书吊销列表）分发点可达——Azure Stack Hub 验证公网证书链时默认检查 CRL。如果企业内部 CA 签发的证书包含无法从 Azure Stack Hub 计算机访问的 CRL URL，验证将失败。处理选项：
   • 优先：确保 Azure Stack Hub 基础结构能解析并访问证书中的 CRL 分发点
   • 次选：申请证书时跳过 CRL 分发点（内部 P2P 场景，吊销需求低）
   • 特殊：配置合法的离线 CRL（定期手动更新到 Azure Stack Hub 内部 DNS / 主机）

离线 / Air-Gapped 部署需重点关注 CRL 可达性——默认 CRL 拉取可能依赖 Internet / 企业 CA 服务器，导致轮换后立即验证失败。

企业需自行集成证书生命周期到现有 PKI 管理平台（如 Venafi / Keyfactor / DigiCert CertCentral），避免依赖单一门户告警。

1.5 ADFS / 联合场景 [L1]

[L1]选 ADFS 身份提供者时：

1. ADFS 证书需要单独颁发（adfs.<region>.<external-domain>）
2. ADFS 元数据需要导出给企业 ADFS 做联合信任
3. ADFS 证书需要定期轮换（通常 1-2 年）
4. ADFS 证书的 SAN 至少包含：
   • adfs.<region>.<external-domain>（主名称）
   • certauth.<region>.<external-domain>（OAuth 设备流 / 证书认证）
   • enterpriseregistration.<region>.<external-domain>（企业注册，工作环境加入时使用）
   • 企业联合服务器可达的 DNS 名称

[L1]⚠️ADFS 证书失效影响：adfs.<region>.<external-domain>失效会导致：

• 所有 Entra ID / 企业 AD 联邦用户登录 Azure Stack Hub 门户失败
• 租户自服务门户访问中断
• ADFS 元数据交换不可用（联合信任中断）

ADFS 证书是 Azure Stack Hub 上"最敏感的证书"之一，建议同时启用 Microsoft Learn 推荐的 ADFS 自动证书滚动（auto-certificate rollover）以避免人工遗漏。

[L1]ADFS 端口要求：

• 联合信任需要企业 ADFS 服务器开放TCP 443（ADFS 主端口）与TCP 80xx / 443xx（代理 / 元数据端口）
• 客户防火墙 / 代理需明确以下流量方向：
  • Azure Stack Hub ADFS → 企业 ADFS（出站 443）：令牌签发 / SAML 响应回传
  • 企业 ADFS → Azure Stack Hub ADFS（入站 443）：联合元数据拉取 / 联合信任验证
  • 两边均为标准 ADFS 联合场景的双向互访需求（不是单向）
• Web Application Proxy（WAP）场景需额外开放 443 到 WAP

⚠️ 实际网络拓扑中，Azure Stack Hub ADFS 位于内部、企业 ADFS 可能位于企业内网或 DMZ；需在边界防火墙同时配置源 / 宿与方向，避免网络团队配置时歧义。

2. ⭐ L2 AzsReadinessChecker 证书验证

2.1 工具安装

[L2]与 doc 02 §7 的 AzsReadinessChecker 是同一个工具——部署前/后都可跑。

# 部署前：在 HLH 或网络可达的机器上跑 Invoke-AzsReadinessChecker -CertificatePath <path-to-pfx> ` -Password <secure-password> ` -RegionName <region-name> ` -FQDN <external-domain> ` -IdentitySystem ADFS # 或 AzureAD

以官方 AzsReadinessChecker 模块当期接口为准：本示例为典型调用语法，具体 cmdlet 名 / 参数集 / 参数取值（如-IdentitySystem的合法值）以 PowerShell Gallery 上当期模块版本为准。

⚠️离线部署（Air-Gapped）环境的准备：Azure Stack Hub 部署环境经常处于彻底隔离的物理断网状态，Get-Help/Update-Help在断网机器上可能返回不完整帮助。部署前在可联网跳板机上：

• 运行Update-Help -Module Azs.Deployment.Worksheet, Microsoft.AzureStack.ReadinessChecker缓存帮助
• 或直接查阅 PowerShell Gallery 网页端模块页面（https://www.powershellgallery.com/packages/...）

携带预缓存的帮助文件或离线文档包到 Air-Gapped 环境，避免 cmdlet 参数确认延误。

2.2 8 项证书验证

[L2]AzsReadinessChecker 证书验证（PPT slide 15）包含至少 8 项检查，具体项数 / 名称以当期模块输出为准：

注：不同 AzsReadinessChecker 模块版本可能引入新的验证项（如KeyUsage/Thumbprint/Subject等）。执行后查看输出，遇到本表未覆盖的项以工具输出为准。

2.3 验证报告解读

2.4 常见失败原因

2.5 证书验证 Checklist

• 每个 PFX 文件都跑过Invoke-AzsReadinessChecker
• 所有验证项全 PASS（当期模块版本定义项为准）
• 失败项已修复并重跑
• 验证报告存档（合规审计用）
• 自 OEM 脚本开始执行之日起算，证书剩余有效期 ≥ 7 天（避免部署后立即触发轮换告警）
• 临期证书（< 30 天）重新签发后再验证（避免临期证书中选）

3. ⭐ L1 证书与密钥轮换

3.1 轮换必要性

[L1]Azure Stack Hub 使用机密（secrets）维护与基础结构资源和服务的安全通信：

1. 服务账户密码——内部服务账号
2. 内部证书——节点间通信
3. 外部证书——公共终结点 SSL

[L1]轮换要求：

• 微软建议：操作员以符合其组织安全要求的频率轮换这些机密（这是最佳实践，不是硬性产品限制）
• 微软强制：Azure Stack Hub 会在密钥过期前 30 天在管理员门户生成告警；完成轮换将解决告警
• 轮换频率由企业根据自身合规要求决定（业内参考：外部证书 1-2 年、内部证书 2-5 年、服务账户密码 1-2 年）

3.2 三类密钥轮换

[L3]推荐轮换顺序（避免服务中断）：

1. 先外部——外部证书轮换不影响 Azure Stack Hub 内部服务；部署新 PFX → 验证 → 切换
2. 后内部——内部证书轮换可能需要节点重启 / PEP 重连，建议在维护窗口内执行
3. 最后服务账户密码——内部服务重启后依赖新密码生效

[L3]顺序的底层逻辑：

• "先外后内"确保在内部节点重启 / 拓扑变更期间，外部入口（门户 / adminportal / API）始终可用——管理员可以随时通过外部入口接入控制台，观察内部轮换状态、收集错误日志、调整轮换节奏
• 反过来"先内后外"会造成外部入口轮换时内部服务尚未恢复，运维完全失联，盲轮换风险高
• 服务账户密码最后轮换，是因为内部服务重启后才依赖新密码生效，提前轮换会导致"新旧密码同时有效"的中间状态，徒增调试点

3.3 轮换命令（PEP）

[L2]通过 PEP（特权终结点）执行；PEP 凭据为CloudAdmin（不是 ERCS 本地管理员）：

# 连接到 PEP（凭据类型：CloudAdmin，不是 ERCS 本地管理员） Enter-PSSession -ComputerName <pep-ip> ` -ConfigurationName PrivilegedEndpoint ` -Credential <CloudAdmin-credential> # 内部证书轮换 Invoke-AzsInternalCertificateRotation # 服务账户密码轮换 Invoke-AzsPasswordRotation # 检查当前状态 Get-AzsCertificateRotationStatus # 外部证书轮换：在管理员门户导入新 PFX 后，在 PEP 上验证并激活 Set-AzsExternalCertificate -CertificatePath <new-pfx-path> ` -Password <secure-password> # 验证外部证书状态 Get-AzsCertificateRotationStatus

PEP 访问限制：PEP 仅允许从 Azure Stack Hub 内部网络（HLH / OME VM / 运维跳板机）连接，不允许从外部网络直接连接。

外部证书轮换顺序：门户导入新 PFX → PEPSet-AzsExternalCertificate激活 → 验证 → 30 天预警清除。外部证书轮换命令仅负责"验证 + 激活"，证书文件必须先通过门户上传。

3.4 轮换 Checklist

• 管理员门户设置轮换日历（每年 / 每 2 年）
• 外部证书 PFX 提前 60 天准备就绪
• 内部证书轮换由 PEP 执行（不依赖外部 CA）
• 服务账户密码轮换计划
• 告警订阅配置（证书过期前 30 天）

4. 证书生命周期总览

部署前 4 周 部署日 部署后 │ │ │ ▼ ▼ ▼ ┌────────┐ ┌─────────────┐ ┌──────────────┐ │ 申请证书│──────────────▶│ OEM 导入证书 │──────▶│ 运维轮换循环 │ │ (CA) │ │ (PFX) │ │ (每年/2年) │ └────────┘ └─────────────┘ └──────────────┘ │ │ │ ▼ ▼ ▼ AzsReadinessChecker AzsReadinessChecker 30 天预警窗口期 (部署前 8 项验证) (部署前最后一次) (PEP / Portal) │ ┌───────┴───────┐ ▼ ▼ 完成轮换 到期 (0 天) (告警清除) (服务中断)

30 天预警窗口期说明：Azure Stack Hub 在证书过期前 30 天开始告警；运维需在该窗口内完成轮换。建议从 30 天预警到 0 天到期之间预留≥ 14 天缓冲（包括重新签发 + 验证 + 切换 + 观察）。

5. 一句话总结

证书是 Azure Stack Hub 部署的"硬门槛"——AzsReadinessChecker 验证是部署前的核心证书关卡；任何一项 FAIL 都会阻塞 OEM 部署；运维必须建立每年轮换日历。

6. 下一步

完成证书管理后，进入doc 04 — 安装部署，覆盖：

• §1 部署前 11 步流程总览
• §2 HLH 重镜像（Re-imaging）
• §3 交换机配置
• §4 HLH 配置脚本
• §5 OME VM 网络预检查脚本
• §6 InstallDellEMCAzureStack 部署脚本
• §7 Test-AzureStack 验证