[SERVER-36460] TLS certificate "purpose" requirements changed Created: 06/Aug/18  Updated: 27/Oct/23  Resolved: 06/Aug/18

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Mark Benvenuto
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File mongo_c_driver_asan_ubuntu_test_asan_latest_sharded_auth_openssl_patch_ea29177af4d347616b2213016dac59c59e2b0eb7_5b66da682fbabe1abc9a5d6b_18_08_05_11_07_21-0-mongodb-logs.tar.gz    
Issue Links:
Problem/Incident
causes CDRIVER-2783 test-valgrind-latest-sharded-auth-ope... Closed
Operating System: ALL
Participants:

 Description   

Starting in the last week or two, the C Driver's mongo orchestration config has been unable to started a sharded cluster of replica sets with TLS enabled. Shard servers now seem to reject connections from other shard servers. They log:

2018-08-01T22:36:37.579+0000 I NETWORK [listener] connection accepted from 127.0.0.1:56037 #12 (3 connections now open)
2018-08-01T22:36:37.584+0000 W NETWORK [conn12] SSL peer certificate validation failed: unsupported certificate purpose
2018-08-01T22:36:37.584+0000 I NETWORK [conn12] end connection 127.0.0.1:56037 (2 connections now open)



 Comments   
Comment by A. Jesse Jiryu Davis [ 06/Aug/18 ]

Thanks Mark! No, none of our configurations pass --sslClusterFile, only --sslPEMKeyFile.

I just realized what's really happening: until a change to our Evergreen config.yml on July 19, the C Driver had no variants executing our test task for a sharded cluster with auth and OpenSSL. We had messed up our tag selectors such that the test task was defined but never selected to run in any variant. I thought this was a server change, but our test config has been wrong for a long time or forever.

Comment by Mark Benvenuto [ 06/Aug/18 ]

This is a bug in the certificate. The server has not changed any code on its side.

I validated that using the server.pem cannot be used as a client certificate. I used the following server and ca file.
https://github.com/mongodb/mongo-c-driver/blob/2f3878954915baf0c07b2e5d8a6e81964ca76e6c/src/libmongoc/tests/x509gen/server.pem
https://github.com/mongodb/mongo-c-driver/blob/2f3878954915baf0c07b2e5d8a6e81964ca76e6c/src/libmongoc/tests/x509gen/ca.pem

I used the shell to connect with this certificate.
./mongo --ssl --sslPEMKeyFile=server.pem --sslCAFile=ca.pem

and the server logged the following error as expected:

2018-08-06T14:07:24.845-0400 E NETWORK  [conn1] SSL peer certificate validation failed: unsupported certificate purpose
2

I validated this against 3.6.5 and 4.0.0.

Did mongo-orchestration ever use --sslClusterFile? When the mongos/mongod is passed only --sslPEMKeyFile it uses that certificate for inbound and outbound communication. If it is passed --sslClusterFile, it will use --sslPEMKeyFile for inbound connections and use --sslClusterFile for making outbound connections.

Comment by A. Jesse Jiryu Davis [ 06/Aug/18 ]

That's right, v4.1.1-224-gecb0b6c on Ubuntu 14.04.

Comment by Mark Benvenuto [ 06/Aug/18 ]

Just want to confirm that the test environment is with MongoD 4.1 with OpenSSL running on Ubuntu 14.04?

Generated at Thu Feb 08 04:43:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.