- 3,733,518 Users
- 2,246,779 Discussions
- 7,856,750 Comments
- 17.8K All Categories
- 3.3K Industry Applications
- 3.2K Intelligent Advisor
- 57 Insurance
- 533.2K On-Premises Infrastructure
- 137.3K Analytics Software
- 38.5K Application Development Software
- 5.1K Cloud Platform
- 109K Database Software
- 17.5K Enterprise Manager
- 8.8K Hardware
- 70.7K Infrastructure Software
- 105K Integration
- 41.5K Security Software
An empty wallet works?!? - Question on the intricacies of SSL Trusted Site Certs (client side)
I've had a curious experience, installing a new trusted certificate into my wallet for a remote Oracle server, to replace an expiring certificate. (I'm up and running, but trying to gain a deeper understanding of the intricacies of the wallet process.)
The remote/offsite database uses SSL for encryption. They use a well known certificate authority for the SSL certificate they install to their Oracle databases for encryption. And they provide a trusted certificate for us (users) to install on the client side. So far, so good.
Except, during testing, I came across this unusual event, leading to my question: (my test environment btw, is more than one computer, and creating new/different wallets, altering SQLNET.ORA and/or TNSNAMES on the fly, to test many different scenarios. Also as a sanity check, I also test things out on other machines too, since (see below) there were times where things happened that I didn't understand.
- The biggest question of all (keep in mind I have several different setup scenarios I've tested with.) - One of my tests was trying to connect with just an empty wallet. And the connection worked. Similarly, a few clients that we intentionally didn't update continued to work after the certificate expiration date.
- I'm assuming this is because the remote database in this case uses an SSL Certificate provided by a widely recognized Certificate Authority? (I've tried an alternate setup without a wallet at all, and that fails, as expected. The surprise in my case, is that it all worked just by having a wallet). I also checked and double checked this, including on a new wallet install/new virtual machine because I was thinking I was crazy too. But I definitely did not have the wallet/certificate installed somewhere else that I had forgotten about.
- Does question 1 mean we really don't need to install trusted site certificates, just have a wallet (at least in the case of SSL certs administered by a trusted certificate authority? Separately, we noticed that those among us using SQL Developer specifically with a JDBC connect string didn't even need a wallet, but I chalked that up to JDBC. The rest of us use things like Oracle native client, ODBC, and .net, which definitely don't proceed if there's not an Oracle wallet involved.
- I know someone will ask, yes, there's a site to site VPN, but the SSL was for encryption, and other than SQL Developer/JDBC, nothing connects without a wallet.
- Before I tried the empty wallet test, my focus was on updating wallets ahead of the original certificate expiring. I noticed during that testing, that on the client side, either the old or new trusted cert worked fine, and during final testing, where the vendor installed only the new certificate, all our local clients still worked whether using the old/about to expire cert or the new. (At that point, I was theorizing that the certificate resolution was based on the CN (name) of the trusted certificates.
So my question in advance, is if anyone out there fully understands the intricacies of SSL, I'm really curious. I have to say I was surprised that things worked with an empty wallet. (FYI, I've also made sure that the vendor certificate wasn't installed to my Windows certificate store, as a possible alternate explanation. The certificate authority cert was, of course, it was one of the major CAs)
Thanks in advance!