-1

我使用命令添加了刚从 comodo 购买的 SSL 证书

cctrlapp xxxx/default addon.add ssl.host --cert certif.crt
         --key certif-nopass.key --chain SecureServerCA-bundle.crt

检查后我的命令没有得到任何响应

$ cctrlapp xxx/default addon ssl.host

Addon                    : ssl.host   
Settings

SSL_CERT_INCEPTS         : 2013-02-07 00:00:00

SSL_DNS_DOMAIN           : addonssl-depsmgr6bsx-1086693984.eu-west-1.elb.amazonaws.com
SSL_CERT_EXPIRES         : 2014-02-07 23:59:59

After accessing to the https
I have the error
The certificate is valid for the following domains :
  *.cloudcontrolled.com , cloudcontrolled.com  

(Error code : ssl_error_bad_cert_domain)

为什么SSL_DNS_DOMAIN表示这个子域名？

我刚刚使用命令检查了证书

openssl x509 -in certif.crt -text -noout

它是一个有效的 2048 RSA 密钥。

有任何想法吗？谢谢

4

1 回答 1

2

我假设您使用自定义别名。然后，当 DNS 更新时，您无需更改任何内容。您的子域上已经有一个 CNAME，指向“whatever.cloudcontrolled.com”。只需使用 HTTPS 访问您的域，然后您将获得您的证书（而不是 *.cloudcontrolled.com 证书）。

说“访问 https 后”是指您尝试使用 https 访问自己的域？

添加插件后，您必须等待两件事：

  • 您的个人负载均衡器将完成启动（当 SSL_DNS_DOMAIN 包含 dns 名称而不是“待定”之类的内容时，这将完成）。
  • 由于您的域的 IP 将更改，因此您必须等到此链中的 DNS-TTL 通过。这在 cloudcontrol-domain 上大约需要 5 分钟，然后取决于您自己的域 DNS 配置。

我想您的 dns-provider 或 cloudcontrol-TTL 可能遇到了 TTL 问题。或者可能是您的本地 DNS 缓存、浏览器 DNS 缓存、提供商 DNS 缓存……

一个不错的技巧（目前正在工作，但将来不必工作）：

dig在您的域上运行。

  • 当您获得一个 IP 时，SSL 完成并应该运行。
  • 当您获得多个 IP（现在为 testet，3）时，SSL 出现问题。

您还可以为 dig-command 指定特定的 DNS-Servers 以绕过缓存（google-dns-servers 始终是最新的）。

对于您的另一个问题： SSL_DNS_DOMAIN 仅向您显示已启动并将为您管理的 Amazon Elastic Loadbalancer。您不需要此名称，因为当您使用 SSL-Addon 查询“whateverapp.cloudcontrolled.com”时，您会获得 ELB-IP 之一。所以它只是为了提供信息，大部分不需要。

希望这可以帮助 ：）

于 2013-02-11T12:40:43.977 回答