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.
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?
Providing an update for others who may run into this. The issue was in the certificate installed on the client. Resolution is essentially the same as in this thread that I quoted above : Mbedtls_ssl_handshake return error -0x2700 - #5 by KennethSong
Need to use certificate that has CA flag set (not be leaf cert) and CN name must match between client cert and server cert. Most of certificates available from Google public certificate repository can be used, check the pki.goog. The expiration dates can be a challenge to embedded devices. Some note from Google on that:
Google’s recommendation for devices that seek to connect to Google services securely:
Blockquote
I’m building a product that connects to Google services. What CA certificates do I need to trust?
Google certificates are issued by different CAs depending on the current business needs and best practices. A certificate chain cannot be considered static.
Developers of applications connecting to Google services must take this into consideration and never hardcode Intermediate or Root Certificate Authorities. Developers should instead build a robust mechanism to update the set of CAs trusted by their applications.
Google services’ certificates can be issued by any of the Certificate Authority from this regularly updated list. Applications connecting to Google services should trust all the Certificate Authorities from that list.
Blockquote
