
Securing MongoDB Using Let's Encrypt Certificate - zabi_rauf
https://zohaib.me/securing-mongodb-using-lets-encrypt/
======
precurse
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.

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.

~~~
zabi_rauf
Good point, I'll take a look at the creating an internal CA and generate own
certificate. The point of LE API servers down is pretty good and makes the use
of own CA more enticing. I suspect that will also break a lot of other
websites as well as the usage of LE grows overtime so I suppose critical
systems should avoid LE altogether.

~~~
precurse
LE certs can still be used in those cases. We use LE extensively for the
(somewhat critical) project I'm on. We centralize all certificate creation
from our deployment server(s), so that we just push the certs out when the
servers are built.

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 :)

------
nodesocket
Not sure I get the point of this. Seems way overly complicated. Why not just:

    
    
        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

~~~
pritambaral
That's worse than no TLS: it gives a false-sense of security while actually
securing nothing. All because of that "allow_self_signed".

"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.

------
getcrunk
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

~~~
zabi_rauf
Can you please elaborate more on what other ways are you referring to? This
particular way was used to communicate with the DB hosted on a different cloud
provider from where it was being used. I would like to learn about different
ways to accomplish the same securely. This was one of the ways I could find.

~~~
justinsaccount
lots of ways..

at the network: ipsec, openvpn, wireguard

tcp proxy before the application: stunnel, spiped

mongo protocol is http right?

http tls proxy: haproxy, nginx, etc

~~~
yjftsjthsd-h
I would expect native SSL to have better perf than at least some of those.
Maybe. Probably not ipsec and wireguard.

------
drinchev
In my last project, we had a VPN ( tinc ) between the mongo cluster and the
micro services.

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.

------
gaius
_Making MongoDB publicly accessible_

The game's already over, you just don't know it yet

