[SERVER-10962] Add support for online (SSL/X.509) server cert. replacement Created: 30/Sep/13  Updated: 06/Dec/22  Resolved: 20/Aug/20

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: None
Fix Version/s: 4.7.0

Type: New Feature Priority: Minor - P4
Reporter: Scott Hernandez (Inactive) Assignee: Backlog - Security Team
Resolution: Done Votes: 12
Labels: former-quick-wins
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-18008 Ability to dyamically reload SSL cert... Closed
is duplicated by SERVER-37494 RFE: Ability to change TLS/SSL certif... Closed
Related
Assigned Teams:
Server Security
Backwards Compatibility: Fully Compatible
Participants:
Case:

 Description   

Users will want to upgrade server certs without downtime, or restarts.



 Comments   
Comment by Kelsey Schubert [ 19/Mar/21 ]

Hey ian.springer@gmail.com,

It'll still be in our next our next LTS release (e.g. what previously might have been referred to as 4.6.0), please take a look at https://www.mongodb.com/blog/post/new-quarterly-releases-starting-with-mongodb-5-0 for more details.

Best,
Kelsey

Comment by Ian Springer [ 19/Mar/21 ]

The fix version on SERVER-49116 is 4.7.0. Did it get pushed from 4.6 to 4.8?

Comment by Mark Benvenuto [ 20/Aug/20 ]

We added support for a new command rotateCertificates to rotate certificates on the server side as part of SERVER-49116. It will ship in 4.5.1.

Comment by Vaibhaw Pandey [ 12/Oct/18 ]

Hello matt.lord,

Thank you for your thought out response!

You are right in pointing out that no other databases supports online cert replacement and it is a rather hairy thing to get right. I just wanted to understand how you folks view this issue and intend to solve it.

A rolling sort of a solution sounds like a fair one, much like the current way we move from non-SSL to completely SSL deployments. Just that this operation will need to run frequently. Since it wouldn't be possible to offer the new cert to just one node and let it percolate it to others - what will be desirable is a well documented process to performing such a certificate replacement.

Again, I just wanted to understand if this usecase was on your radar and how were you approaching it. Thanks for explaining that Matt.

Comment by Matt Lord (Inactive) [ 09/Oct/18 ]

Hi vaibhaw

That is actually one of the use cases that we have in mind. We have several related projects on our plan now (disclaimer that we cannot make forward looking projections on dates or versions for future work):

  1. Drastically improve the election handoff time when doing a replSetStepDown (this work is already in 4.1.3+)
  2. Support TLS cert replacement via a cluster rolling restart (rather than having to take down the entire cluster and re-bootstrap)
  3. Work with the goal of incurring no downtime from planned maintenance 

So you would then be able to replace the cert on each of the Secondaries one at a time via a restart of the process. And then finally replace it on the Primary via a replSetStepDown and restart of the process. All w/o incurring application downtime (although there would be some connection errors, but that would happen either way–see below). 

To the best of my knowledge no other databases support online cert replacement, and this is because to do that would require you to drain all open connections while blocking new ones, once connection count is at 0, then create a new security context with the new cert, and finally allow new connections again. So in the end it's often worse than simply restarting the process–all while requiring a lot of engineering effort that could instead be put towards things that otherwise cannot be solved. And a side benefit of a process restart is that you also have the opportunity to periodically install the latest patch release (e.g. 4.0.3) which is important in and of itself. 

If you have any additional input or ideas though, I'd love to discuss it.

Thanks!

Matt

Comment by Vaibhaw Pandey [ 06/Oct/18 ]

There is now an somewhat important (IMO) usecase - supporting Let's Encrypt (LE) signed certificates with MongoDB. LE is fast becoming the simplest (and cheapest) way to get proper signed certificates. However their short validity (90 days, see https://letsencrypt.org/2015/11/09/why-90-days.html) is serious issue in adopting them for database servers.

Can you please consider targeting it to a release?

Comment by Balazs Varga [ 20/Oct/17 ]

Hello Support team,
Any news related to this problem ?
Thanks

Generated at Thu Feb 08 03:24:30 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.