BUG: Oracle.ManagedDataAccess can't parse valid wallet file — oracle-tech

    Forum Stats

  • 3,715,657 Users
  • 2,242,821 Discussions
  • 7,845,481 Comments

Discussions

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

BUG: Oracle.ManagedDataAccess can't parse valid wallet file

Louis Haußknecht
Louis Haußknecht Member Posts: 3
edited January 2020 in ODP.NET

This took quite a bit of effort to figure out...

I'm connecting to my DB with tcps. I configured the WallettLocation like this:

   OracleConfiguration.WalletLocation = @(SOURCE=(METHOD= File)(METHOD_DATA = (DIRECTORY = /app/ )));

When connecting to the DB an exception is thrown: "TCPS: Invalid SSL Wallet (Magic)".

After spending hours of trying to configure the wallet location I started dotPeek and looked for the exception message in the assembly. It turned out, that in OracleInternal.Secure.Network.WalletReader there is a magic number defined  - which has a typo!

The correct magic number for a wallet should be 

A1 F8 4E 37 (161, 248, 78, 55)

But the client is expecting the following:

internal static byte[] a = new byte[4]

    {

      (byte) 161,

      (byte) 248,

      (byte) 78,

      (byte) 54

    };

I manually patched the wallet file and wrote a 37 to byte 3 and now it's working.

I found this in Oracle.ManagedDataAccess version 2.18.3 but it's also in the current version 2.19.60.

Comments

  • Mark Williams
    Mark Williams Member Posts: 67 Blue Ribbon
    edited January 2020

    Hi Louis,

    I know this won't help much and I am not saying there is not a bug here, but I am wondering if there is a difference based on the version of the wallet or how the wallet is created.

    I just used orapki from a 19.3 database home on Windows and here is the magic number in the created wallet:

    A1 F8 4E 36 (161, 248, 78, 54)

    This matches what the provider expects to find. I'm not a wallet expert and I have other problems with wallets but at least for this case there is a match between the wallet and the provider.

    Regards,

    Mark

    Louis Haußknecht
  • Alex Keh-Oracle
    Alex Keh-Oracle Posts: 2,751 Employee
    edited January 2020

    Hi Louis,

    There was an older bug in ODP.NET Core with similar symptoms that is now fixed. Can you verify the ODP.NET version you are using is indeed 2.19.60?

  • Louis Haußknecht
    Louis Haußknecht Member Posts: 3
    edited January 2020

    @Mark: Interesting, I tested two wallets from our DBA and anther random one from the internet and all had the last byte 36. Strange..

    @Alex: Yes it's from version 2.19.60

  • Alex Keh-Oracle
    Alex Keh-Oracle Posts: 2,751 Employee
    edited January 2020

    It's interesting that three other wallets you tried had the "36" magic number. Where did you get the "37" wallet from? How was its generation different from these other three?

  • Louis Haußknecht
    Louis Haußknecht Member Posts: 3
    edited January 2020

    Oh man my bad. That was a typo. All wallets I tried had the "37" not "36".

  • user715761-Oracle
    user715761-Oracle Member Posts: 2
    edited January 2020

    Mark is correct. Without getting into the technically details, the 54/0x36 is much more common, and the 55/0X37 is associated w/ "optional" functionality.

    Also, ODP (both M and C) originally only had support for 54/0x36, but the support for 55/0x37 should be in 19.6.

  • Alex Keh-Oracle
    Alex Keh-Oracle Posts: 2,751 Employee
    edited January 2020

    Louis,

    Please check the ODP.NET Core version you are using again. In ODP.NET 19.6, the exception message will include a magic version. Older ODP.NET Core releases did not have nor were they able to support "37" wallets.

  • user715761-Oracle
    user715761-Oracle Member Posts: 2
    edited January 2020

    What Alex is saying is that the NEW code will show a different msg for a failure on the last byte of the magic. Thus the fact that you are receiving "TCPS: Invalid SSL Wallet (Magic)" (and the fact that you are failing on the magic) most likely means you are running the old code before the fix.

Sign In or Register to comment.