mbedTLS version: mbed TLS 2.16.6 branch released 2020-04-14
We are using mbedTLS on ARM target to provide TLS 1.2 for GCP connections. One connection type is using “self-managed” SSL certs and works fine.
The other connection’s end point is Google HTTPS load balancer and is using “Google-managed” SSL certs. This connection fails with flags == 0x08 which is the “not signed by trusted CA” error.
Flag is set in function x509_crt_verify_chain(…) after call to x509_crt_find_parent(…) returns no “parent” pointer.
/* No parent? We're done here */
if( parent == NULL )
{
*flags |= MBEDTLS_X509_BADCERT_NOT_TRUSTED;
return( 0 );
}
On this forum I found a post with similar problem ( Mbedtls_ssl_handshake return error -0x2700 ) where the handshake was failing due to CA being set to FALSE.
The OP in that post was able to resolve the problem after modifying the certificate.
I downloaded and compared the two certs and sure enough the one that is working has CA:TRUE and the failing which is Google-managed cert has CA:FALSE.
Google’s online docs ( SSL certificates overview | Load Balancing | Google Cloud ) list some limitations to Google-managed SSL certs, in particular this line:
“Google Cloud load balancers don’t support client certificate-based authentication (mutual TLS, mTLS).”
We are in communication with Google about the problem but I wanted to ask some questions here:
-
Is there a known incompatibility between mbedTLS and Google HTTPS load balancers? Google lists “mutual TLS” and “mTLS” as examples of “client certificate-based authentication”. Does mbedTLS fall under same category? Not sure if “mTLS” is/was another name for mbedTLS.
-
Is there any remedy for CA:FALSE on the client side other than running with “authmode” set to MBEDTLS_SSL_VERIFY_OPTIONAL? What are the security risks with that, MITM, certs spoof, self-signed certs, etc?
Thanks!