“This is the 10th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021.”

directory

  • The problem
  • To solve
  • At the end

The problem

Today, a cloud service was deployed on the public network in the form of a container. There was no problem in the test environment. I don’t know why there was a problem when I deployed to the beta environment, resulting in the HTTPS protocol file access failure.

The specific error information is as follows:

2021/11/09 07:15:58 http: TLS handshake error from 125.6494.138.:34428: remote error: tls: bad certificate\
2021/11/09 07:15:58 http: TLS handshake error from 125.6494.138.:36510: EOF\
2021/11/09 07:15:58 http: TLS handshake error from 125.6494.138.:39042: read tcp 172.17. 079.:9443->125.6494.138.:39042: read: connection reset by peer\
2021/11/09 07:15:58 http: TLS handshake error from 125.6494.138.:41490: EOF\
2021/11/09 07:15:58 http: TLS handshake error from 125.6494.138.:42006: read tcp 172.17. 079.:9443->125.6494.138.:42006: read: connection reset by peer\
2021/11/09 07:16:00 http: TLS handshake error from 125.6494.138.:42738: read tcp 172.17. 079.:9443->125.6494.138.:42738: read: connection reset by peer\
2021/11/09 07:16:01 http: TLS handshake error from 125.6494.138.:51154: read tcp 172.17. 079.:9443->125.6494.138.:51154: read: connection reset by peer\
2021/11/09 07:16:01 http: TLS handshake error from 125.6494.138.:33806: read tcp 172.17. 079.:9443->125.6494.138.:33806: read: connection reset by peer\
2021/11/09 07:16:01 http: TLS handshake error from 125.6494.138.:34836: read tcp 172.17. 079.:9443->125.6494.138.:34836: read: connection reset by peer\
2021/11/09 07:16:01 http: TLS handshake error from 125.6494.138.:35318: read tcp 172.17. 079.:9443->125.6494.138.:35318: read: connection reset by peer\
2021/11/09 07:16:16 http: TLS handshake error from 125.6494.138.:34338: read tcp 172.17. 079.:9443->125.6494.138.:34338: read: connection reset by peer\
2021/11/09 11:24:42 http: TLS handshake error from 209.1797.114.:65306: EOF\
2021/11/09 13:46:06 http: TLS handshake error from 89.248174.193.:39762: EOF\
2021/11/09 15:51:50 http: TLS handshake error from 165.227163.245.:38494: EOF
Copy the code

Through the error message, it is generally speculated that the handshake failure may be caused by the certificate. The specific reason is not clear, at least it is a direction for analysis and thinking.

Further analysis of error logs shows that during the handshake process, the machine whose IP address is 125.64.94.138 keeps trying to switch to another port, but the connection is reset each time, and the connection fails.

To solve

I searched a lot of materials on the Internet, but none of the methods introduced could solve my problems. Later, I found the reason when I sorted out the overall process. Because the container service itself supports both HTTP and HTTPS protocols, there is a layer of HTTPS certificate, which is not a problem in the test environment, but in the beta environment, all service access portals have to pass through the Nginx proxy service to forward requests. However, the Nginx service itself has a layer HTTPS certificate, which is inconsistent with the layer 2 certificate, causing an error.

Therefore, there are two solutions. One is to use only one layer of HTTPS certificate. The other is to unify the two-layer certificate and use the same signature certificate.

At the end

Sometimes, a lot of problems are difficult to find in the self-test, because it is not put into the specific production environment, therefore, the development process must take into account the future deployment of possible problems, try to avoid coding.

About the author: Hello, everyone, I am Liuzhen007, an audio and video technology fan, CSDN blog expert, Huawei Cloud community cloud sharing expert, signed the author, welcome to follow me to share more dry products!