-
Type: Task
-
Resolution: Unresolved
-
Priority: Minor - P4
-
None
-
Component/s: URI Options
-
None
-
Needed
Summary
Test that setting a tlsCertificateKeyFile to a .pem file with a certificate chain succeeds.
Scope
- Add a .pem file with a private key, certificate, and one intermediate certificate to drivers-evergreen-tools/.evergreen/x509gen.
- Test specifying the certificate as tlsCertificateKeyFile in the URI.
Motivation
GODRIVER-2263 identified a Go driver bug parsing a tlsCertificateKeyFile with a certificate chain.
This .pem file includes the following:
- Private Key
- Certificate 1 for Private Key
- Certificate 2 for Issuer of Certificate 1.
The Go driver was incorrectly attempting to associate Private Key with Certificate 2.
The expected order of certificates in a .pem file is described in: RFC 5246 7.4.2:
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it.
The motivation of this ticket is the possibility of other drivers having a similar bug. There is no certificate in drivers-evergreen-tools/.evergreen/x509gen to test.
This .pem file was created for the Go driver by concatenating test files from:
https://x509gen.corp.mongodb.com/#/cert/5ce5b21a42a0ef0008b11399
- Drivers-Testing-Client-Second-Level.key
- Drivers-Testing-Client-Second-Level.pem
- Drivers-Testing-Client-Intermediate.pem
Who is the affected end user?
Users enabling TLS and including intermediate certificates in the certificate chain.
How does this affect the end user?
Users may be confused or annoyed. If a driver has a bug similar to GODRIVER-2263, users may need to reorder sections in their client certificates.
Is this issue urgent?
No.
Is this ticket required by a downstream team?
No.
Is this ticket only for tests?
Yes.
- is related to
-
GODRIVER-2263 Not loading all certs in a PEM file
- Closed