AWS自动发货 AWS亚马逊云账号SSL配置

一、先把话说明白：为什么 AWS 上的 SSL 不能随便糊弄

在 AWS 里做 SSL 配置，表面上看只是“给网站挂个小锁头”，实际上背后牵扯的是证书签发、域名解析、服务绑定、流量转发、到期续期这一整套链路。别小看这个小锁头，它一旦没配好，浏览器会立刻给你来一出“此连接不安全”，用户点一下页面都像在拆炸弹，心里发毛，手上发抖。

很多人第一次接触 AWS 的 SSL，都会有一种朴素的误解：证书嘛，不就是上传一下，完事。结果真动手才发现，AWS 的证书体系和传统虚拟主机不太一样。你可能把证书申请在 ACM 里，结果忘了它必须和具体的 AWS 服务绑定；你可能已经有了证书，却忘了 DNS 验证没通过；你可能在 EC2 上装好了 Nginx，却没有把 80 跳转到 443，最后用户还是能看到裸奔的 HTTP。所谓“配置 SSL”，本质上是让整条访问路径都穿上衣服，而不是只给前门挂个门牌。

所以，如果你正在做 AWS 亚马逊云账号 SSL 配置，最重要的不是追求一步到位，而是先搞清楚你的网站到底部署在哪一层：是直接跑在 EC2 上，还是挂在 ALB 后面，或者前面还有 CloudFront、API Gateway、Elastic Beanstalk。不同架构，SSL 的落点完全不一样。弄清楚这一点，后面很多弯路都能少走。

二、AWS 里常见的 SSL 配置场景

1. 直接在 EC2 上部署网站

如果你的网站跑在 EC2 上，最常见的做法就是自己在服务器里安装 Nginx 或 Apache，然后把证书文件放到服务器上，手动配置 443 端口。这个方案自由度高，适合喜欢自己掌控一切的人。优点很明显：你想怎么配就怎么配，连证书链都可以按你的心情排列。缺点也很明显：证书续期要自己操心，操作稍有不慎，网站就会在浏览器里“挂红牌”。

这种方式适合轻量项目或者测试环境，但如果是正式业务，建议还是多考虑 AWS 托管证书和负载均衡。毕竟服务器可以自己折腾，凌晨两点证书过期弹警告的时候，人的精神状态通常不太适合重装系统。

AWS自动发货 2. 使用 ALB 作为入口

应用负载均衡器 ALB 是 AWS 里做 SSL 的常见选择。你把 HTTPS 证书绑定到 ALB 上，外部用户访问 443 端口，ALB 负责终止 SSL，再把请求转发到后端 EC2。这样一来，证书管理简单很多，ACM 证书还能直接和 ALB 配合，省心程度高了不止一点点。

对大多数中小型网站来说，这几乎是最推荐的方案之一。你不用在每台服务器上都装证书，后端机器换来换去也不影响外部访问，运维心情会稳定不少。毕竟能让人少点加班的方案，都是好方案。

3. 前面挂 CloudFront

如果你的网站有全球访问需求、静态资源很多，或者希望加速和缓存效果更好，CloudFront 也是常见入口。它支持绑定 ACM 证书，但有个很关键的点：如果是给 CloudFront 用的证书，必须放在 us-east-1 区域。这个坑非常经典，经典到很多人都踩过，踩完才发现自己证书没问题，问题是区域不对。

CloudFront 场景下的 SSL，不只是给用户看的 HTTPS，还影响到回源方式、缓存策略、重定向逻辑。如果你的网站前面有 CloudFront，后面还有 ALB 或 S3，那么每一层的证书和协议都要对应起来，不能前面是 HTTPS，后面却偷偷回源 HTTP，像穿西装配拖鞋，表面体面，细看全是破绽。

三、申请 AWS 证书：ACM 才是主角

AWS 上最常用的证书管理服务是 ACM，也就是 AWS Certificate Manager。它的好处是和 AWS 各类服务集成得很自然，申请、绑定、续期都比较省力。只要域名验证通过，证书就能发下来，而且很多场景下还支持自动续期，简直是证书界的“甩手掌柜”。

申请证书时，首先进入 ACM 控制台，选择请求公有证书。然后填写要保护的域名，比如 example.com 和 www.example.com。如果你的网站有多个子域名，也可以用通配符证书，比如 *.example.com。不过要注意，通配符证书不代表“天下无敌”，它只能覆盖同一层级的子域名，不能跨层乱来。比如 www.example.com 可以，a.b.example.com 就未必适用。

接下来是验证方式。通常建议选 DNS 验证，因为它最省事，也最利于自动续期。ACM 会给你一条 CNAME 记录，你把它加到域名解析里，等验证通过，证书就能签发。邮件验证虽然也能用，但在实际运维里没那么优雅，尤其当域名管理员、邮箱管理员、项目负责人三个人互相以为对方会处理的时候，证书就容易在角落里默默长草。

