Certificate for ＜xxx.xxx.xxx.com＞ doesn‘t match any of the subject alternative names: [xxx..com]

问题和解决

        我这里先描述问题和解决方案吧。很多同学不太关心发生的背景。

 问题表象

Certificate for ＜xxx.xxx.xxx.com＞ doesn‘t match any of the subject alternative names: [xxx..com]

问题解决方案

        肯定是域名访问的证书问题，要么是https证书失效，要么是该域名没有申请https证书。 从这两个方面去考虑和解决即可。我们的解决方案是因为纯内网服务没有https证书，所以使用http域名访问解决。

问题描述

        昨天晚上团队的小伙伴有个续期上线，上完之后群里沟通说完全兼容老业务，前端也做了兼融，即使前端不发布也不会有啥影响。然后大家就很欢快的回家了。

        “如果不出意外的话意外就要出现了” 
                                    -- 来自东方的神秘预言。

        结果意外来的很是及时，我当时还在回家的车上，收到了报警，紧接着测试同学就在群里开始反馈业务群里有人报问题了。当时心里那个“xxxxx”。其实通过手机也能看到是啥报警（下图），但是负责上线的同学没有遇到过类似的问题，我在群里问的时候是不是域名问题的时候他们说不是，反馈在和预发使用的同样的域名，预发没有问题。当时我就纳闷了，既然预发没有问题怎么到线上就有问题了，就在群里组织系统回滚，好在5分钟内止损了。

 问题根因

        1、域名证书问题。

        2、FeignClient Apollo加载问题。

        其实问题根因就是线上使用的是https访问依赖的服务，但是依赖的服务他是纯内网服务，没有申请https证书。导致使用https访问对方域名被拦截了。就是没有匹配到可用的证书。

        但是为啥上线的同学说使用的是http访问呢。我就去看了下Apollo的地址配置。这一看就破案了，开始开发依赖方提供的就是http域名，但是开发同学以为线上都应该是https访问的就自己改成了https域名，导致出现了问题。结果报错之后直接改了Apollo的配置位http。但是还是不生效，有引出了另一个问题。是因为我们使用 FeignClient 进行http调用的，他只是在启动的时候加载一次，导致开发同学修改了Apollo配置之后没有生效。

 一些思考

        针对上面描述的问题还是有些感触的。

1、研发针对上线的疏忽，没有评估到到影响面。

2、上完线之后的验证，全部的同学针对上线完毕的验证没有做到位，但凡有一个人上完灰度验证一次就会复现该问题。

3、确实环境问题在我们平时的开发中不常遇见，但是遇到了就要知道大概的方面，所以我将本次问题记录下来，方面大家查阅。

最后，希望可以帮助到大家。