Recently we were faced with a critical problem whereby our company website (E-Commerce platform) was not accessible. It threw a 301/302 error. This platform is used for subscribers to purchase reloads, subscribe to new plans and so forth.
When we ran a curl command to troubleshoot further, this was the error we found :
[oracle@ecwebapp01 ~]$ curl https://connect.telenordigital.com/oath
curl: (35) SSL connect error
We compared the output with another staging platform, which did not have this connectivity problem. Thus we compared the configurations in the test server with the production server, and found that the openssl for both the production and staging were same :
Production :
[root@ecwebapp01 digi_aigini]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
[root@ecwebapp01 digi_aigini]#
Staging :
[root@ecappstg01 digi_aigini]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
[root@ecappstg01 digi_aigini]#
The management confirmed that the certificates in the production had not expired. And to prove this, we copied the certificates from the production to the staging, and the staging server was still able to access the site.
We finally checked the Load Balancer (All the E-Comm servers are connected to the LB), and we found that the communication between the production server and the website used ssl v2, whereas the staging used TLSv1.2.
And because of this, the head of department guessed that the team that was responsible with managing the website we were trying to access had blocked the ability to use the old ssl version. We called the team to confirm, and true enough this was the reason of the problem.
However, I am still unclear of why the ssl version for both the servers vary. According to my team lead, only the Load Balancer is configured to use the SSL.
Not the servers. So my question is how did the LB get the information of the different SSL versions for both the servers?