RDBMS -- TLS 1.2 support and issues ORA-29263: HTTP protocol error & ORA-29024: Certificate validation failure

Recently dealed with a SSL web service call-related problem.
Developers were trying to call a web service by executing a stored procedure residing in the Oracle Database.
The database version was 11.2.0.3, and the web service calls ended up with the following;

ERROR at line 1:
ORA-29273: HTTP request failed
ORA-06512: at "SYS.UTL_HTTP", line 1369
ORA-29263: HTTP protocol error
ORA-06512: at line 9

We directly applied the Patch 13517951: UTL_HTTP FAILS ACCESSING HTTPS SITE IN 11.2, but the issue remained..

This was easy to diagnose actually. After doing a little research and analyzing the traffic (by getting a tcpdump and analyzing it with wireshark), we could conclude that the traffic was TLS 1.2..

Oracle Database 11.2.0.3 can not communicate with TLS 1.2, so we recommended a database upgrade.. -> Upgrade to 11.2.0.4 and apply Oct PSU.

As 11.2.0.4 Oct 2018 DB PSU contain MESv415..

Note that: MES is short for RSA BSAFE Micro Edition Suite which is a software development toolkit for building 

cryptographic, certificate, and Transport Layer Security (TLS) security technologies into C and C++ applications, devices and systems. With release of Oct 2018 PSU, all supported DB versions use RSA BSAFE toolkit MESv415 or greater.

After upgrading the database and applying the Oct 2018 PSU, the error changed ..

Now the web service calls were failing with the following;

ERROR at line 1:
ORA-29273: HTTP request failed
ORA-06512: at "SYS.UTL_HTTP", line 1130
ORA-29024: Certificate validation failure
ORA-06512: at line 8

It was obvious that the certificates in the wallet could not be validated..

Still , we wanted to diagnose the issue;

We even got 10937 trace , but the traffic was looking good.

Then we decided to analyze our wallet and the certificates inside of it..

The wallet should include only the signing certificates, because during the SSL handshake Oracle checks whether the signing authority is known to it (i.e. whether the certificates of the signing authority was imported into the wallet). 

We saw that, the last certificate in the certificate chain was user certificate, not a trusted one. So , this shouldn't be imported into the wallet as a trusted certificate. 

So we removed that user / server / leaf certificate from the wallet and the error dissapeared :)

Yes..I know that these SSL/TLS-related configurations can be tricky sometimes, so I wanted to share this with you..