AWS: CloudFront（CDN）的使用系列之三——实战及SSL证书的问题

系列

AWS: CloudFront（CDN）的使用系列之一——S3为例

AWS: CloudFront（CDN）的使用系列之二——Load Balancer(ELB)源为例

AWS: CloudFront（CDN）的使用系列之三——实战及SSL证书的问题

简介

本文基于笔者的一个项目进行讲解，在项目初期，由于访问量不大，从搭建一台虚拟机开始，到访问量逐渐增大，增加Load Balancer，直接最后加上CDN的项目的演进过程，每个过程都会贴出相应的架构图。

1. 一台虚拟机的情况

web网站是部署在虚拟机上(EC2)的，在此虚拟机上安装一个与example.com相关的证书，在Route 53 的域名解析处，我们加上了一个A 记录，将这个域名指向了此台虚拟机的IP，这样当用户访问https://example.com的时候，就可以安全地访问到我们的网站了。

2. 两台虚拟机+Load Balancer

随着访问量的增加，远远超过了一台虚拟机的负载，所以这里我使用了两台虚拟机并安装了与example.com相关的证书，然后在两台虚拟机上前面加一个Load Balancer作为负载均衡，它会将外部请求均匀地分发到这两台虚拟机上,这里使用了AWS的Load balancer服务，名叫Elastic Load Balancer(ELB), 更改一下Route 53处的A记录，将域名指向ELB的IP，而不再是指向EC2的IP，同样，为了外部能安全地访问我们的网站，需要在ELB上也安装与example.com相关的证书，具体的架构图如下。

3. 两台虚拟机+Load Balancer+CDN

随着访问量的进一步增长，用户会在全球各地访问到我们的网站，为了提升用户体验，我们在ELB 的前面加一个CDN，在AWS中的服务名叫CloudFront。这里CloudFront的源是使用得ELB，架构图如下所示：

这里我们将ELB的自定义域名（AMZLB2813-1776174616.us-east-1.elb.amazonaws.com）填入到Origin Domain Name, 这里Origin Protocol Policy选择Https Only，在Distribution Settings那里，我们也设置了一个CName(cdn.example.com)，我们称之为加速域名,并安装了相应的证书，但是当我们访问加速域名https://cdn.example.com时，它报了一个502的错误，如下图：

经过一番研究后，发现是证书不匹配的问题，当用户发起https://example.com请求，请求经过Route 53，这里设置的一个 CName，实际请求会被转发到加速域名https://cdn.example.com，由于此加速域名也安装了相应的证书，如上图，所以不是这里的证书问题。

用户第一次访问，通常CDN的边缘站点是没有缓存我们网站的静态资源的，所以CDN会向源站点发起请求，而发起源站的请求是https://AMZLB2813-1776174616.us-east-1.elb.amazonaws.com, 即ELB的自定义域名，但我们的ELB上只安装了https://example.com的安全证书，没有ELB的自定义域名的证书，所以这里发生了502错误。如果我们直接访问https://AMZLB2813-1776174616.us-east-1.elb.amazonaws.com 也同样遇到了502错误。

（1） 办法一：给ELB的自定义域名加上安全证书

既然ELB上没有https://AMZLB2813-1776174616.us-east-1.elb.amazonaws.com的安全证书，那我们直接安装此证书不就可以了吗? 但这个的域名前半部分看起来有点丑，且像乱码一样，要给这样的域名申请一个安全证书，明显不和谐，在公司找人帮忙申请也很难申请下来。

（2）办法二：使用http协议

用户的请求进入到CDN后，不再使用https协议，而且使用http协议，如下图，cloudFront访问源站点ELB采用http协议，ELB转发请求也使用http协议。就这样就解决了上面的502错误，整个项目可以正常使用，也起到了加速的效果。但这里也暴露了一个安全问题，ELB向外暴露了80端口，即外网可直接访问http://AMZLB2813-1776174616.us-east-1.elb.amazonaws.com，这里不符合公司的安全规定，所以我们必须还得一种思路。

（3）办法三：在CloudFront上使用自定义域名作为源

在CloudFront中，Origin Domain Name填入example.com, 这里Origin Protocol Policy选择Https Only。 当我们访问https://cdn.exmple.com时，CDN就可以起到加速的效果了，如果直接访问https://exmple.com，请求会直接进入ELB,CDN不是对进行加速。

由于我们的网站是另一个Portal网站的子站点，所以当用户通过 Portal网站访问到我们的网站的时候，直接访问https://cdn.example.com就可以了，现在的构架及证书都不需要作任何改动，正好符合的我们需求。

总结

看到这里就有人不禁会问了，https://cdn.example.com是加速域名，但通常https://example.com是程序的主站点，怎么反过来了通过https://cdn.example.com去访问https://example.com呢？ 这里主要是由于历史原因引起的，可以看到，上面只使用了两个域名和两个证书：https://cdn.example.com 和https://example.com的证书。如果将https://example.com作为程序的主站点的话，那需要三个域名及两个证书，https://alias-example.com作为自定义源加入到CloudFront中，架构图所下：