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

problems and solutions

        Let me first describe the problem and solution here. Many students don't care much about the background of what happened.

 Problem appearance

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

problem solution

        It must be a domain name access certificate problem, either the https certificate is invalid, or the domain name has not applied for an https certificate. It can be considered and solved from these two aspects. Our solution is to use http domain name to access because the pure intranet service does not have an https certificate.

Problem Description

        Last night, a small partner of the team had a renewed launch. After the launch, the group communicated that it was fully compatible with the old business, and the front-end was also integrated. Even if the front-end is not released, it will not have any impact. Then everyone went home happily.

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

        As a result, the accident came in a timely manner. I was still in the car on my way home and received an alarm. Immediately afterwards, the test students began to report problems in the business group in the group. At that time, the "xxxxx" in my heart. In fact, you can also see what the alarm is on your mobile phone (pictured below), but the students in charge of going online have never encountered similar problems. When I asked in the group if it was a domain name problem, they said no, and the feedback was in the pre-release The same domain name is used, and there is no problem with the pre-release. At that time, I wondered, since there was no problem with the pre-release, how could there be a problem when it went online, so I organized a system rollback in the group, and fortunately, the loss was stopped within 5 minutes.

 Root cause of the problem

        1、域名证书问题。

        2、FeignClient Apollo加载问题。

        In fact, the root cause of the problem is that https is used online to access dependent services, but the dependent services are pure intranet services and no https certificate has been applied for. As a result, using https to access the other party's domain name is blocked. It just doesn't match the available certificate.

        But why do the online students say they use http access? I went to see the address configuration of Apollo. At this point, the case was solved. The relying party provided the http domain name at the beginning of development, but the development students thought that the online access should be https, so they changed it to the https domain name, which caused problems. As a result, after the error was reported, the configuration bit of Apollo was directly changed to http. But it still doesn't take effect, which leads to another problem. It is because we use FeignClient to make http calls, and it is only loaded once at startup, which caused the development students to modify the Apollo configuration and it did not take effect.

 some thinking

        Still have some feelings about the problems described above.

1. R&D neglected the launch, and did not assess the impact.

2. The verification after going online, all the students did not do a good job in the verification after going online, but this problem will recur if one person completes the grayscale verification once.

3. It is true that environmental problems are not often encountered in our usual development, but we must know the general aspects when we encounter them, so I will record this problem for everyone to refer to.

Finally, I hope it can help everyone.

Guess you like

Origin blog.csdn.net/lly576403061/article/details/130123699