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 证书（节点间认证）。任何证书错误都会导致：

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

本文解法：

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

1. ⭐ L1 证书策略

1.1 证书用途总览

$L1$ Azure Stack Hub 需要两类证书：

类型	用途	数量	颁发者
公网证书（PKI）	公共终结点（adminportal / portal / adminmanagement / storage / keyvault 等）	每个终结点一个 SAN	公共可信 CA 或企业 CA
内部 CA 证书	节点间身份验证（默认由 Azure Stack Hub 内部 ADCS 颁发）	1 个根证书	Azure Stack Hub 内部 CA

1.2 公网证书策略 $L1$

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

每个公共终结点需要 PKI 证书，对应其 DNS 名称
Azure Stack Hub 不提供开箱即用的默认证书------客户必须自行从内部 CA 或公共可信 CA 准备
每个服务器证书的 SAN 必须根据目标的 FQDN 验证
必须验证整个信任链
必须验证证书到期日期
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 至少包含：

终结点	DNS 名称
Admin Portal	`adminportal.<region>.<external-domain>`
Admin Management	`adminmanagement.<region>.<external-domain>`
Portal	`portal.<region>.<external-domain>`
Management	`management.<region>.<external-domain>`
Storage (blob)	`*.blob.<region>.<external-domain>`
Storage (table)	`*.table.<region>.<external-domain>`
Storage (queue)	`*.queue.<region>.<external-domain>`
Key Vault	`*.vault.<region>.<external-domain>`
Key Vault Internal	`*.adminvault.<region>.<external-domain>`
ADFS	`adfs.<region>.<external-domain>`
Graph	`graph.<region>.<external-domain>`

$L3$ 通配符策略：

复制代码

*.<region>.<external-domain>

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

1.4 信任链要求 $L1$

$L1$ 必填项：

证书链完整------客户端能验证到受信任的根 CA
所有 Azure Stack Hub 基础结构计算机都信任内部 CA 的根证书------根证书添加到本地证书存储
CA 证书不能过期 ------CA 根证书有效期应覆盖 Azure Stack Hub 整个生命周期；Microsoft 官方未提供固定年限，企业根证书通常 5-10 年，公共可信 CA 根证书通常 10-20 年，建议规划 ≥ 5 年以避免轮换中断
证书主题（Subject）与颁发者（Issuer）必须为可分辨名称（DN） ------Subject 至少包含 CN=<hostname>；Issuer 包含 CA 的 DN
Azure Stack Hub 不提供证书续期通知 API ------客户需自建监控（如 Azure Monitor / Prometheus 抓取管理员门户 API 或 Azure Stack Hub PEP 的 Get-AzsCertificate 输出）
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 身份提供者时：

ADFS 证书需要单独颁发（adfs.<region>.<external-domain>）
ADFS 元数据需要导出给企业 ADFS 做联合信任
ADFS 证书需要定期轮换（通常 1-2 年）
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 项检查，具体项数 / 名称以当期模块输出为准：

#	验证项	失败后果
1	PFX 分析：检查 PFX 文件有效、密码正确、公共信息是否受密码保护	OEM 脚本读取证书失败
2	到期日期：检查最短有效期 ≥ 7 天	部署后立即触发轮换告警
3	签名算法：检查不是 SHA1（SHA1 已不安全）	浏览器 / 客户端拒绝
4	私钥：检查私钥存在 + 本地计算机属性可导出	OEM 无法导入
5	证书链：检查证书链完整 + 自签名证书检查	客户端不信任
6	DNS 名称：检查 SAN 包含每个端点的 DNS 名称 / 通配符	浏览器证书警告
7	密钥用法：检查密钥用法含数字签名 + 密钥加密 + 增强型密钥用法含服务器身份验证 + 客户端身份验证	SSL 握手失败
8	链式顺序：检查其他证书的顺序正确	链验证失败

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

2.3 验证报告解读

输出	含义	处置
✅ PASS	验证通过	继续
⚠️ WARNING	不阻塞部署但需关注	记录到部署日志
❌ FAIL	阻塞部署	必须修复后重跑

2.4 常见失败原因

失败项	常见原因	修复
签名算法 SHA1	CA 用了过期的签名算法	让 CA 用 SHA256 重新签发
私钥不可导出	证书导入时未勾选"私钥可导出"	重新导入 PFX 时勾选
SAN 不匹配	通配符层级错（如 `.east` 而非 `.east.cloud.fabrikam.com`）	重新申请正确 SAN
证书链不完整	中间 CA 证书缺失	把完整链（含中间 CA）打包进 PFX
到期日期 < 7 天	证书快过期	重新签发

2.5 证书验证 Checklist

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

3. ⭐ L1 证书与密钥轮换

3.1 轮换必要性

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

服务账户密码------内部服务账号
内部证书------节点间通信
外部证书------公共终结点 SSL

$L1$ 轮换要求：

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

3.2 三类密钥轮换

类别	触发	操作
服务账户密码过期	30 天预警告警	通过 PEP（特权终结点）轮换
内部证书过期	30 天预警告警	通过 PEP 轮换
外部证书过期	30 天预警告警	通过管理员门户 + 重新导入 PFX

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

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

$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 → PEP Set-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 验证

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

0. 这篇解决什么

1. ⭐ L1 证书策略

1.1 证书用途总览

1.2 公网证书策略 L1

1.3 SAN 列表（核心）

1.4 信任链要求 L1

1.5 ADFS / 联合场景 L1

2. ⭐ L2 AzsReadinessChecker 证书验证

2.1 工具安装

2.2 8 项证书验证

2.3 验证报告解读

2.4 常见失败原因

2.5 证书验证 Checklist

3. ⭐ L1 证书与密钥轮换

3.1 轮换必要性

3.2 三类密钥轮换

3.3 轮换命令（PEP）

3.4 轮换 Checklist

4. 证书生命周期总览

5. 一句话总结

6. 下一步

1.2 公网证书策略 $L1$

1.4 信任链要求 $L1$

1.5 ADFS / 联合场景 $L1$