AWS日本账号 亚马逊云AWS伺服器SSL证书配置

前言：别急着配证书，先搞懂你到底在哪儿“挂”HTTPS

很多人一听“AWS 伺服器 SSL 证书配置”，第一反应就是：买证书、点几下、搞定。但现实是，AWS 上 HTTPS 的“挂载点”有好几个：你可能把证书挂在 ALB（应用型负载均衡器） 上，也可能直接挂在 NLB（网络型负载均衡器） 或 EC2 实例 上。挂错位置，灯会亮，但网站不一定会按你想的方式工作——有时甚至能打开，有时又莫名其妙证书报错。

所以这篇文章我会按“从你到底用什么入口开始”的逻辑写：先确定场景，再讲证书申请与验证，再讲安装与配置，最后给你一份常见问题排查清单，让你不至于在凌晨两点用“猜”的方式修复。

你要先决定：SSL 证书配置在 AWS 的哪一层？

在讲具体操作之前，先花一分钟做选择题。你的网站入口属于哪种？

场景 A：你用 ALB（推荐，最常见）

典型架构是：用户访问域名 → ALB 负责做 HTTPS → 转发到后端 EC2/容器服务。这个场景的优点是：证书托管在 ACM/ALB，管理方便，HTTPS 配置集中。

如果你不确定自己用的是什么，先看看你前端是不是通过一个 ALB 的 DNS 或者你在控制台里看到 Application Load Balancer。大概率就是这个。

场景 B：你用 NLB

NLB 也支持 TLS，但配置思路会和 ALB 不一样。适合对性能、网络层有特殊需求的用户。

场景 C：你直接在 EC2 上跑 Web 服务

比如 Nginx/Apache 在实例上直接处理 HTTPS。这样你需要自己配置证书文件、私钥、重启服务等。也不是不行，但管理成本会更高。

核心概念：AWS 里最常用的证书管理工具是 ACM

在 AWS 里，配置 SSL 证书最省心的方式通常是：用 ACM（AWS Certificate Manager） 申请证书，并把证书挂到你的负载均衡器或其他支持的资源上。

你可以把 ACM 理解成“证书仓库 + 自动续期管家”。你把证书让 ACM 管，它会在快过期时帮你继续把证书续上（前提是你验证方式和权限配置没有问题）。这比你手动拷证书、改文件、重启服务要轻松很多。

步骤一：准备域名与 DNS（不然你证书申请就会卡住）

在申请 SSL 证书之前，你需要至少满足：

• 你要用的域名已经能在公网访问（或至少能做 DNS 验证）。
• 你有该域名的 DNS 控制权（例如在 Route 53、Cloudflare、其他 DNS 服务商上）。

注意：证书验证通常需要你能新增 TXT 记录或通过 CNAME 记录做证明。没有 DNS 权限，就等于你拿身份证去办业务，结果别人告诉你“你没带身份证”。

步骤二：在 ACM 申请证书（最常见的是域名验证）

AWS日本账号 下面以“你要在 AWS 上启用 HTTPS”为目标，讲最常见的申请方式。

2.1 进入 ACM

AWS日本账号 在 AWS 控制台搜索 Certificate Manager（证书管理器），进入后开始申请。

2.2 选择证书类型

常见选择：

• 公有证书（Public certificate）：用于对外网域名。
• 私有证书（Private certificate）：用于内部服务，一般走私有 CA。

大多数网站都是公有证书。

2.3 填写域名

你可以选择：

• 只填写主域名，例如：example.com
• 填写多个域名：example.com、www.example.com
• 若有子域名需求，可能还会用到通配符（取决于你申请的证书能力与验证方式）。

提醒一句：通配符证书并不是“随便填就能过”。它的验证会更严格一些。

2.4 选择验证方式

ACM 支持域名验证，常见是：

• DNS 验证（推荐）：你在 DNS 添加 TXT 记录或 CNAME 记录，验证通过后证书签发速度通常更快。
• 电子邮件验证：如果你能通过指定邮箱收到验证邮件。

