[SERVER-37296] Did KMIP CN requirement change to SAN? Created: 24/Sep/18 Updated: 27/Dec/18 Resolved: 27/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 3.6.6 |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | Nicholas Bayle | Assignee: | Sara Golemon |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Security 2018-10-08 | ||||||||
| Participants: | |||||||||
| Description |
|
Hello, we're working with a customer trying to close a mongodb enterprise sale. They are connecting to our key management server via KMIP.
Previously (v 3.2), the CN had to exactly match the KMIP hostname specified in the mongo configuration. Now, the error is as follows:
Did the requirement change that the hostname must now be in the subject alternative name? If so when did it change? And can this information be documented in the KMIP docs?
If the requirement did not change and the CN already matches the hostname, what would cause it to reject the SAN?
I'm supposed to tag Kenn White on this issue, but see no way to do that.
Thank you, Nick |
| Comments |
| Comment by Sara Golemon [ 28/Sep/18 ] |
|
nicholasbayle I'll reach out to DOCS to make a link, and I'll also see about the possibility of improving the error message. Sorry about the confusion. |
| Comment by Nicholas Bayle [ 27/Sep/18 ] |
|
Someone please delete the hostname from the original ticket. I didn't know all this was public until after I started the ticket. |
| Comment by Gregory McKeon (Inactive) [ 27/Sep/18 ] |
|
Closing this as "Done" with a linked ticket for the Docs team to improve our KMIP documentation. |
| Comment by Nicholas Bayle [ 27/Sep/18 ] |
|
I see, so the issue here was my understanding and documentation. Since my only interaction with MongoDB deployment is doing KMIP setup, I never ventured into the MongoDB client TLS documentation. After looking through the docs, this section from TLS:
Would be amazing to have in the KMIP section. Definitely spent a fair amount of time doing horrible workarounds to have matching CNs because I didn't realize there was SAN support (all errors had indicated CN in my case). Carry on.
|
| Comment by Sara Golemon [ 27/Sep/18 ] |
|
Sorry, I thought by tagging you in my prior comment you'd be able to see it. |
| Comment by Nicholas Bayle [ 27/Sep/18 ] |
|
Are you actually waiting for user input? Because I've heard nothing... |
| Comment by Sara Golemon [ 25/Sep/18 ] |
|
nicholasbayle Can you confirm that the command line you provided is also how they were starting v3.2 ? |
| Comment by Sara Golemon [ 25/Sep/18 ] |
|
Short answer: No. Looking at the CN/SAN matching logic in v3.2 and v3.6, they look essentially identical. Long answer: Both versions will, if any SAN is present, match ONLY against the SAN. It will try CN only if there is no SAN on the certificate. That error indicates the certificate has a SAN, therefore it should never have worked on 3.2 unless they were previously using --sslAllowInvalidCertificates or --sslAllowInvalidHostnames. ((Or if they were using a different certificate, obviously)) |