Neat concept, but there's no cost to running your own internal CA and having MongoDB trust that instead. Since you're already likely going to be running automated tools to deploy MongoDB (I assume), you can generate your own certificate/key pair then. This is how we do it where I work.<p>One of the big issues with generating the Let's Encrypt cert on demand is that if the LE API servers are ever down, you won't be able to create a cert.
Not sure I get the point of this. Seems way overly complicated. Why not just:<p><pre><code> cd /etc/ssl
### 10 year expiration
openssl req -newkey rsa:2048 -new -x509 -days 3650 -nodes -out mongodb-cert.crt -keyout mongodb-cert.key
cat mongodb-cert.key mongodb-cert.crt > mongodb.pem
</code></pre>
Then in the MongoDB config:<p><pre><code> sslMode = requireSSL
sslPEMKeyFile = /etc/ssl/mongodb.pem
</code></pre>
The only gotcha is in your clients you may have to set a flag:<p><pre><code> "allow_self_signed" => true</code></pre>
What's the benefit of doing this that outweighs the downside of restarts? If your DB has to communicate directly with something over wan there are other options
In my last project, we had a VPN ( tinc ) between the mongo cluster and the micro services.<p>Tincd was installed on each virtual server and allowed a secure and unified way for communication.<p>For example Redis, Mongo, Logstash, etc... all have their own way of encrypting the connection, but once running them in a VPN, you can leave them unencrypted.