Skip to content

PYTHON-5040 Regenerate test TLS certificates with Authority Key Identifier#2846

Draft
blink1073 wants to merge 7 commits into
mongodb:masterfrom
blink1073:PYTHON-5040
Draft

PYTHON-5040 Regenerate test TLS certificates with Authority Key Identifier#2846
blink1073 wants to merge 7 commits into
mongodb:masterfrom
blink1073:PYTHON-5040

Conversation

@blink1073
Copy link
Copy Markdown
Member

@blink1073 blink1073 commented Jun 4, 2026

PYTHON-5040

Changes in this PR

Regenerates all test TLS certificates in test/certificates/ to include the Authority Key Identifier (AKI) and Subject Key Identifier (SKI) extensions, which Python 3.13 requires for certificate chain validation. Also adds a generation script and README so the process is reproducible and documented going forward.

Reverts the PYTHON-5038 workaround that had disabled SSL verification in TestKmsRetryProse.http_post().

Test Plan

SSL integration tests and encryption tests should be validated in CI against Python 3.13 on macOS and Windows (the originally failing configurations from PYTHON-5038).

Checklist

Checklist for Author

  • Did you update the changelog (if necessary)?
  • Is there test coverage? (existing SSL and encryption tests cover these certs)
  • Is any followup work tracked in a JIRA ticket? If so, add link(s)

Checklist for Reviewer

  • Does the title of the PR reference a JIRA Ticket?
  • Do you fully understand the implementation? (Would you be comfortable explaining how this code works to someone else?)
  • Is all relevant documentation (README or docstring) updated?

…ifier

Test certificates in test/certificates/ were missing the Authority Key
Identifier (AKI) and Subject Key Identifier (SKI) extensions, causing
ssl.SSLCertVerificationError on Python 3.13 (macOS and Windows).

Adds gen-certs.sh to document and reproduce the generation process.
Reverts the PYTHON-5038 workaround that had disabled SSL verification
in TestKmsRetryProse.http_post().
@codecov-commenter
Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

blink1073 added 6 commits June 4, 2026 07:43
setup_tests.py was pointing CLIENT_PEM and CA_PEM at the x509gen certs
from drivers-evergreen-tools, which were derived from the old
test/certificates/ca.pem. After regenerating that CA with a new key
pair, the server (which uses test/certificates/) and the client (which
trusted x509gen/ca.pem) no longer agreed on the CA, causing
ssl.SSLCertVerificationError in SSL auth tasks.
Set TLS_PEM_KEY_FILE, TLS_CA_FILE, and TLS_CERT_KEY_FILE to
test/certificates/ so that run-mongodb.sh uses our regenerated certs
when the SSL server is started, and async_client_context connects with
a CA that matches the server cert.
Set TLS_PEM_KEY_FILE, TLS_CA_FILE, and TLS_CERT_KEY_FILE on the
setup-mongodb-ssl workflow step so run-mongodb.sh uses our regenerated
test/certificates/ certs. async_client_context already trusts
test/certificates/ca.pem by default (helpers_shared.py), so server and
client now agree on the CA.

Also reverts setup_tests.py and integration_tests/run.sh to their
state before the failed x509gen fix attempts.
setup_tests.py was pointing CLIENT_PEM and CA_PEM at x509gen/ certs from
drivers-evergreen-tools, which were derived from the old ca.pem. After
regenerating test/certificates/ with a new CA key, the server
(test/certificates/) and client (x509gen/) no longer agree on the CA.

Switch both to test/certificates/ to match the server cert.
The CSFLE mock KMS servers were started using x509gen certs that lack
the Authority Key Identifier extension, causing Python 3.13 to reject
them with ssl.SSLCertVerificationError.

- Set CSFLE_TLS_CA_FILE and CSFLE_TLS_CERT_FILE to test/certificates/
  in setup_tests.py so the KMIP server and HTTP mock servers use our
  AKI-enabled certs.
- Add wrong-host.pem (SAN: wronghost.example.com) and expired.pem to
  test/certificates/ and gen-certs.sh for use in KMS TLS error tests.
Two test failures from regenerated certs:

1. test_mongodb_x509_auth: MongoDB derives the x509 username from the
   cert subject using RFC 4514 reverse order. The old client cert stored
   the subject with CN first so the reversed form matched
   MONGODB_X509_USERNAME ("C=US,...,CN=client"). Our new cert stored
   C=US first, reversing to "CN=client,...,C=US". Fix: use CN-first
   subject order (/CN=client/OU=.../C=US) in gen-certs.sh.

2. test_tlsCRLFile_support: The test verifies CRL enforcement works by
   connecting with tlsCRLFile and expecting ConnectionFailure. This
   requires the server cert to be listed as revoked in crl.pem. Fix:
   sign the server cert via `openssl ca` (tracked in the CA database),
   revoke it, then generate the CRL with the revoked entry.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants