• 微信
    咨询
    微信在线咨询 服务时间:9:00-18:00
    纵横数据官方微信 使用微信扫一扫
    马上在线沟通
  • 业务
    咨询

    QQ在线咨询 服务时间:9:00-18:00

    选择下列产品马上在线沟通

    纵横售前-老古
    QQ:519082853 售前电话:18950029581
    纵横售前-江夏
    QQ:576791973 售前电话:19906048602
    纵横售前-小李
    QQ:3494196421 售前电话:19906048601
    纵横售前-小智
    QQ:2732502176 售前电话:17750597339
    纵横售前-燕子
    QQ:609863413 售前电话:17750597993
    纵横值班售后
    QQ:407474592 售后电话:18950029502
    纵横财务
    QQ:568149701 售后电话:18965139141

    售前咨询热线:

    400-188-6560

    业务姚经理:18950029581

  • 关注

    关于纵横数据 更多优惠活动等您来拿!
    纵横数据官方微信 扫一扫关注官方微信
  • 关闭
  • 顶部
  • 您所在的位置 : 首页 > 新闻公告 > 云服务器SSL配置失败怎么办?

    云服务器SSL配置失败怎么办?

    上个月有个做创意设计工具的朋友小何联系我,说他被一个问题折磨了整整两天。他们公司的设计协作平台要上线一个新功能,用户上传的作品需要走HTTPS加密通道,SSL证书已经买好了,配置也按照网上的教程一步步做了,但就是不行。他试了三篇不同的教程,换了两种配置方式,甚至重装了一遍Web服务软件,可是每次用浏览器访问的时候,要么提示连接被重置,要么提示SSL握手失败。他说他最后都快崩溃了,蹲在工位底下抱着头,觉得自己可能真的不适合干这行。

    我听他描述完症状之后,心里大概有了数。SSL配置失败这件事,说大不大说小不小,但它有一个很坑的地方,就是错误提示往往非常隐晦。浏览器的报错就那么几个字,什么“安全连接失败”啊,“无法建立安全连接”啊,根本不告诉你具体哪里错了。你翻Web服务的日志文件,里面可能也就是一行“SSL握手错误”的笼统信息,让人摸不着头脑。今天我就结合自己踩过的坑和处理过的案例,把SSL配置失败的各种可能性梳理一遍,希望能帮到正在被这个问题折磨的朋友们。

    先讲一个我自己早年犯过的错误,说出来有点丢人,但可能对大家有启发。那时候我刚接触云服务器不久,给一个个人博客配置SSL。我下载了证书文件,打开一看,里面有四五个不同后缀的文件,什么证书文件、私钥文件、证书链文件、根证书文件,我当时就懵了。我随便挑了两个看起来最重要的文件填到了配置里,然后重启服务,浏览器打开,显示“证书无效”。我又换了另外两个文件,还是不行。折腾了好几个小时,最后发现我配置的时候把私钥文件和证书文件的位置搞反了,而且证书链文件压根就没加进去。这个错误现在回头看很幼稚,但当时真的让我怀疑人生。

    实际上SSL配置失败的根源虽然五花八门,但我总结下来,大部分都可以归类到几个大的方面。下面我一条条展开说,尽量说透。

    第一类问题是文件本身的问题。你拿到的证书和私钥文件可能就有问题,这时候不管你怎么配置都是白搭。先说私钥,私钥是一段以特定格式保存的加密文本,它的开头和结尾都有明显的标记。如果你打开私钥文件发现里面是空的,或者内容明显不是正常的私钥格式,那这个私钥就没法用。还有一种情况是私钥的权限设置不对,很多人可能不知道,Web服务进程读取私钥文件的时候,如果这个文件的权限是所有人都可读的,有些严格配置的Web服务会拒绝加载,因为觉得私钥不应该这么暴露。你需要在系统里把私钥文件的权限改成只允许管理员读取,其他用户一律不能看。再说证书文件,证书文件和私钥是配套的,就像一把锁配一把钥匙。如果你把证书文件和另一把完全不搭的私钥凑在一起,Web服务启动的时候就会报错,提示私钥和证书不匹配。判断它们是否匹配有一个简单的办法,用系统自带的命令行工具分别查看证书和私钥的模数,如果输出的内容是一样的,那就是一对,不一样的话就说明你搞混了。

    小何当时遇到的情况,我让他先检查私钥和证书是否匹配。他查完之后告诉我,模数确实对不上。再一细问,原来他申请证书的时候操作了两次,第一次申请中途取消了,第二次才成功,但他下载证书的时候下载的是第一次申请的,私钥却是第二次生成的。这两次申请的密钥对完全不一样,自然配不到一起。他重新下载了配套的证书文件之后,第一个错误就消失了。

    第二类问题是证书链不完整。这个问题我在上一篇文章里提到过,在配置SSL的时候尤其值得单独拿出来再说一遍。很多人在配置的时候只配置了网站证书,忘了配置中间证书,结果浏览器拿到你的网站证书之后发现签发它的人不在信任列表里,往上找又找不到中间的信任链,就认为证书无效。这种情况的典型表现是,有些浏览器能正常访问,有些不能,或者同一个浏览器在有网络和没网络的时候表现不一样,因为有些浏览器会尝试从网上下载缺失的中间证书。解决这个问题的方法是在Web服务的配置里增加一个证书链文件的配置项,把你从证书颁发机构那里下载的证书链文件填进去。有的机构会把网站证书和中间证书合并成同一个文件发给你,那你就只需要配置一个文件。如果不确定自己配置的是否完整,可以用在线的SSL检测工具扫描一下你的网站域名,这些工具会非常明确地告诉你证书链是否完整,如果缺少中间证书,它会具体指出缺了哪一层。

    第三类问题是配置语法错误。这个主要看你用的是哪种Web服务软件。不同的软件配置文件的写法差异很大,有的用标签,有的用花括号,有的用空格缩进,有的用分号结尾。一个逗号放错位置,一个分号忘记写,甚至一个多余的空格,都可能导致配置根本加载不了。这种情况下你重启Web服务的时候通常会有明确的语法错误提示,告诉你第几行第几个字符附近有问题。很多人不看错误提示就盲目地去浏览器里测试,这是最浪费时间的做法。正确的习惯是,每次修改配置之后,先用Web服务自带的配置测试命令检查一遍语法,没有报错再重启服务。养成这个习惯,可以省下至少一半的排查时间。

    第四类问题是端口和防火墙。SSL有自己独立的端口,默认是四四三。很多人在配置的时候只改了Web服务的监听端口,但忘了在云服务商的控制台里给安全组加上一条允许四四三端口入方向的规则。结果就是,你从外面访问这个端口的时候,云平台的网络设备直接就把请求给丢了,根本到不了你的Web服务。还有操作系统自带的防火墙,也可能默认关闭了四四三端口。排查这个问题很简单,用网络工具测试一下你的云服务器的四四三端口是否是开放的,如果显示关闭或者被过滤,就去检查安全组和系统防火墙。还有一种情况是端口被其他程序占用了,比如你同时启动了另一个也监听四四三端口的服务,或者你之前测试的时候有个残留进程没杀掉,这时候新配置的Web服务就绑定不了端口,启动会失败。

    第五类问题是协议和加密套件不兼容。现在的浏览器和客户端对SSL的版本和加密算法有最低要求,如果你的服务器只支持那些老旧的不安全的协议版本,或者只配置了一些强度太低的加密套件,现代浏览器会拒绝连接。这种情况的表现是,在老旧的操作系统或者老版本的浏览器上能正常访问,但在新版Chrome或者新版Edge上反而打不开。解决办法是把Web服务的SSL配置更新到当前业界推荐的标准,关闭不安全的协议版本,只启用安全的加密套件。具体应该启用哪些,网上有很多现成的模板可以参考,找一个信誉好的安全博客上推荐的配置复制过来就可以。不过有一点要注意,如果你要兼容特别老的客户端,比如Windows XP上的老浏览器,那配置就要复杂一些,不过现在绝大多数场景下已经不需要考虑那么古老的系统了。

    第六类问题是域名和证书的匹配问题。这个我在上一篇文章里也详细说过,简单再提一下,就是你证书上的域名必须和用户浏览器地址栏里输入的域名完全一致,包括子域名的部分、包括带不带www。很多人在测试的时候用IP地址直接访问,但证书是针对域名的,不针对IP,所以用IP访问必然会报证书错误。还有一种情况是你用了负载均衡器或者CDN,SSL证书配置在了这些中间设备上,但你测试的时候直接访问了源站的IP,那同样会因为域名不匹配而报错。解决这类问题,就是要确保最终处理SSL请求的那个设备上的证书,能覆盖用户实际访问的那个域名。

    小何的问题在解决了证书不匹配之后,又冒出了一个新的毛病。他的Web服务能正常启动了,四四三端口也能连上了,但浏览器访问的时候进度条走了一半就卡住,最后超时报错。我让他打开浏览器的开发者工具,看网络请求那一栏,发现有一个字体文件加载了将近两分钟还没完成。这个字体文件是通过相对路径引用的,按理说应该正常,但仔细一看,这个字体文件的请求走的是HTTP而不是HTTPS。问题出在了哪里呢,原来他的网站代码里有一段JavaScript动态生成了这个字体文件的链接,写死成了HTTP协议。虽然主页面是HTTPS的,但这个字体文件因为是HTTP的,被浏览器的混合内容策略给拖住了,浏览器在等这个资源加载完成才渲染页面,但又被安全策略限制了,于是就卡在了那里。把那段代码里的HTTP改成HTTPS,或者改成协议相对的写法,问题就解决了。

    我还遇到过一种比较棘手的情况,就是云主机上运行着多个网站,每个网站都需要独立的SSL证书。这种情况下配置起来要格外小心,因为每个网站都要监听同一个四四三端口,但每个网站的证书又不一样。Web服务软件需要通过服务器名称指示,就是根据用户访问的域名来选择合适的证书返回给浏览器。如果你的配置里没有正确启用这个功能,或者不同网站的配置块之间有冲突,就可能出现访问网站A的时候,返回的是网站B的证书,浏览器自然就会报域名不匹配的错误。排查这种问题时,可以用命令行的工具来模拟访问,它能显示出来服务器实际返回的证书是给哪个域名的,这样就能清楚地看到是不是张冠李戴了。

    SSL配置失败还有一个非常隐蔽的原因,就是云主机的时间和时区设置。我前面在讲证书错误的时候提到过系统时间的问题,在配置SSL的时候,如果系统时间和真实时间相差太大,证书验证过程也会失败,但这个失败不是证书本身的问题,而是系统层面的时间偏差导致安全协议在计算时间窗口的时候出错。有些云主机在刚创建的时候时区可能是默认的UTC,如果你自己在里面手动改了时间但没有配置好时间同步服务,过一段时间系统时间就会慢慢漂移,最后漂出证书的有效期范围。配置好网络时间同步服务,让它定期自动校准,这个问题就能彻底解决。

    回到小何的案例,他最终把所有问题都解决之后,跟我说了一句话让我印象很深。他说以前觉得SSL配置就是把几个文件路径写到配置文件里就行了,没想到里面水这么深。我告诉他,其实没那么可怕,只要你理解了SSL握手的基本流程,知道浏览器和服务器之间要交换什么信息、要验证什么东西,配置起来就有了方向感,不会像无头苍蝇一样乱撞。

    总结一下,云服务器SSL配置失败的时候,按照下面这个思路去排查,基本不会漏掉关键点。第一,检查证书和私钥文件本身是否有效、是否配套、权限是否正确。第二,确认证书链完整配置了,不要只放网站证书。第三,测试Web服务的配置语法是否正确,养成修改后先测试语法再重启的好习惯。第四,检查四四三端口是否开放,包括云平台的安全组和系统的防火墙。第五,确认协议版本和加密套件的配置与当前浏览器的要求兼容。第六,确保证书上的域名和用户实际访问的域名完全一致。第七,留意混合内容的问题,所有页面资源都应该走HTTPS。第八,如果服务器上运行了多个网站,确保每个网站返回的证书都是匹配的。第九,校准系统时间和时区,并配置好时间同步服务。

    SSL配置这件事,第一次做的时候确实会觉得有些复杂,各种概念和术语堆在一起容易让人头大。但相信我,只要你真正亲手配置成功一次,把整个流程完整地走一遍,你就会发现它其实是有规律可循的,并不是什么玄学。以后再遇到类似的问题,你就能很快地定位到问题出在哪个环节,而不至于像小何那样蹲在工位底下怀疑人生了。



    最新推荐


    微信公众帐号
    关注我们的微信