Forum Stats

  • 3,875,480 Users
  • 2,266,928 Discussions
  • 7,912,227 Comments

Discussions

TLS Connection Looking For Wallet in Default Location despite using MY_WALLET_DIRECTORY

I'm finding hints here and there that this is a known issue, but just wanted to ask here directly to confirm. I have a typical client-server TLS connection. We have multiple database instances server-side, each with their own client-side apps, and are transitioning all of them to communicating over TLS1.2. We would like to avoid making unique sqlnet.ora files for all of them, so are opting to use each client's tnsnames.ora file to point to where the wallet is on the server-side. That is my understanding of how the MY_WALLET_DIRECTORY is supposed to work.

Client side tnsnames.ora uses the MY_WALLET_DIRECTORY parameter as follows:

(SECURITY=

(SSL_SERVER_CERT_DN=[cert])

(MY_WALLET_CONNECTION=[location of server-side wallet])

)

This results in ORA-28759: failure to open file. Looking at the trace, it is clear that it is looking for the server-side wallet in the default Unix area:

[29-AUG-2022 11:00:59:766] snzdfo_open_file: Opening file /etc/ORACLE/WALLETS/oracle/ewallet.p12 with READ ONLY permissions

[29-AUG-2022 11:00:59:767] snzdfo_open_file: File Open/Close error

[29-AUG-2022 11:00:59:767] nzdfo_open: File Open/Close error

[29-AUG-2022 11:00:59:768] nziropen: rio open failed with error 28759


This error is eliminated if the WALLET_LOCATION parameter is set in the server-side sqlnet.ora file, but that gets us back to the problem of then having to create unique sqlnet.ora directories for each instance. Hopefully this is just something I'm not understanding. Thanks for any assistance you can provide.

Tagged:

Answers

  • Solomon Yakobson
    Solomon Yakobson Member Posts: 19,951 Red Diamond

    It is my_wallet_directory, not MY_WALLET_CONNECTION. Is it just a typo?

    SY.

  • Solomon Yakobson
    Solomon Yakobson Member Posts: 19,951 Red Diamond
    edited Aug 29, 2022 6:00PM

    Anyway, post server side wallet ownership. OS user must have read permission on wallet files and every directory in directory path to the wallet.

    SY.

  • Solomon Yakobson
    Solomon Yakobson Member Posts: 19,951 Red Diamond

    Actually, I missed "point to where the wallet is on the server-side". Fortunately this doesn't work this way otherwise it would create huge security gap since it would allow any OS user on client machine to read database side wallet files. Wallet files must reside on client side. And I am not sure you even need my_wallet_directory which is used when SAME client has multiple wallets.

    SY.

    Jefferson Bauersfeld
  • Jefferson Bauersfeld
    Jefferson Bauersfeld Member Posts: 4 Red Ribbon
    edited Aug 29, 2022 7:05PM

    Ah so this was a mix of an unmissed typo and me not understanding how MY_WALLET_DIRECTORY works. Fixed the typo, then proceeded to receive an "ORA-28759 failure to open file" error, which jives with what you said that that is referencing the wallet on the client-side, not the server side.

    Given that, am I to understand that there is no way around creating multiple sqlnet.ora directories on the server side for multiple Oracle Instances using a shared Oracle Home? In other words, there is no way to utilize a shared sqlnet.ora file when utilizing Oracle wallets for multiple instances?

    I guess on a side question, my understanding is that technically, and for security reasons, you cannot utilize a single Oracle wallet for multiple instances, correct?

  • Solomon Yakobson
    Solomon Yakobson Member Posts: 19,951 Red Diamond
    edited Aug 29, 2022 7:53PM

    @Jefferson Bauersfeld: I guess on a side question, my understanding is that technically, and for security reasons, you cannot utilize a single Oracle wallet for multiple instances, correct?

    Incorrect. Wallet/instance/application are in general "parallel" to each other. It is who is allowed to use (read) the wallet what matters. For example, you can have

    WALLET_LOCATION =
       (SOURCE =
         (METHOD = FILE)
         (METHOD_DATA =
           (DIRECTORY = /wallets)
         )
       )
    

    make sure all desired client OS users have read on /wallets and create wallet there (make sure all desired client OS users have read on wallet files). In this case every OS user who has read on /wallets can use that wallet. Or you can have:

    WALLET_LOCATION =
       (SOURCE =
         (METHOD = FILE)
         (METHOD_DATA =
           (DIRECTORY = /wallets/$wallet_owner)
         )
       )
    

    make sure environment variable $wallet_owner is set in each user .profile (or set in default profile), make sure all desired client OS users have read on /wallets but only corresponding OS user has read on /wallets/$oracle_wallet directory. Then create a separate wallet in each /wallets/$oracle_wallet directory (make sure only corresponding OS user has read on wallet files). Now OS user can use their wallet only since they have no read on other wallets.

    SY.

    Jefferson Bauersfeld
  • Jefferson Bauersfeld
    Jefferson Bauersfeld Member Posts: 4 Red Ribbon

    Oh ok, so the wallet security in that case is pushed down to the OS level.

    Now I'm getting kinda confused in setting up a shared wallet. In trying out a few things, I removed the user certificate for the host I successfully set up and added a user certificate for another host. I expected this would cause the app to not be able to connect, but it still can. Although the two user certs have the same CA chain, I'm guessing that the client isn't authenticating that the user cert the server is presenting matches the server.

    I thought that kind of server authentication was how 1-way TLS works. I intentionally have Client Authentication for 2-way TLS turned off until I lock down 1-way TLS, but could I have somehow turned off server authentication as well? Or am I just missing something?

  • Jefferson Bauersfeld
    Jefferson Bauersfeld Member Posts: 4 Red Ribbon

    Nevermind. Answered my own question on that one. I missed one small explanation in the documentation that mentioned needing to set SSL_SERVER_DN_MATCH=ON in the client sqlnet.ora. Odd that they mentioned it, but then didn't include it as a discreet step alongside adding the SSL_SERVER_CERT_DN parameter in the tnsnames.ora file.

    Though this is now presenting a different issue that's definitely pushing the limits of what I know about Oracle Wallet. The TLS connection works fine if the server's user cert is the only cert in the wallet or is listed first with `orapki wallet display`. However, if another server's user cert is listed first, the connection errors out with this output in the sqlnet.log file:

     Tns error struct:

      ns main err code: 12560

      TNS-12560: TNS:protocol adapter error

      ns secondary err code: 0

      nt main err code: 540

      TNS-00540: SSL protocol adapter failure

      Oracle error 1: 43081

    ORA-43081: Message 43081 not found; product=RDBMS; facility=ORA

    I would assume the client would try to iterate across all of the user certs in the wallet until it found the one listed in its tnsnames.ora file, but maybe not?