[SERVER-19174] net.ssl.mode allowSSLIssuerDN mode Created: 28/Jun/15 Updated: 14/Apr/16 Resolved: 07/Jul/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Paul Gilligan | Assignee: | Andreas Nilsson |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Security 6 07/17/15 |
| Participants: |
| Description |
|
In cloud based environments with an internal CA a situation arises whereby a mongo cluster at release A is already enrolled with a CA also from release A but during release B the CA might have been rebuilt and thus the cluster can't be formed with strict net.ssl.mode settings. It depends how the clustering is implemented and the timing of each mongo node deployments but such a situation has arisen. Rather than lower the SSL authentication could we propose an additional net.ssl.mode for matching issuer DN values rather than failing due to changes in issuer certificate version numbers ? net.ssl.mode=allowSSLIssuerDN |
| Comments |
| Comment by Andreas Nilsson [ 07/Jul/15 ] |
|
Hi pauldavidgilligan, did the work around work for you? I'm going to close this ticket as "Works as Designed" unless you object. |
| Comment by Paul Gilligan [ 01/Jul/15 ] |
|
That is not a bad idea actually, normally we only have one CA (EJBCA) in this case which is ephemeral, can be replaced by the same identical instance except of cause now the keys and hence certificate signatures had changed. Because it is all dynamic we can't really publish the CA certs each time they are created, into for example some YAML files, would be too complex. But I like the idea let me see... If we can try this out. |
| Comment by Andreas Nilsson [ 01/Jul/15 ] |
|
It's possible to use multiple concurrent CA certs by putting them all in the CA certificate file. Would this be an option for you? |
| Comment by Paul Gilligan [ 01/Jul/15 ] |
|
Yes there is an edge case whereby part of the cluster is on one CA cert and the other part on another due to release pipeline. The issuer DN is the same but the newly provisioned CA has a different serial ID which is expected and hence the authentication fails. We prefer not to relax the authentication but would be nice to have a sort of match issuer DN option. Thank you for getting back to quick. |
| Comment by Andreas Nilsson [ 01/Jul/15 ] |
|
Hey, thanks for your note. To clarify, are you looking to change the CA and upgrade the cluster at the same time? |