feat: Update TLS validation to use both SAN and CN fields.#2150
Merged
Conversation
hessjcg
force-pushed
the
feat-new-tls-logic
branch
from
7d1a95c to
1e93513
Compare
kgala2
approved these changes
Apr 28, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This updates the logic used by the connector to validate server certificates.
When connecting to the instance, the connector's TLS validator will first check the SAN field,
and then if that fails check the CN field in the certificate for the instance name. This will enable
the connector to work smoothly with both legacy and newer instances.
To summarize the deviations from standard TLS hostname verification:
Historically, Cloud SQL creates server certificates with the instance name in the Subject.CN field in
the format "my-project:my-instance". The connector is expected to check that the instance name
that the connector was configured to dial matches the server certificate Subject.CN field. Thus,
the Subject.CN field for most Cloud SQL instances does not contain a well-formed DNS Name. This
breaks standard TLS hostname verification.
Also, there are times when the instance metadata reports that an instance has a DNS name, but
that DNS name does not yet appear in the SAN records of the server certificate. The client should
fall back to validating the hostname using the instance name in the Subject.CN field.
See also: GoogleCloudPlatform/cloud-sql-go-connector#979