Which certificates/CAs are included when using "runtime-tokio-rustls"?

[lcmgh]

From other crates there are usually options like

• webpkis
• host system/native certs

but it is not clear to me which certs are bundled when using this flag via sqlx?

[abonander]

It's never really come up before but we currently hardcode webpki-roots with the tls-rustls feature: https://github.com/launchbadge/sqlx/blob/main/sqlx-core/src/net/tls/tls_rustls.rs#L131

The reason being that, if you're building a container image (Docker/OCI), the system certificate packages (e.g. ca_certificates) generally aren't installed in most base images by default. Either way, you're going to end up baking the root certificates into your image at build time, so we preferred the approach that generates less friction.

When using tls-native-tls, it just uses the system certs.

I'm not against making this more configurable, but the question is, how much value would that add?

[lcmgh]

I think that using webpki-roots as a default is a wise choice for many of us. But in more restricted corporate environments one needs to have more fine-grained control about which certs are accepted.

The question came up on our side due to a cert rotation at AWS RDS: https://aws.amazon.com/de/blogs/aws/rotate-your-ssl-tls-certificates-now-amazon-rds-and-amazon-aurora-expire-in-2024/

From our corporate perspective we must add a bunch of whitelisted cas/certs to our image and actually only these. Having no way to opt-out of webpki-roots adds another bunch of certs we formally have not approved (I am not challenging the trusthworthiness of webpki-roots here). So most easy would be to configure all libs to not fetch additional certs and simply rely on the ones that were bundled into the image/os. Hence I think that such a feature request makes sense. Concrete I would like to see a feature flag to use rustls with native certs only.