Uploaded image for project: 'Java Driver'
  1. Java Driver
  2. JAVA-3614

Connections now always require a two way trust with no way to disable?

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 3.10.0, 3.10.1, 3.10.2, 3.11.0, 3.11.1, 3.11.2, 3.12.0, 3.12.1
    • None

      I somewhat guess that this is a bug, or at least, a compatibility issue and/or missing feature.

      Using a java driver version between 3.10 and 3.12.1 (more generally, a version supporting MongoDB 4.0), i observe the following:

      If i try to connect to a MongoDB 3.6 instance by username and password, secured by ssl, it works as it did in previous versions of the java driver. More precisely, as seen from output with -Djavax.net.debug=all , the server sends his certificate to be validated by the driver. The client (so, my program using the java driver), does not even try to send its own certificate and MongoDB is happy with that.

      I also duplicated the same data, users, passwords and all into a newer MongoDB 4.0 instance for testing. If i try to connect with that, it fails. As seen with -Djavax.net.debug=all, it tries several times before exiting with

      Database connection verification failed: Timed out after 30000 ms while waiting to connect. Client view of cluster state is {type=UNKNOWN, servers=[{address=…, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketReadException: Prematurely reached end of stream}}] 

      Also, this MongoDB 4.0 instance several times logs the following:

       

      I NETWORK  [listener] connection accepted from 10.210.53.230:55362 #368 (1 connection now open)
      E NETWORK  [conn368] SSL peer certificate validation failed: (800B0109)A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
      E NETWORK  [conn368] SSL peer certificate validation failed: (800B0109)A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
      D -        [conn368] User Assertion: SSLHandshakeFailed: SSL peer certificate validation failed: (800B0109)A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. C:\data\mci\234eaebb96d72f5e8aef1024be83238a\src\src\mongo/transport/session_asio.h 621
      I NETWORK  [conn368] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: (800B0109)A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.. Ending connection from 10.210.53.230:55362 (connection id: 368)
      I NETWORK  [conn367] end connection 10.210.53.230:55361 (0 connections now open) 

      This is consistent with the output from -Djavax.net.debug=all where i can tell that, connecting to the newer MongoDB 4.0 instance, my program now also sends his certificate to MongoDB – which is not happy about that (as seen above). My program trusts the server, but this is not true for the other direction in general. It can be for some environments using my program, but does not have to be.

      Furthermore, I’m not sure if it would suffice to tell them to use a trusted certificate on both ends (if even feasible). Sometimes the MongoDB instance will run on a Windows Server with many trusted certification authorities. Since MongoDB 4.0 started to use Windows’ own mechanisms (schannel), every time the driver tries to connect, Windows complains about its limitation that it cannot present all of them to my “client” (Schannel Event 36885). Because of that, it seems possible that even a valid “client” certificate, would not be recognized as valid and this 2-way-trust would be doomed anyhow.

      Both points might be resolvable by administrators of some environments, but not for all of them.

      I did not find a way to disable this new two-way trust to let the administrator of those environments decide what to do. Did i overlook something or is such a possibility missing at the moment?

        1. MongoDB Instance configuration.7z
          4 kB
        2. example with workaround.7z
          205 kB
        3. example.7z
          179 kB

            Assignee:
            jeff.yemin@mongodb.com Jeffrey Yemin
            Reporter:
            josef.haertl@ldbv.bayern.de Josef Haertl
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: