ssl - 在Amazon EC2 ELB上安装SSL证书

Question

我是Amazon Web Services的新手，一直在尝试在EC2实例上安装SSL证书。我尝试遵循AWS文档，但发现令人困惑。然后，我按照http://www.robertbrewitz.com/2014/09/aws-and-setting-up-a-custom-ssl-certificate/上的指南进行操作。

我通过Go Daddy购买了SSL证书，并使用openssl生成了2个文件：

server.key
server.csr

指南说我应该得到3份证书：

DigiCertCA.crt
TrustedRoot.crt
star_yourdomain_com.crt

相反，我混淆地收到了两个名为：

f6f65901b1708ae5.crt
gd_bundle-g2-g1.crt

我认为 f6f65901b1708ae5.crt是我的域证书（但我不确定）。无论如何，该指南说我需要一个Elastic Load Balancer才能安装SSL证书，因此我创建了一个。

我使用以下命令生成了私钥：

openssl rsa -in server.key -text

并且公共密钥通过以下方式进行认证：

openssl x509 -inform PEM -in f6f65901b1708ae5.crt

还要求我输入证书链。我不确定这是什么以及如何获得它，所以我猜到了命令：

openssl x509 -inform PEM -in gd_bundle-g2-g1.crt

并输入以“ ----- BEGIN CERTIFICATE -----”开头的结果证书密钥

该指南继续说，然后我需要设置Cloudfront。我安装了aws命令行工具，并生成了我运行的PEM：

openssl rsa -in server.key -text > aws_private.pem
openssl x509 -inform PEM -in f6f65901b1708ae5.crt > aws_public.pem
openssl x509 -inform PEM -in gd_bundle-g2-g1.crt > aws_public.pem 

我将SSL证书上传到：

aws iam upload-server-certificate --server-certificate-name mydomain_com \
--certificate-body file://aws_public.pem --private-key file://aws_private.pem \
--certificate-chain file://aws_chain.pem --path /cloudfront/mydomain_com/

这是成功的。

然后，我必须选择一个SSL证书来创建一个Cloudfront发行版。

但是，当我转到https url（ https://www.example.org/）时，它不起作用。 http://www.example.org/但是有效。

由于安装SSL证书有很多步骤，我怀疑我在此过程中犯了一个错误。问题是，我不知道在哪里。有人有指针吗？

此外，没有任何更简单的方法来安装SSL证书吗？对于如此常见的事物来说，它似乎非常复杂。我愿意付钱给我一个专家（我是一个几乎不了解SSL相关知识的软件开发人员），但是很难找到任何人来完成这样的任务（而且存在必须解决的问题）交出登录详细信息等）。任何帮助，不胜感激。

编辑

下面的建议是我应该使用 AWS Certificate Manager。我看了看，这似乎是一个更轻松的选择。但是，我确实在Go Daddy上花了86欧元购买SSL证书，所以我希望这不会浪费。我的工作可以挽救吗？是否有意转售SSL证书？

编辑

我仍然没有找到真正的解决方案。澄清一下，我有一个非常小众的网站，访问者很少。我的网站位于EC2实例上。我跟踪了上面建议使用Load Balancer和Cloudfront以便通过SSL加密的站点。但是，它无法正常工作，而且无论如何可能已经过头了。谁能帮我这个？我想使用自己购买的SSL证书，但是如果没有，应该使用Lets Encrypt之类的东西吗？

Answer 1

您提到了指南，该指南说应该包含3个文件，其中包括“ DigiCertCA.crt”文件。听起来好像是使用DigiCert作为您的证书提供者而写的，而不是GoDaddy。

证明书

首先，确保“ f6f65901b1708ae5.crt”包含您所请求的证书（并在那里保留任何疑问）。为此，您可以将“ server.csr”文件（即证书签名请求）中的数据（例如，通用名称（CN），DNS主题备用名称（SAN）等）与该“ f6f65901b1708ae5.crt”中的内容进行比较”文件：

$ openssl req -noout -text < server.csr

这应该在CSR文件中显示有关您的域详细信息的可读文本。与以下内容进行比较：

$ openssl x509 -noout -text < f6f65901b1708ae5.crt

这应该显示类似人类可读的文本，并填充更多的详细信息/字段。但是它们应该大致具有您的期望。请注意，如果您看到与此类似的错误：

51299:error:0906D06C:PEM routines:PEM_read_bio:no start line:/SourceCache/OpenSSL098/OpenSSL098-52.40.1/src/crypto/pem/pem_lib.c:648:Expecting: TRUSTED CERTIFICATE

