Key Exchange issue

[Randall]

I'm communicating with my customers website through a certificate and key provided by an OAUTH process.  I'm posting data to the website successfully by adding those certs to my TLS Credentials

   err = tls_credential_add( TLS_SEC_TAG,

                             TLS_CREDENTIAL_SERVER_CERTIFICATE,

                             certPtr,

                             strlen(certPtr) + 1);

   if ( err ) LOG_ERR( "Error adding GET_CLOUD_CERT" );

   param_read( PARAM_REPO_CLOUD_KEY, keyPtr, CLOUD_KEY_LEN );

   err = tls_credential_add( TLS_SEC_TAG,

                             TLS_CREDENTIAL_PRIVATE_KEY,

                             keyPtr,

                             strlen(keyPtr) + 1);

   if ( err ) LOG_ERR( "Error adding GET_CLOUD_KEY" );

   err = tls_credential_add( TLS_SEC_TAG,

                             TLS_CREDENTIAL_CA_CERTIFICATE,

                             oauth_root_ca,

                             strlen(oauth_root_ca) + 1);

I'm posting this to their site device-dev.get-cloud.com

Another process that I need to implement is to renew the keys when they are close to expiration.  To do this I need to send a GET request to auth.get-cloud.com using the same cert and key pair.

This is failing on my device.  It does work if I use curl;

curl -vv --key key.pem --cert cert.pem https://auth.get-cloud.com/renew 

So I'm thinking that authentication with the cert/key is working but the key exchange is not.  I've tried enabling every exchange option that I can find;

CONFIG_NET_SOCKETS_SOCKOPT_TLS=y

# TLS configuration

CONFIG_MBEDTLS=y

CONFIG_MBEDTLS_BUILTIN=y

CONFIG_MBEDTLS_ENABLE_HEAP=y

CONFIG_MBEDTLS_HEAP_SIZE=60000

CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=8096

CONFIG_MBEDTLS_PEM_CERTIFICATE_FORMAT=y

#CONFIG_MBEDTLS_USER_CONFIG_FILE="mbedtls_config.h"

CONFIG_MBEDTLS_ECP_ALL_ENABLED=y

CONFIG_MBEDTLS_ECP_C=y

CONFIG_MBEDTLS_ECDSA_C=y

CONFIG_MBEDTLS_ECP_DP_SECP384R1_ENABLED=y

CONFIG_MBEDTLS_ECP_DP_SECP521R1_ENABLED=y

CONFIG_MBEDTLS_ECP_DP_BP384R1_ENABLED=y

CONFIG_MBEDTLS_ECP_DP_BP512R1_ENABLED=y

CONFIG_MBEDTLS_HASH_SHA512_ENABLED=y

CONFIG_MBEDTLS_SERVER_NAME_INDICATION=y

CONFIG_MBEDTLS_DEBUG=n

CONFIG_MBEDTLS_ECDH_C=y

CONFIG_MBEDTLS_SHA1_C=y

CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED=y

CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED=y

CONFIG_MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED=y

CONFIG_MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED=y

CONFIG_MBEDTLS_KEY_EXCHANGE_ECDH_ECDSA_ENABLED=y

CONFIG_MBEDTLS_KEY_EXCHANGE_ECDH_RSA_ENABLED=y

CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED=y

CONFIG_MBEDTLS_KEY_EXCHANGE_PSK_ENABLED=y

CONFIG_MBEDTLS_KEY_EXCHANGE_RSA_ENABLED=y

CONFIG_MBEDTLS_KEY_EXCHANGE_RSA_PSK_ENABLED=y

But nothing works.  Some things seem to be out of my range because I'm using MBEDTLS_BUILTIN.  Some options seem to call for NRF_SECURITY or L2_OPENTHREAD.  I'm concerned that trying to move to any of that will cause problems with my existing setup.  I was hoping that you might be able to think of some things I can try.

[Sigurd Hellesvik]

Randall said:

Do you know anything about TLS 1.3 support in Zephyr?

You have triggered an automatic quote from my part:
I am not able to answer questions about our timeline. You can try to ask your local sales representative from Nordic Semiconductor for information about our timeline.

For adding the cert manually, here is some info that might help you do that:

"
I looked what happens when the TLS state machine enters the state MBEDTLS_SSL_CLIENT_CERTIFICATE
https://github.com/nrfconnect/sdk-mbedtls/blob/main/library/ssl_tls12_client.c#L3552

The mbedtls_ssl_write_certificate() function will skip sending client certificate if ssl->handshake->client_auth == 0

ssl->handshake->client_auth is only set if ServerHello contains a Certificate request here:
https://github.com/nrfconnect/sdk-mbedtls/blob/main/library/ssl_tls12_client.c#L2523

If the customer wants to hack a solution that always sends the client certificate without receiving a certificate request they can probably just set ssl->handshake->client_auth somewhere in the state machine.
"

[Randall]

Interesting suggestion.  I tried several variants of overriding the client_auth flag.  Unfortunately, it all resulted in a TLS handshake error. 

Looking at the above it also appears to be using NRF_SECURITY with MBEDTLS_LIBRARY.  I'm using MBEDTLS_BUILTIN.  I don't know if that makes any difference.

Randall

[Sigurd Hellesvik]

I think that TLS code is the same for MBEDTLS NRF_SECURITY and MBEDTLS_BUILTIN. It is the underlying crypto drivers that are changed.

However, I am not 100% on that, so I suggest that you print or step through code or something like that to verify that the file is really used

[Randall]

I did, and the changes did attempt to write the certificate despite not receiving a request.  But for some reason it still produced a TLS handshake error.

On the positive side, the cloud team has agreed to give me an alternate route to get certificate and key renewals.  So I guess this ticket can be closed out.

[Sigurd Hellesvik]

Randall said:

I did, and the changes did attempt to write the certificate despite not receiving a request.  But for some reason it still produced a TLS handshake error.

To quote myself from talking to our developers:

"At the very least if the hack work that would be a good indication to them being correct about what goes wrong"

And especially when you are not able to make it work like that, I start to suspect that the handshake request really is not the cause here after all.

However, if you got a workaround for key renewal, that fixes your issue, and that is that.
Good luck onwards!