[SERVER-54752] Version 4.4.4 fails to validate existing certificateKeyFile, refuses to start Created: 24/Feb/21 Updated: 12/Jul/21 Resolved: 12/Jul/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.4.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Vlad Lasky | Assignee: | Varun Ravichandran |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Sprint: | Security 2021-03-22, Security 2021-04-05, Security 2021-04-19, Security 2021-05-03, Security 2021-05-17, Security 2021-05-31, Security 2021-06-14, Security 2021-06-28, Security 2021-07-12 |
| Participants: |
| Description |
|
Hello, I am running MongoDB under CentOS 7, installed from the official mongodb-org-4.4 yum repo. I ran yum today and it updated mongodb-org.x86_64 0:4.4.3-1.el7 to mongodb-org.x86_64 0:4.4.4-1.el7. Mongod then failed to restart. It gave me the following startup error, indicating a problem with the existing certificateKeyFile that I know for certain is valid. Downgrading MongoDB back to mongodb-org.x86_64 0:4.4.3-1.el7 got things working again. Here are the error messages from the log: {"t":\{"$date":"2021-02-24T22:03:15.822+11:00"},"s":"I", "c":"CONTROL", "id":20698, "ctx":"main","msg":"***** SERVER RESTARTED *****"} {"t":\{"$date":"2021-02-24T22:03:15.825+11:00"},"s":"E", "c":"NETWORK", "id":23252, "ctx":"main","msg":"Cannot use PEM key file","attr":{"keyFile":"/etc/mongod.pem","error":"error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch"}} {"t":\{"$date":"2021-02-24T22:03:15.826+11:00"},"s":"F", "c":"CONTROL", "id":20574, "ctx":"main","msg":"Error during global initialization","attr":{"error": {"code":140,"codeName":"InvalidSSLConfiguration","errmsg":"Can not set up PEM key file."}}} |
| Comments |
| Comment by Varun Ravichandran [ 12/Jul/21 ] | ||||||||||||||||||||||||||||||||||||||||||
|
I'm closing this ticket as we were unable to reproduce this issue with the information the reporter provided. vlasky@remotelaboratory.com, if the steps outlined in the previous comments still did not resolve your issue, then please reopen the ticket and provide verbose logs and the subject names of the certificates in the chain in your tls.certificateKeyFile. Thanks! | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Varun Ravichandran [ 29/Jun/21 ] | ||||||||||||||||||||||||||||||||||||||||||
|
Hi vlasky@remotelaboratory.com, I'm just following up to see whether you had a chance to try those steps that I outlined above. I'd greatly appreciate it if you could respond with an update! | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Varun Ravichandran [ 21/May/21 ] | ||||||||||||||||||||||||||||||||||||||||||
|
Hi vlasky@remotelaboratory.com , 2. Your configuration file, interestingly enough, does not include the security.keyfile option. Starting in 4.4.4, users must provide a path to a keyfile using this option if they have authorization enabled on a replica set (which it appears you do). If you don’t already have that option set, you should create a keyfile and populate that field. See documentation about internal auth here and see more information about the change itself from the ticket. 3. If setting that option and upgrading to 4.4.6 still does not resolve your issue, then please enable verbose logging in your config file and provide a full copy of verbose logs so I can take a deeper dive into those. I would also appreciate it if you could provide the subject names of the certificates that appear in tls.certificateKeyFile , in the order they appear. Feel free to redact the subject name of the leaf (your server’s) certificate if you wish. I hope these steps are useful, and apologies again for the delay! | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Vlad Lasky [ 31/Mar/21 ] | ||||||||||||||||||||||||||||||||||||||||||
|
Hello Varun, 1. These were the configuration options in /etc/mongod.conf:
2. It did not crash, so there was no core dump. 3. I'd prefer not to post the server's identifying details on a public forum. I confirm that I tested two different certificates including one generated by the Let's Encrypt cerbot utility. Both certificates worked in version 4.4.3 under my CentOS 7 environment., but not in version 4.4.4. | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Varun Ravichandran [ 26/Mar/21 ] | ||||||||||||||||||||||||||||||||||||||||||
|
Hi vlasky@remotelaboratory.com , | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Varun Ravichandran [ 10/Mar/21 ] | ||||||||||||||||||||||||||||||||||||||||||
|
Hi vlasky@remotelaboratory.com , Thank you for filing this ticket! I am taking a look into this, but would like some more information. Would you mind providing the following information?
Thank you! |