feat(tls): server certificate SAN can have a trailing dot

[levkk]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 2.40964% with 81 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pgdog/src/net/tls.rs	0.00%	80 Missing ⚠️
pgdog/src/backend/server.rs	66.66%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[sgrif]

I'm not familiar with the rustls API but this seems like a lot of code for a trailing dot. (And it wouldn't surprise me at all that the TLS library API actually makes it this hard)

[levkk]

Yeah... I'm not sure if this is how this is supposed to be done. I'm waiting for a review from Ryan.

[rlittlefield]

It looks like curl strips trailing dots automatically, but the default in go crypto/x509, python's ssl, and rustls-webpki all mismatch this, apparently by design. From what I can tell, its probably a malformed cert from google.

Here is the python GCP cloud sql issue:
GoogleCloudPlatform/cloud-sql-python-connector#1087

It looks like the GCP Go connector does the same thing this PR does, so that's a good sign: https://github.com/GoogleCloudPlatform/cloud-sql-go-connector/blob/main/internal/cloudsql/tls_verify.go#L112-L118

I guess I could see not wanting to fall back to custom code for strict verification, so if that's a concern I suppose it could be a configuration option to strip the dot?

[rlittlefield]

Would this make sense as

Err(rustls::Error::InvalidCertificate(
    rustls::CertificateError::NotValidForName
    | rustls::CertificateError::NotValidForNameContext { .. },
))

It sounds like rustls considers it okay to change enum variants, so this might help avoid a silent behavior change if I'm reading this right.