清点主机名、依赖项与所有权
列出访客或集成使用的每个主机名：apex（根域）、www、子域、API、资源主机、门户和区域化名称。对于每个主机名，记录 TLS 在何处终止、谁可以更改它、证书覆盖与到期、续期方式，以及会生成 URL 的依赖项。证书必须在其主题备用名称（Subject Alternative Name）列表中覆盖被请求的主机名。包括 CMS、CDN、标签管理器、对象存储、支付提供方、邮件模板和第三方嵌入；这些在首次启用 HTTPS 后常会引入 HTTP URL。
选择一个规范的 www 或 apex 主机名，并将备选名称直接通过 HTTPS 重定向到它。
部署证书并启用当前 TLS 版本
配置回答对外请求的 Web 服务器、反向代理、CDN 或负载均衡器。安装证书和所需链条，将它们绑定到预期的主机名，并从托管网络外进行验证。浏览器会检查证书链、主机名和日期；任何公开警告都是发布阻断项。默认使用 TLS 1.3，仅在兼容性需要时保留 TLS 1.2。禁用 SSL 以及 TLS 1.0 和 1.1。使用受维护的平台指导，而非复制来的过时密码套件列表，并保持服务器与 TLS 库打好补丁。
限制对私钥的访问，并记录每个共享该私钥的系统，以便替换时能覆盖所有系统。
一次性重定向 HTTP，使 HTTPS 成为规范
对每个 HTTP URL 返回服务器端的永久重定向，通常为 301 或 308，从而跳转到等效的 HTTPS URL。避免重定向链：链条会增加延迟并引入更多失败点。在内部链接、规范标签、站点地图、结构化数据、社交标签、电子邮件和应用生成的绝对链接中发布规范的 HTTPS URL。测试主页、深层页面、带查询的 URL、错误路由和主机名变体。当 TLS 在代理处终止时，配置受信任的转发协议处理，以免应用在 HTTP 与 HTTPS 之间循环跳转。
HTTP 仅能保留用于重定向或完成证书挑战，而不应作为单独的对外站点提供内容。
在源头查找并修复混合内容
混合内容是指 HTTPS 页面请求通过 HTTP 或其他不安全协议加载的资源。浏览器可能会自动升级某些媒体资源，但会阻止许多风险较高的请求，包括脚本、样式表、框架、fetch 调用和字体。将每个引用替换为经过测试的 HTTPS URL、自有内容的相对 URL 或经批准的替代方案。爬取有代表性的模板，并在完成关键流程时使用开发者工具检查。检查 CSS、JavaScript、CMS 块、资源清单、标签管理器条目、下载内容和供应商嵌入内容。安全页面不应提供 HTTP 下载链接。
自动升级仍可能导致不可用或不受支持的第三方依赖；应修正存储的 URL。
自动化续期并演练证书恢复
把续期当作一次自动化部署处理，而不是日历提醒。续期必须在每个服务层完成部署并安全重载服务。在线上到期前，测试相同的验证路径。例如，Let’s Encrypt 建议其 90 天证书在每 60 天续期；遵循你的签发者与平台的生命周期。将证书名称、签发者账户、挑战方法、自动化、密钥位置、目标和紧急联系人记录在清单中。部署后从公共端点验证到期日期。
若续期失败，检查 DNS、挑战路由、权限、签发者访问、速率限制以及 CDN 到源的部署。
只有在 HTTPS 体系准备好后才使用 HSTS
HTTP Strict Transport Security，即 HTTP 严格传输安全（HSTS），是一个 HTTPS 响应头，告知浏览器以后对该主机使用 HTTPS。浏览器随后不会为证书错误提供访客绕过选项。仅在 HTTPS 响应上发送该头，并保留 HTTP 重定向，因为浏览器在收到安全响应后才学会 HSTS，除非适用预加载列表。先使用有限的 max-age，经过验证续期与必需路由后再延长。不要在每个当前或未来子域都能提供有效 HTTPS 之前添加 includeSubDomains。预加载（preload）不是 HSTS 规范的一部分，需要单独、长期的承诺审查。
max-age=0 只有在浏览器获得有效的 HTTPS 响应后才会生效；它无法修复无法访问的安全主机。
发布、测试与回滚时不削弱传输安全
在变更前捕获已知良好的证书、边缘与重定向配置。定义谁批准回滚、尽可能进行分阶段发布，并每次只改动一种控制类别。变更后立即从多个网络检查对外端点、跟踪重定向、检查证书，并完成重要访客操作。测试对你的受众重要的浏览器与客户端群体。对于支付或受监管流程，向支付提供方与合格的安全专业人员咨询适用要求。如果变更破坏了 HTTPS，恢复已验证的安全配置；不要以将客户页面降级为 HTTP 的方式临时处理。
捕获主机名、时间、客户端、错误、变更与结果，以便下次续期或迁移时更易诊断。