这表明您的“ f6f65901b1708ae5.crt”文件为DER格式，而不是PEM格式。如果不是，则您已经有一个PEM文件，这正是AWS ELB所期望的。如果您拥有DER格式的证书，则可以使用以下方法轻松转换为PEM格式：

$ openssl x509 -in f6f65901b1708ae5.crt -inform DER -out f6f65901b1708ae5.pem -outform PEM

我只想通过提及这一部分来做到透彻。

现在，假设我们知道“ f6f65901b1708ae5.crt”包含您所在域的PEM格式的证书，那么我们准备处理“证书链”部分。

我查看了GoDaddy的 online certificate repository，以查看您提到的“ gd_bundle-g2-g1.crt”文件是否存在。 （可以公开使用这些文件，因为它们包含供任何人/所有人使用的公共证书。）查看该 gd_bundle-g2-g1.crt文件，我发现它包含多个证书。这个很重要。

请参阅，“证书链”是提供信任路径（或“链”）的文件列表，从您拥有的“ f6f65901b1708ae5.crt”证书到受信任的根GoDaddy CA证书。每个证书都有一个主题（颁发给谁）和一个颁发者（颁发给谁）。这意味着您可以从证书到颁发者的证书，再到该证书的颁发者的证书等“向后”走。向后走就是“证书链”。

“ gd_bundle-g2-g1.crt”文件包含多个证书的事实表明该文件包含您需要的证书链。这也意味着您不想这样做：

$ openssl x509 -inform PEM -in gd_bundle-g2-g1.crt > aws_public.pem

因为 openssl x509仅读取指定文件中的第一个证书，因此您需要所有这些证书。

鉴于以上所有情况，您可能仅需要以下内容（以确保私钥是PEM格式的）：

$ openssl rsa -in server.key -text > aws_private.pem

然后，由于我们假设“ f6f65901b1708ae5.crt”已被PEM格式化（如果没有，您将在上面进行转换），并且我们知道“ gd_bundle-g2-g1.crt”已被PEM格式化，我们现在准备将它们上传到AWS ELB。

AWS ELB

要上传证书和密钥以供ELB使用，请使用类似以下的内容：

$ aws iam upload-server-certificate \
  --server-certificate-name redmatterapp_com2 \
  --certificate-body file://f6f65901b1708ae5.crt \
  --private-key file://aws_private.pem \
  --certificate-chain file://gd_bundle-g2-g1.crt \
  --path /cloudfront/redmatterapp_com/

请注意，我使用了不同的 --server-certificate-name，只是为了确保它不会覆盖/与您的现有配置冲突。作为建议，您可以在名称中包含创建上传证书的日期（或者更好的是，证书何时过期），以提示您将来添加该证书的时间，例如“ redmatterapp_com-2016-02-18”。

另请注意，如果您不使用CloudFront，则不应使用 --path选项。如果您使用的是CloudFront，然后将其删除，则强烈建议您再次执行上述 aws iam upload-server-certificate命令，仅使用不同的 --server-certificate-name并且不使用 --path选项（并删除先前的名称）。这可能意味着需要重新配置任何现有的ELB HTTPS侦听器以使用新的证书名称，但这可能是必需的，因为 --path会影响SSL处理。

完成上述操作后，请使用在AWS Console上，您应该能够配置AWS ELB，然后在“侦听器”选项卡下，单击“编辑”。添加侦听器，例如代表“ https”。添加任何支持SSL的侦听器时，您会在“ SSL证书”列/标签下看到“更改”链接。单击该“更改”，然后选择“现有证书”按钮。然后，在“证书名称”下拉菜单下，您应该看到上面使用的 --server-certificate-name字符串/标签的条目。选择该条目，然后单击“保存”。现在，应该为浏览器将信任的SSL / TLS连接正确配置与您的AWS ELB上的该侦听器的连接。

因此，HTTPS侦听器配置如下所示：


负载均衡器协议：HTTPS
负载均衡器端口：443
实例协议：HTTP
实例端口：80
密码：（默认策略）
SSL证书：（ --server-certificate-name名称）


请注意，您也不想将端口443用作实例端口。如果这样做，则表示您希望从ELB到实例使用HTTPS，这通常是不需要的。 （某些安全站点希望这样做，但这是一个不同的主题/存储。）因此，以上内容将ELB配置为处理SSL终止；到实例上的Node.js服务器，它只会在端口80上收到纯HTTP请求：

client ---> HTTP ---> ELB port 80 ---> HTTP ---> server port 80
client ---> HTTPS --> ELB port 443 --> HTTP ---> server port 80

