[GODRIVER-643] Verify server certificates using CAs in system certificate stores Created: 19/Nov/18  Updated: 27/Oct/23  Resolved: 15/May/19

Status: Closed
Project: Go Driver
Component/s: Connections
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: David Golden Assignee: David Golden
Resolution: Gone away Votes: 0
Labels: devexp-product
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by TOOLS-1833 Migrate tools (excluding mongoreplay)... Closed
Related
is related to GODRIVER-351 Investigate Darwin root certs Go bug ... Closed

 Description   

Revised:
The tools need to support CAs in system certificate stores. Specifically, the following Evergreen tasks that passed using OpenSSL-based tools need to pass using the Go driver:

Go 1.12 (and 1.11.6) claim to have fixed the Mac issue, so when that toolchain is available we can test against it.

For Windows, it doesn't look like Go has fixed it upstream, so we need to find an alternate way of getting the system CAs. That could be something like the go-openssl wrapper system_certs.c code, or, perhaps preferably, something using Go's syscall library or sys/x/windows.

Original

The mongodb tools currently have the ability on Windows and Mac to authenticate a server against a CA installed in the system certificate store. This is achieved via the go-openssl wrapper which loads Windows/Mac system CAs into an openssl X509 store. See this code called via this code.

The Go driver needs to implement some equivalent functionality or the tools can't use the Go driver for TLS support.

For Mac, there seems to be support already for system CAs, but with some outstanding bugs, e.g. go#24652.

For Windows, this might be addressed in Go 1.12 – see go#16736 or we might need to do the equivalent ourselves if the patch doesn't get merged in time.

Another option for Windows might be to implement schannels support. I've seen a package claiming support, alexbrainman/sspi, but have no idea how functional/usable it is.



 Comments   
Comment by David Golden [ 15/May/19 ]

Testing with custom macos hosts with CA installed in the System keychain passed tools tests. Closing this ticket as "gone away".

Comment by David Golden [ 02/May/19 ]

I believe this issue can be resolved if BUILD-8386 gets the tools passing their tests.

tl;dr: Go 1.12 provides support, but CA certificates needed to be installed differently on Evergreen to be recognized.

Windows:

  • System CA tests for the MongoDB server note that with SChannel (i.e. Windows native crypto), CAs must be installed in the Root store, not a user store. When MongoDB tools tests make that same change, tests pass, indicating that the driver is able to validate the server certificate via the installed CA.

Mac:

  • Tests using mkcert based certificates proved that Go 1.12 will validate a server certificate from a CA in the System keychain.
  • Additional tests show that a CA in the user's login keychain can also work, but only if installed with the security CLI tool without the "-d" flag. With that flag, while the certificates appear identical in the Keychain Access app, some internal, invisible trust setting prevents it from being available for validating the server cert.
  • Chef recipes for Mac Evergreen images use the "-d" flag for the login keychain; certificates are not installed during tests so rely on the one installed during provisioning.
  • Most internet examples of installing a CA to a keychain use the System keychain (which does require the "-d" flag) – just like mkcert – so our proposed remedy in BUILD-8386 is to install the CA cert into the System keychain.
Comment by David Golden [ 19/Nov/18 ]

SetDialer is a possibility. We'd prefer to avoid it as it means we need to keep shipping the openssl DLL with Windows builds. Part of the goal in switching to the Go driver is to stop needing openssl and to stop having to maintain connection logic outside the driver.

Comment by Jeffrey Yemin [ 19/Nov/18 ]

An application can already configure a Connection to use the openssl wrapper via func (c *ClientOptions) SetDialer(d ContextDialer) *ClientOptions. This is essentially what mongosqld is doing, for example. Is there a reason that's not a workable solution?

Generated at Thu Feb 08 08:34:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.