[SOLVED] Instant Client v19.9 throws "ORA-29024: Certificate validation failure" error but v19.6 does not

[TomRivers]

Hello!

I want to start this post by thanking the developers. I've been using cx_Oracle for almost a year now and it is absolutely fantastic - thank you!

I've been trying to trace the source of this problem for a few days now with no luck. Since I've been unable to find any information regarding how to debug this problem, I am hoping one of the gurus here can point me in the right direction.

1. What versions are you using?

   Oracle Database 12c Standard Edition 12.2.0.1.0 64bit Production
   platform.platform: Windows-10-10.0.19041-SP0
   sys.maxsize > 2**32: True
   platform.python_version: 3.9.1
   cx_Oracle.version: 8.1.0
   cx_Oracle.clientversion: (19, 9, 0, 0, 0)

2. Describe the problem

   If I use Instant Client v19.9, I get the following error when connecting to the database:

   cx_Oracle.DatabaseError: ORA-29024: Certificate validation failure

   If I use Instant Client v19.6, the error does not occur.

3. Include a runnable Python script that shows the problem.

   import os
   import cx_Oracle

   os.environ["TNS_ADMIN"] = r"E:\oracle\wallet"
   dsn = 'Production'
   instant_client_dir = r"E:\instantclient_19_9"
   cx_Oracle.init_oracle_client(lib_dir=instant_client_dir)
   cnx = cx_Oracle.connect(dsn=f"{dsn}", encoding="UTF-8")
   print("Connection established")

The above program fails with the aforementioned error. To make it work, all I have to do is change the value for instant_client_dir so it points to the older version.

I've validated the certificate chain using openssl and it shows no issues. If it helps, the following is my sqlnet.ora file:

  SQLNET.WALLET_OVERRIDE = TRUE
  SQLNET.AUTHENTICATION_SERVICES = (BEQ,TCPS,ALL)
  SSL_CLIENT_AUTHENTICATION=FALSE
  SSL_SERVER_DN_MATCH=YES
  
  WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA = 
      (DIRECTORY = %TNS_ADMIN%)
    )
  )

Can someone please point me to a resource that details how to get more information on what might be causing this? Thank you!

Tom

[cjbj]

We'll definitely ask around but your question is not related to cx_Oracle, so I suggest you open a support request - even if so this is tracked and the impact can be seen by Support.

PS, instead of "TNS_ADMIN", you can pass config_dir to init_oracle_client()

[cjbj]

If you have access to Linux, it would be interesting to see if 19.10 Instant Client is the same. (This version is currently only available on Linux. It was released yesterday)

[TomRivers]

Thanks for the tip for "config_dir"! As you suggested, I tried this on Linux too.

I used vagrant to provision a Fedora 32 box, configured everything, and ran the test. Here are my results:

System specs

platform.platform: Linux-5.9.16-100.fc32.x86_64-x86_64-with-glibc2.2.5
sys.maxsize > 2**32: True
platform.python_version: 3.8.6
cx_Oracle.version: 8.1.0
cx_Oracle.clientversion: (21, 1, 0, 0, 0)
cx_Oracle.clientversion: (19, 10, 0, 0, 0)
cx_Oracle.clientversion: (18, 5, 0, 0, 0)

Instant Client versions

v21.1 - cx_Oracle.DatabaseError: ORA-29024: Certificate validation failure
v19.10 - cx_Oracle.DatabaseError: ORA-29024: Certificate validation failure
v18.5 - worked

The system I am accessing is cloud based so I don't have anything other than credentials for the UI and the back end database. Since our organization is only licensed to use the product that leverages the Oracle database, I suspect I won't be able to register an account with My Oracle Support. Any ideas on how I might proceed?

Thanks!

[cjbj]

Thanks for testing.

The ownership will be with the DB security team. I haven't seen email so far from them about whether this is 'known'. I will probably end up logging a bug for this, so please share as much detail as possible: e.g. which cloud?

[TomRivers]

I really appreciate all your help and I'm happy to provide any information I can to you. Unfortunately I am not part of the team that is responsible for the product in question which means I don't have authorization to contact the company's help desk, but I'll do whatever I can.

With respect to the cloud question, according to whois the domain's IP address is part of Rackspace Hosting. What other information would be helpful?

[cjbj]

@TomRivers the code owners are not aware of issues and wonder about your configuration. To diagnose, they would want a lot of information - which is best shared via a Support service request.

• Complete version (i.e including PSU details) of the Server on which issue occurring. As in the July PSU, some strict certificate validations were pushed in.

• SQL*Net traces 16-level on both client and server(I.e in both working and non-working case).

• TCPDUMP capture in both working and non-working

  tcpdump - i any –w test.pcap --- root permission needed

• Client and Server wallet. (with password)

• sqlnet.ora (i.e client + server), listener.ora

I don't recommend putting this on GitHub. My email is in my profile, if you do care to send version & trace information. I also wouldn't send wallets via email.

[TomRivers]

Thank you very much for looking into this. Unfortunately, this is an application that contains PHI and is protected by some pretty strict laws so this is not an easy set of data to deliver. Also, I don't have the authority/access to give them everything they requested even if I wanted to.

As someone who has been a professional developer/architect for decades, I completely understand the need for more information when trying to debug a problem. This, however, is way over the line. It would be like my plumber asking me for the security code to my house, the keys to my car, and the combination to my safe in order to do home repairs. If they would like to give me code to run that will spit out more debug information other than a cryptic "ORA-29024: Certificate validation failure" message, I am happy to play ball. Otherwise, I think they are being unfair and asking way too much.

If they are willing to compromise and work with me, given the limited access I have, then I say let's move forward. Otherwise, I will unfortunately be forced to use the older client software or simply use another means of accessing the database to get what my team needs.

Please tell them the details of my situation and convey that I truly want to help them find the source of this issue. I'm sure if we put our collective heads together we can figure this out.

[stale]

This issue has been automatically marked as inactive because it has not been updated recently. It will be closed if no further activity occurs. Thank you for your contributions.

[TomRivers]

I noticed that Instant Client v19.10 was released so I tried the test program with that. Unfortunately, I am still getting the same error. Is there any plan to put more verbose error details in a newer release to help identify the cause of this?

[cjbj]

We did spend some time offline (as @TomRivers knows from email) looking at this and couldn't identify an absolute cause without having better access to trace information. I will prod the dev team about message improvements.