我试图将预先存在的通配符SSL证书添加到Amazon EC2上的单个Ubuntu实例，其中networking服务器是Nginx，并且运行一个子域。
我有 – 从提供证书的原始供应商 – 名为private.key，selfsigned.crt和ssl-shared-cert.inc的文件。 我已经将这些file upload到了/ etc / nginx / ssl（这是我创build的一个新文件夹）的EC2。 我以前在Heroku上使用过相同的文件，虽然这个过程似乎是非常具体的。 他们也在我们的主域（ https://wwww.minnpost.com ）上使用，但是我并没有参与设置，因为我相信我们的托pipe供应商是为我们做的。
ssl-shared-cert看起来像这样：
SSLEngine On SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile "/path/to/selfsigned.crt" SSLCertificateKeyFile "/path/to/private.key" 在我的EC2实例上，我将网站的configuration更改为：
server { listen 8080; listen 443 ssl; server_name subdomainurl; ssl_certificate /etc/nginx/ssl/selfsigned.crt; ssl_certificate_key /etc/nginx/ssl/private.key; root path; ... }
当我运行sudo nginx -t我得到以下内容：
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
所以我跑sudo service nginx restart ，并且这个返回OK。 首先我检查，以确保HTTP版本仍然工作，它确实，但HTTPS仍然没有。 当我运行curl时，它会返回：
* SSL certificate problem: Invalid certificate chain * Closing connection 0 curl: (60) SSL certificate problem: Invalid certificate chain More details here: http://curl.haxx.se/docs/sslcerts.html
我可以从哪里出发？
如果证书实际上不是自签名的，那么我可以想到两种可能性。 首先是curl缺less一系列可信任的权限（Debian在一个名为ca-certificates的包中保存了一组可信ca-certificates ）。 如果是这种情况，那么没有https网站可以使用它。 你可以检查你的curl是否与其他网站工作？
如果curl正在工作，那么您所缺less的可能是签名者应该提供的证书链，它将证书上的签名与其中一个主要受信任的证书链接起来。 从这里的说明中，您应该将证书链（每个PEM格式的证书）添加到selfsigned.crt （服务器自己的证书必须是第一个）的末尾 。
DerkK所说的自签名证书是绝对正确的。 你需要一个不同的证书。 我有一个关于让我们encryption和Nginx的教程 – 这是相对简单的。