Securing MongoDB Using Let's Encrypt Certificate
zohaib.me
zohaib.me
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.
Doing it this way means we don't rely on the LE servers being up all the time, since we renew at the 1 month remaining point. If they're down for a day two, they'll just renew after they're back up. It also means our loadbalancers don't need access to the DNS system to handle the DNS-01 challenge required for wildcard certs :)
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
Then in the MongoDB config: sslMode = requireSSL
sslPEMKeyFile = /etc/ssl/mongodb.pem
The only gotcha is in your clients you may have to set a flag: "allow_self_signed" => true"Allow self-signed" is literally just "trust anyone, no matter what". The entire point of certificates is to delegate trust. The verifying party (a client, in this case) trusts an authority, and the authority trusts and vouches for the authenticatee. "Allow self-signed" allows absolutely anyone to be the "authority". Instead, you should be telling to verifying party exactly who is the authority, which, in this case, could be the certificate you created.
at the network: ipsec, openvpn, wireguard
tcp proxy before the application: stunnel, spiped
mongo protocol is http right?
http tls proxy: haproxy, nginx, etc
Tincd was installed on each virtual server and allowed a secure and unified way for communication.
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.
The game's already over, you just don't know it yet