我真的希望有更多经验的人可以帮助我让我们的生产站点重新上线,因为我正在绞尽脑汁!
我刚刚更新了我们生产网站上过期的 SSL 证书,我创建了新的证书和密钥,然后在 Comodo 上订购了新的 SSL。自从我添加了新的 Comodo 签名证书和密钥后,我无法从任何以前使用过旧证书的网站的设备连接到我们的生产网站。但在 iPad 或 iPhone 上,一切正常。
如果我尝试连接,我在左下角看到的只是正在执行 TLS 握手,然后我收到页面不安全错误,我已经检查了以下在线工具: https://www.ssllabs.com/ssltest/ 他们说 SSL 很好并且有效期到 2018 年 2 月。
下面是我的 nginx 配置文件,但是我开始认为这与浏览器缓存旧证书有关,因为我已多次重新启动服务器以查看是否会改变任何内容。
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
server_tokens off;
return 301 https://$host$request_uri;
}
server {
listen 443;
server_name *;
server_tokens off;
ssl on;
ssl_certificate /jet/etc/nginx/ssl/cert.crt;
ssl_certificate_key /jet/etc/nginx/ssl/key.key;
error_page 403 https://$host/404;
error_page 404 https://$host/404;
root /jet/app/www/public;
index index.php index.html index.htm;
autoindex on;
# Load configuration files for the default server block.
include /jet/etc/nginx/conf.d/*.inc;
}
我还附上了一张屏幕截图,但删除了域名,如果能得到任何帮助,我将不胜感激。在解决这个问题之前,我无法入睡,因此使用“我很恐慌”这句话是轻描淡写!
在一个浏览器上我得到以下信息:
www...... 使用无效的安全证书。该证书已于 2017 年 11 月 29 日 23:59 过期。当前时间为 2017 年 11 月 30 日 03:33。
这适用于已被替换的旧证书,而新证书直到 2018 年 2 月才到期。我已经验证过,该证书已从服务器中删除,但 Firefox 和除 iOS 之外的其他浏览器似乎认为它尚未被删除,这可能是由于缓存造成的,如果是这样...这是否意味着所有访问过该网站的访问者都会看到此消息,除非他们是唯一访问者?
答案1
你是否? :
# service stop nginx
# ps auxw|grep nginx
此时肯定已经没有存活的 nginx 了。如果还有的话kill
。之后:
# service start nginx
如果您停止并启动 nginx,并确保“停止”确实终止了该过程并且/jet/etc/nginx/ssl/cert.crt
确实指向新证书(通过使用 进行双重检查cert.crt
,openssl
验证Validity
字段是否处于正确的日期)那么 nginx 就不可能再使用旧证书。
另外,你确定是 nginx 接收连接吗?也就是说,如果你执行host www.your.site
并连接到该 IP,ssh
然后在那里执行netstat -npa|grep 443
,那么你得到的进程实际上是 那nginx 而不是其他代理(varnish、apache、haproxy、docker 获取连接等)?
如果事实上是nginx 正在获取连接,然后你有在 nginx 日志中查看该连接是否由其提供服务/var/log/nginx/*.log
。
如果您的 nginx 设置更复杂,则可能会有多个配置项设置证书。所以请执行grep -r ssl_certificate /etc/nginx
。证书是否仅在一个地方设置,还是有多个站点在设置它?是否ssl_certificate
使用了另一个设置而不是您想要的设置?
另外,确保它不是低级数据包重写或将连接移动到其他地方:检查iptables -L
和iptables -t NAT -L
。
答案2
您是否将 Comodo CA 包添加到了证书中?您应该已经收到它或证书中的链接。它需要添加到证书文件中的站点证书之后才能与 nginx 配合使用。要测试您的证书,请使用Qualys SSL 测试。
答案3
我看到你已经找到了答案,但我会添加我自己的经验,希望它能对其他人有所帮助。
我在安装 DigiCert 的自定义证书后遇到了类似的问题,该证书是在没有發行人内部域的引用字段。相反,DigiCert 提供了发行者证书客户端可以将其安装在本地钥匙串中。Chrome 和 Firefox(可能还有其他我尚未检查过的浏览器)将使用您的本地钥匙串,并跟踪 URI,直到找到由受信任的证书颁发机构如果浏览器无法在预配置的集合中找到颁发者证书。这被称为遵循“信任链”。
蟒蛇要求库(基于urllib3),而出于安全考虑,不会遵循信任链。它只会使用由python-certifi项目。当我编写 Python 脚本来访问此 Web 服务时,我收到了与您描述的类似的错误消息。证书有效。urllib3 无法验证它,即使我将其安装在主机钥匙串中也是如此。
为了继续,我写了证书会话Python 包。你可以在这里阅读更多相关信息文章。
因此,您的 nginx 配置似乎没有任何问题。您的 iPhone 和 iPad 上的客户端可以验证证书,因为它们会跟踪颁发者链接,直到找到受信任的证书颁发机构。但是,其他设备上的客户端不会遵循信任链。因此,它们不会验证证书。
当您运行安装脚本在本地安装颁发者证书时,该问题可能已得到解决。这是我的合理猜测。