大多数人选 DNS 验证。原因很朴素：稳定、可自动化，也比较不吃运气。

步骤三：把证书挂到 ALB（以最常见场景为例）

如果你是用 ALB，那么你的操作会相对轻松。

3.1 打开 ALB 的监听器（Listener）

进入 EC2 控制台 → Load Balancers → 选择你的 ALB → 找到 Listeners（监听器）。

通常你会看到类似：

• HTTP:80（开着但没加密）
• HTTPS:443（你可能还没配置证书）

AWS日本账号 3.2 添加 HTTPS 监听器或编辑现有监听器

选择：

• 端口：443
• 协议：HTTPS
• 证书：选择刚刚在 ACM 签发通过的证书

如果系统还没让你选择，通常是因为证书还没完成签发。证书状态一般会从“Pending validation”到“Issued”。

3.3 确认转发规则（Forward to target group）

SSL 配好了，你还得保证 HTTPS 请求能被正确转发到后端。

检查该 HTTPS Listener 是否指向正确的 Target Group（目标组），并核对：

• 目标类型：EC2 / IP / Lambda
• 健康检查（Health check）是否通过
• 端口设置是否正确

有些人证书配置成功但网站还是“502/无法访问”，原因往往不是证书，而是目标组没配对、后端服务没起来。

步骤四：从 HTTP 强制跳转到 HTTPS（让用户别绕路）

很多站点上线后会遇到一个经典问题：浏览器看到你支持 HTTPS，但用户输入 http:// 还是会走 http。虽然有些网站“能用”，但安全性和用户体验都会打折。

因此建议你做强制重定向。

4.1 在 ALB 上配置 HTTP 监听器跳转

AWS日本账号 你可以编辑 HTTP:80 的 Listener 规则，让它直接：

• 返回重定向到 HTTPS:443
• 保留路径和查询参数（通常系统支持此类设置）

当用户访问 http://example.com/xxx，浏览器会自动跳到 https://example.com/xxx。

4.2 后端应用也要注意 HSTS（可选但推荐）

除了重定向，你还可以启用 HSTS（HTTP Strict Transport Security），让浏览器未来一段时间强制使用 HTTPS。

如果你不熟，建议先咨询你当前 Nginx/应用框架如何设置，避免“一上来就把有效期设太夸张”，导致你测试时很难回退。

步骤五：如果你用的是 EC2 直挂证书，怎么办？

下面这部分会更“动手”，因为你需要在服务器上配置 Nginx/Apache 并安装证书文件。

5.1 仍然建议用 ACM 申请证书

即便你最终要在 EC2 上用证书，证书申请仍建议走 ACM。原因是：签发流程更规范、续期更好管理。

但 ACM 的证书要在 EC2 上使用，可能需要：

• 导出证书与私钥（取决于你的用途与 ACM 配置策略）
• 或者使用结合部署工具的方式同步

不同公司/不同安全策略会有差异。如果你环境允许导出，那可以继续。

5.2 Nginx 示例思路（不展开到具体命令细节）

你要做的是：

• 准备证书文件（证书链、站点证书）与私钥
• 配置 server 块，监听 443 并引用证书路径
• 配置 80 做重定向到 443

注意权限：私钥文件不要给太宽的权限，否则安全审计会先找你喝茶。

步骤六：证书自动续期（你以为到期前会有人提醒，其实没人会）

大多数情况下，使用 ACM + 合适的挂载方式，续期会自动处理。你需要做的是确保：

• 证书仍能按验证方式继续通过（DNS 验证通常最稳）
• 证书没有因为域名所有权变更、DNS 被删掉而导致续期失败
• 你挂载的资源（ALB/其他）引用的证书不会在续期后出现不兼容问题

建议你在上线后设一个“心里有数”的监控：比如证书到期前一个月就给团队提醒一下。自动续期是自动续期，提醒不是多余的。

常见坑位大集合：为什么我配了还是不对？

下面这些问题非常常见，基本覆盖了“证书配置失败”的大部分原因。