如果您的服务器需要知道原始请求是HTTP还是HTTPS，请查找AWS ELB将 automatically add to the request的 X-Forwarded-For（以及其他请求标头）。

现在，配置好ELB后，这是验证其正常工作的好步骤。首先，可以使用 openssl s_client验证SSL握手是否有效：

$ openssl s_client -connect example.com:443
CONNECTED(00000003)
depth=3 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=redmatterapp.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=example.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
---
SSL handshake has read 4929 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    ...
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

上面的代码表明我们已经成功完成了SSL握手，您可以看到它显示了带有GoDaddy名称的证书链。 “服务器证书”部分应与您加载的“ f6f65901b1708ae5.crt” PEM文件匹配。

HTTPS和DNS

现在测试HTTPS部分；为此，我喜欢使用 curl，如下所示：

$ curl -kv https://example.com/

-v选项显示更多信息，尤其是证书是否与DNS名称匹配。 -k告诉 curl忽略任何证书不匹配/问题，以便我们然后可以查看有关事物的详细信息。

这是需要更多配置的地方。如果在 curl命令（或浏览器）中使用自动生成的ELB DNS名称，则很可能会看到安全警告/问题。为什么？因为HTTPS的一部分正在验证您在URL中使用的DNS名称是否与服务器证书中的域名/主机名匹配，所以可以作为证书中的公用名（CN）或作为DNS使用者备用名称（SAN）之一。而且您可能没有在向GoDaddy的证书签名请求（CSR）中包含ELB DNS名称。

那么，这意味着下一步是配置指向AWS ELB名称的DNS CNAME记录，例如：

www.example.com CNAME to aws-elb-1.elb.amazonaws.com

如果您将AWS用于DNS，则可以使用例如路线53。然后重试 curl命令（或浏览器）：

curl -kv https://www.example.com/

要注意的另一件重要事情（您可以在 curl -v输出中看到）是 Host请求标头的内容。某些HTTP服务器（即在后端实例上运行的HTTP服务器）对此值非常挑剔。他们希望 Host标头匹配其配置中的某些内容，如果不匹配，他们可能会拒绝该请求。

另一个常见的陷阱是：


HTTP 503服务不可用：后端服务器已满负荷


如果您从ELB收到此响应，则通常意味着您的后端服务器没有响应或无法响应ELB healtcheck。仔细检查用于ELB healtcheck的端口和路径/ URL是否正确，并且所有防火墙或AWS安全组均允许从ELB到您的实例的连接。

因此，现在您应该有了一个ELB，它可以将端口80（HTTP）和端口443（HTTPS）转发到您的后端实例。并且您在DNS中具有指向该ELB名称的“ www.example.com”的CNAME记录。还剩什么？

HTTP重定向

我强烈建议将您的HTTP服务器配置为始终重定向到同一URL的等效HTTPS。为什么？

为了确保客户端和服务器之间的数据安全，现在应该使用SSL / TLS。如此之多，以至于越来越多的浏览器首先自动尝试使用HTTPS，而仅仅以HTTP作为回退。诸如Chrome（和其他浏览器）之类的浏览器都希望避免这种HTTP后退，以至于他们引入了诸如 HTTP Strict Transport Security之类的机制：一种让您的网站告诉浏览器仅对该网站使用HTTPS而不使用HTTP的方法。另外，它总是一个更好的营销故事；实际上，如果不使用HTTPS，您可能会从客户端/用户那里得到负面反应。

使用HTTPS处理您的所有网站流量还有另一件事，这可以防止您受到攻击：使用其DNS名称和您的ELB的其他人。您具有“ www.example.com”的CNAME记录，该记录指向“ aws-elb-1.elb.amazonaws.com”。但是，如果我还为“ www.evilco.com”创建了自己的CNAME，该CNAME指向相同的“ aws-elb-1.elb.amazonaws.com”，该怎么办？访问“ www.evilco.com”的人们会看到您的网站，并认为这是我的！

通过将您网站的所有流量强制为HTTPS，可以强制所有HTTPS客户端验证服务器提供的证书（即“ f6f65901b1708ae5.crt”文件）是否包含通用名（CN）或DNS使用者替代名（ SAN）与客户端在其URL中使用的域名相匹配。显然，您的证书不包含“ www.evilco.com”的CN或DNS SAN，因此验证过程将失败-最终用户将发现有些可疑。但是，如果您还允许站点使用HTTP通信，则可能会发生这种现象-而且，您查看站点的日志将永远不会知道！

后记

我本人没有使用过AWS Certificate Manager或CloudFront（因此我无法对其进行评论），但是我多次使用以上过程对多个域的多个证书进行多种工作。

希望这可以帮助！