[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:
Related
is related to DOCS-12092 Improve KMIP CN/SAN Documentation Closed
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:

2018-09-17T17:36:50.040+0800 E STORAGE  [initandlisten] Unable to retrieve key .system, error: socket exception [CONNECT_ERROR] for The server certificate does not match the host name. Hostname: [<hostname>] does not match SAN(s): akm

 

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:

The mongo shell verifies that the hostname (specified in --host option or the connection string) matches the SAN (or, if SAN is not present, the CN) in the certificate presented by the mongod or mongos. If SAN is present, mongo does not match against the CN. If the hostname does not match the SAN (or CN), the mongoshell will fail to connect.

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.
I'm hoping you can share your public certificate and confirm what command line was being used on the v3.2 instance.

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 ?
Also, could you provide the certificate?  No need for the private key, but I'd like to confirm the public contents.

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

Generated at Thu Feb 08 04:45:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.