四、DNS 验证怎么做，别让一条记录卡住全场

AWS自动发货 DNS 验证是最常见也最关键的一步。拿到 ACM 给你的 CNAME 记录后，要去域名服务商或者 Route 53 里添加。这里有几个容易出问题的地方。

第一，记录值别手抖写错。CNAME 的主机名和目标值都要完全一致，少一个点、多一个空格，验证都可能失败。DNS 这东西看起来很温柔，实则非常讲原则，像个一丝不苟的老会计。

第二，不要急着删验证记录。很多人证书签发后，看到记录“好像没用了”，就顺手清掉。其实验证记录在后续续期里可能还会派上用场，尤其是你希望 ACM 自动续期顺畅的时候，留着通常更稳妥。

第三，如果你使用的是第三方域名解析，注意解析生效时间。DNS 不是秒到账，有时候需要等一会儿，短则几分钟，长则更久。这个阶段最忌讳的就是连续刷新一百次，然后开始怀疑人生。建议先喝口水，再回来看看状态。

五、在 ALB 上绑定 SSL 证书

如果你的架构里有 ALB，那么 SSL 配置会轻松很多。打开负载均衡器，找到监听器，新增 443 端口的 HTTPS 监听。然后选择你在 ACM 里申请好的证书，保存即可。ALB 会帮你处理外部的加密连接，用户访问时看到的就是安全小锁。

配置完成后，还要检查后端目标组是否正常。通常 ALB 到后端可以使用 HTTP，也可以使用 HTTPS，具体看你的安全要求和内部架构。很多场景里，外部使用 HTTPS，内部使用 HTTP 也没问题，只要你的 VPC、子网、安全组设置合理。但如果你想更严格，当然可以内外都加密。毕竟安全这事儿，像保险，不怕多，就怕漏。

还有一个常见动作是把 80 端口强制重定向到 443。这样用户即使输入了 http:// 也会自动跳到 https://，体验更统一，也更利于搜索引擎识别。不过重定向要小心循环跳转。你可以在 ALB 里直接设置监听规则，把 80 请求重定向到 443，这种方式通常很干净，少写很多服务器规则。

六、CloudFront 场景下的 SSL 细节

CloudFront 的 SSL 配置看起来简单，实际上细节不少。首先，证书必须在 us-east-1 区域申请，这是铁律。其次，如果你自定义域名要绑定到 CloudFront，证书里的域名也必须覆盖这个自定义域名，比如 cdn.example.com。如果你只申请了根域名，结果却拿去给子域名用，浏览器不认账，还是会跳安全警告。

CloudFront 还有一个值得注意的地方：你可以设置 Viewer Protocol Policy，也就是用户到 CloudFront 的协议策略。一般建议直接强制 HTTPS，或者至少重定向到 HTTPS。这样用户访问时不会有混乱。至于 CloudFront 到源站的回源协议，也要根据你的源站能力设置。如果源站支持 HTTPS，建议也用 HTTPS 回源；如果暂时不支持，那就先保住前端加密，后续再逐步完善。

如果你的源站是 S3 静态网站托管，还要特别注意 S3 静态网站终端和 S3 REST 终端的区别。很多人一开始把对象存储当成普通网站服务器，结果发现 HTTPS 配置绕来绕去。说白了，S3 本身并不直接像传统服务器那样给你装证书，通常要靠 CloudFront 这一层来承接外部 HTTPS 请求。

七、EC2 上手工配置 SSL：Nginx 与 Apache 怎么选

如果你坚持在 EC2 上自己动手，先看你用的是 Nginx 还是 Apache。两者都能做 SSL，思路类似，但配置语法不同。Nginx 更像效率派，配置简洁，性能也不错；Apache 更老牌，功能全，历史包袱也更厚一点。两者没有绝对谁更好，更多看你团队熟悉哪一个。

以 Nginx 为例，一般要做几件事：准备证书文件、准备私钥文件、配置 443 server 块、开启 SSL 协议和加密套件、设置 80 到 443 的跳转。这里最重要的是证书链要完整，尤其是中间证书不要漏。很多“证书明明安装了却还是不安全”的问题，最后都栽在证书链上。浏览器可不管你多辛苦，它只看结果，不看你昨晚睡了几个小时。

Apache 也类似，需要在虚拟主机里启用 SSL 相关模块，然后配置证书路径、私钥路径和重定向规则。如果你是从别的服务器迁移过来，别忘了检查路径权限、安全组端口和防火墙。AWS 安全组是第一道门，系统防火墙是第二道门，服务配置是第三道门，哪道门忘开都不行。

八、AWS 账号里的安全组、端口与证书之间的关系

