Mbed-TLS
Allow external certificate validation in Mbed TLS 4.0
Suggested enhancement
Allow disabling certificate validation even in Mbed TLS 4.0 (also for TLS 1.3), as long as a certificate validation function is set with mbedtls_ssl_conf_verify(), so developers can do their own certificate validation.
Justification
We need to verify certificates against an external certificate management system that just provides an API to send a certificate along with some meta information about why you want to verify this certificate (in this case, because we want to establish a TLS connection to an endpoint with the following address...) and get a verification result in return (which is either just "go ahead" or an error telling us why we cannot trust this certificate for this purpose).
In Mbed TLS 2.x we could achieve this by setting a verification function with mbedtls_ssl_conf_verify() and telling Mbed TLS itself not to verify the certificate (MBEDTLS_SSL_VERIFY_NONE or MBEDTLS_SSL_VERIFY_OPTIONAL).
In Mbed TLS 3.6, it's no longer possible to disable client-side verification for TLS 1.3. So even if a verification function is set with mbedtls_ssl_conf_verify(), Mbed TLS will insist on verifying the certificate itself after calling that function, and that will fail because no CA chain is set in our case.
The reason why we cannot simply set a CA chain or use mbedtls_ssl_conf_ca_cb is that we do not have access to the CAs stored in the external system. This system is a black box to us, and it may have even stricter rules than those required by the RFCs, so we have to use it for certificate verification to comply with the policy.
Mbed TLS 3.6.1 will allow us to disable verification again, but 4.0 should disable it for good, and that would be a big problem for us.
See also #7080
Two other cases of standard validation failures (had been described in the same issue 7080).
- Remote connection in browser with a self-signed certificate. Modern browsers display a warning, then user may view the certificate and manually allow connections.
- Automatic email notifications. Connecting to SMTP server in clear text might be disallowed and only protected connections were possible. For low security cases it might be impractical to keep certificates locally or connect to certification authorities.
For a real-world example of where allowing a third party-system to verify the cert-chain: macOS and iOS. Namely, in macOS reading the system CAcert store is deprecated (and to be removed). And on iOS it was never possible. Meaning the only way to use the system CA-store is to use Apple's verification functions (like SecTrustEvaluateWithError()).
Or else you're stuck with embedding a CACert bundle along-side your app (rather than using the system-built-in CA certs). This is bad UX, however, because now end-users have to search a separate secret/unknown place to manage the CAcerts rather than just use the existing tools).
Yes, it's less than ideal that Apple has designed their systems this way, but ... monopolies 🤷
