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

[toomuchtodo]

You also don’t want sensitive internal infrastructure address data in certificate transparency logs (this also applies to AWS provided ACM certs).