SSL 配置之所以容易翻车，很多时候不是证书本身的问题，而是配套环境没跟上。比如你证书已经装好了，但安全组没放行 443，外部访问照样进不来。又比如 80 端口放行了，443 没放行，结果 HTTP 能进，HTTPS 没法用，这就像给客人开了正门，却把电梯钥匙藏起来了。

所以在 AWS 账号里做 SSL 配置时，建议同时检查以下几点：EC2 或负载均衡器是否开放 443；安全组是否允许对应来源访问；网络 ACL 是否有额外限制；域名解析是否指向正确的公网地址；证书是否覆盖实际使用的域名。把这些项一条条核对，通常比盲目重装靠谱得多。

九、强制 HTTPS：别让用户在明文里裸奔

证书装好以后，并不代表工作就结束了。真正稳妥的做法，是把网站的所有 HTTP 请求都重定向到 HTTPS。这样不仅安全，也避免用户用旧书签、手输地址、第三方链接时走错协议。

在 AWS 里，常见的强制 HTTPS 方式有几种：ALB 监听器重定向、CloudFront 跳转策略、Nginx/Apache 服务器端重写。具体选哪种，取决于你的流量入口在哪儿。若入口在 ALB，优先在 ALB 做；若入口在 CloudFront，就在 CloudFront 做；若是 EC2 直出，就在 Web 服务器里做。原则很简单：谁接流量，谁负责把路带正。

另外，如果你的网站涉及登录、支付、表单提交，HTTPS 就更不是可有可无了。明文传输不仅容易被窃听，还会影响浏览器对 Cookie、跨域、现代接口的处理。很多前端功能一旦没有 HTTPS，表现就像穿着拖鞋去跑马拉松，没跑两步就开始崴脚。

十、证书续期与日常维护：别等过期了才想起它

AWS ACM 的优势之一就是支持自动续期，但前提是域名验证状态正常、证书绑定关系正常。如果你中间改了 DNS、删了验证记录、换了域名服务商，续期可能会出问题。虽然大部分情况 ACM 会尽量帮你兜底，但运维这件事，最怕“我以为没事”。

建议把证书到期时间纳入监控。哪怕是 ACM 托管证书，也可以定期查看状态，确认绑定的 ALB、CloudFront、API Gateway 都正常。对于手工导入的证书，更要格外留意到期日。证书过期这件事，很像出租屋忘交水电费，平时不显山露水，一到点就给你来个现场教育。

如果你的企业有多个账号、多个环境、多个域名，最好统一管理证书和域名策略。不要今天一个人申请，明天另一个人又重来一遍。统一规划之后，不仅减少重复劳动，也更容易排查问题。毕竟真正可怕的不是复杂，而是复杂得没有章法。

十一、常见问题与排查思路

1. 浏览器提示证书不受信任

先看域名是否匹配，再看证书链是否完整，然后检查是不是用了自签证书却拿来对外服务。如果是 ACM 证书，确认绑定的 AWS 服务是否正确，证书状态是否已签发。

2. 证书已经申请，但一直处于待验证

大概率是 DNS 验证记录没加对，或者解析尚未生效。检查 CNAME 主机名和值是否完全一致，不要多一个空格，也不要少一个点。

3. HTTPS 能访问，但页面部分资源报错

这通常是混合内容问题。页面用了 HTTPS，但图片、JS、CSS 里还引用了 HTTP 资源。把资源链接统一改成 HTTPS，或者使用相对协议和同源资源，问题一般就能解决。

4. ALB 已绑定证书，但外部还是打不开 443

检查安全组是否放行 443，监听器是否创建成功，目标组健康检查是否正常。很多时候不是证书没生效，而是门口根本没开门。

十二、实操建议：新手最稳的 AWS SSL 路线

如果你是第一次在 AWS 里配 SSL，建议优先走这条路线：域名解析使用 Route 53 或稳定的第三方 DNS，证书使用 ACM 公有证书，入口尽量用 ALB 或 CloudFront，外部强制 HTTPS，后端按需是否继续加密。这样一套下来，维护成本低，扩展性也好。

如果项目很小，确实可以先在 EC2 上手工配置，但从长远来看，还是建议逐步迁移到托管证书和负载均衡方案。把精力花在业务上，比天天和证书过期搏斗更值。毕竟我们做系统，是为了让服务稳定，不是为了和凌晨的告警铃培养深厚感情。

十三、结语：SSL 配置不是玄学，关键是顺着链路走

AWS 亚马逊云账号 SSL 配置并不神秘，真正难的地方在于服务多、层级多、入口多，一旦某一步没接上，就会出现“看起来都对，实际上哪里都不对”的局面。只要你顺着链路梳理：先申请证书，再做域名验证，然后绑定入口服务，最后检查安全组、跳转和续期，基本都能把问题解决。

说到底，SSL 配置的本质不是和控制台较劲，而是让用户安全、顺畅地访问你的服务。证书一装，浏览器不再皱眉，用户不再心虚，运维也少掉几根头发。这个结果，值。