坑 1：证书状态没到 Issued 就挂载

你可能会在 ACM 里看见证书处于待验证或等待签发状态，然后你急着去 ALB 里选择它。结果要么选择不到，要么挂上了也不工作。

解决办法：确认 ACM 证书状态为 Issued。

坑 2：DNS 验证没生效（TTL、缓存、权限问题）

DNS 记录加了，但签发一直不过。你以为“加了就应该生效”，但 DNS 缓存、记录写错、或你加到错误的主机上，都会导致验证失败。

解决办法：核对记录类型与数值，等待传播或进行权威 DNS 查询。

坑 3：ALB HTTPS Listener 配了证书，但 Target Group 不健康

浏览器提示证书没问题，但后端返回 502/504。此时证书当然是“背锅侠”。

解决办法：检查 Target Group 的 Health check，后端实例、安全组、端口、应用是否监听正确。

坑 4：安全组（Security Group）没放行 443

ALB 的安全组和 EC2 的安全组可能都要配置。尤其是你是否限制了来源地址。

解决办法：确认 ALB 到后端的入站规则与后端端口一致。

坑 5：你用了错误的域名（包含/不包含 www）

证书是为 example.com 签发的，但你访问的是 www.example.com。浏览器就会很诚实地告诉你“证书不匹配”。

解决办法：申请包含所有需要的域名，或使用通配符证书（如果你符合条件）。

坑 6：链不全（客户端无法建立完整信任）

有时你在 EC2 直挂证书时，缺了证书链文件，导致某些客户端兼容性差。

解决办法：使用正确的证书链与配置。

AWS日本账号 实战建议：上线前你可以做哪些“检查清单”？

为了不让上线当天出现“啊这怎么又报错”的剧情，我建议你上线前做下面这些检查。

检查 1：用不同浏览器确认证书

至少用 Chrome 和 Firefox 或 Safari（如果你们的用户可能在这些浏览器上）。看是否有域名不匹配、证书过期、证书链异常等提示。

检查 2：确认跳转是否正确（HTTP → HTTPS）

访问 http:// 和 https://，观察：

• 是否会正确重定向
• 是否保留路径（比如 /api/xxx）
• 是否出现循环跳转

检查 3：后端日志里是否能看到请求

如果 HTTPS 监听器配置没问题，但应用端没日志，可能是转发规则或端口问题。

检查 4：缓存与 CDN（如果有）的交互

如果你前面还有 CloudFront 或其他 CDN，不同层可能做了重定向或证书策略。你要确保最终客户端看到的是期望的 HTTPS 行为。

结尾：AWS 配 SSL 不是玄学，是流程管理

说到底，“亚马逊云AWS伺服器SSL证书配置”并不难，难的是你在第一次接触时不知道它的入口在哪里、证书挂载点怎么选、验证为什么卡住、重定向怎么配。

只要你记住三句话：先确认你挂在 ALB 还是 EC2；再确保 ACM 证书完成签发；最后检查监听器转发与后端健康。

做完这些，你的站点就能用一张合规的证书把 HTTPS 的“信任”稳稳端上来。剩下的就是把手头的安全加固、TLS 策略、HSTS（如果需要）做得更体面一点。毕竟，我们不只是让浏览器不报错，我们还想让它信任你。

附：快速问答（帮你省几次返工）

Q1：我是否一定要在 ACM 里申请证书？

不一定，但强烈建议。ACM 的管理、续期与挂载体验更适合大多数生产环境。

Q2：我能不能直接用自签名证书？

可以用于内部测试环境，但公网客户端不会信任。生产对外服务一般不建议。

Q3：证书快到期了我该怎么办？

如果使用 ACM 并保持验证方式不出问题，续期通常是自动的。你仍然建议提前设提醒，避免续期失败时你浑然不觉。

Q4：证书配置完成后立刻就生效吗？

通常是的，但 DNS 变化、证书签发验证、负载均衡更新可能会有延迟。耐心等待一段时间并通过浏览器或检查状态来确认。