We have existing wildcard cert from ssls named *.domainname.com. Is it possible to use this .cert for my MongoDB TLS connections?
We want to do this for us to have a uniformity in maintenance timeframe for other platforms that are using the same cert. Unlike when using LetsEncrypt (although this approach can be automated) that have 3months expiry on certificates
Yes, as long as the hostnames match the wildcard.
I’ve tried it but when my client will connect with the tls=true option, error is
unable to verify the first certificate
I did combine the .cert and the .key into a .pem file.
Then on my mongod.conf
certificateKeyFile=/path/to/file.pem
That is unusual. Possibly the client system and/or runtime needs to update the ca-certificates bundle.
How can I do that? When I download the cert from ssls.com, I got 3 files (domainname.com.crt, domainname.com.key, domainname.com.ca-bundle)
Depends on the client, it could rely on OS trust stores or it own mechanism, drivers will have options to use a specific CAFile too.
I would expect most reputable TLS to be verifiable by an up to date system using well known trust roots.
What OS, MongoDB Version, Client are being used?
If needed the omainname.com.ca-bundle would be the one to specify as the CAFile if specifying it with the client.
My server is running on Ubuntu 22.04, MongoDB 6.0
Have you tried recreating the .pem file with the .key and .crt in opposite order?
you mean running this one?
cat file.key file.crt > file.pem
MongoDB was not able to start when I do this.
That’s odd. Because I’m running MongoDB just like that, with a combined file key+cert.
One suspects your files are in the wrong format.
What about the client?
The client is the one performing the verification.
As mentioned already, you have the domainname.com.ca-bundle so even if ‘natively’ updating ca-certificates does not work on the client this file can be used explicitly.