MongoDB and Compass won't TLS with Custom CA certs made with OpenSSL

This is a connected to previous question I asked:

Compass and MongoDB VPS instance won't establish TLS connection

where Wernfried Domscheit provided the solution, which raised further question.

Just like Wernfried Domscheit pointed out, if you know URL of MongoDB instance and you happen to know that LetsEncrypt certs are used for TLS, then nothing is stopping you from generating your own LetsEncrypt certs for this URL and connecting to MongoDB. The established fact is MongoDB only verifying the CA and validity of the cert and isn't verifying the contents of the cert provided by the client.

The non-obvious solution found that made Compass talk to MongoDB instance on VPS was to use LetsEncrypt certs generated by Certbot. The 2 files are used:

certKey.pem, which has host certificate and privkey;
intermRoot.pem, which has chain.pem and rootCA certitifates, wherein the RooCA is downloaded from LetsEncrypt website.

Those are attached to mongodb.conf end. Compass is happy to use certKey only. Connection establishes just fine. Apparently, not happy days, because it's fake TLS security - like explained above.

The truly secure solution would be make own, custom CA, which nobody can dodge, that MongoDB is actually verifying.

With OpenSSL I generated the custom CA, the host cert and the intermediate cert and they do pass verification against rootCA. But MongoDB isn't happy:

{"t":{"$date":"2024-12-07T22:13:18.040+00:00"},"s":"E",  "c":"NETWORK",  "id":23256,   "ctx":"conn56","msg":"SSL peer certificate validation failed","attr":{"error":"SSL peer certificate validation failed: unsuitable certificate purpose"}}

Any ideas on how to fix this are appreciated.

Edit:

RootCA cert:

Intermediate cert:

Host cert:

Solution

I assume the wrong intermediate certificate is just a mistake from your side.

So, focus on your error. unsuitable certificate purpose indicates that you have wrong certificate purpose:

> openssl x509 -in giftbutton.com.crt -noout -ext extendedKeyUsage,keyUsage,nsComment
Netscape Comment:
    My First Certificate
X509v3 Key Usage:
    Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
    TLS Web Server Authentication

I guess, you try to use this certificate at Compass. This is a server certificate, however at Compass you need to create a client certificate, i.e. you need to set TLS Web Client Authentication.

Why did you set Non Repudiation? This property and the Netscape extensions are not needed.

Regarding intermediate certificates: On public web servers you have usually a Root-CA and an Intermediate-CA. In general there is no technical reason for it, it is more driven by organization challenges. Imagine the Let's Encrypt Root-CA would be compromised - there are billions of devices and browsers who trust in this Root-CA. It would be really a huge effort to remove and update this Root-CA on billions of devices. That's the reason for Intermediate-CA. If an Intermediate-CA gets compromised (maybe by an vindictive and angry service desk employee) then it is rather simple to revoke this Intermediate-CA in the Root-CA CRL.

Most likely in Let's Encrypt, only the CEO and CTO may have access to the private key of their Root-CA's in order to keep them protected.

In your small or private environment there is no technical reason to create any Intermediate-CA. In case your Root-CA gets compromised then you can simply replace the CA and the end-entity certificates.