Hi,
For us to help you with this in the best possible way, please list the following information:
Regards,
Sigurd Hellesvik
It's SDK 2.5.2 on custom hardware. But we are using the Laird Pinnacle 100 module that has a 52840 paired with the Sierra Wireless modem. But we are using the Zephyr builtin mbedTLS library.
The cloud provider dug into this some and has the following comments;
-------------------------------------------------------------------------------------------------------
For some reason Azure don't send a certificate request when using a App Service hosted in docker in Azure. Our other endpoints is hosted using Azure function and the Microsoft Identity Provider intercept the call and do a rewrite of the header. That's why it works for device-dev.get-cloud.com and not auth.get-cloud.com.
The are two way of do a mTLS init connection.
1) The server ask for a certificate from the client (that's what Zephyr supports out of the box)
2) The client send the cert inside the handshake (that's what curl does).
------------------------------------------------------------------------------------------------
It seems to be related to an Azure issue;
https://github.com/MicrosoftDocs/azure-docs/issues/111230
Hopefully that sheds more light
Randall said:The are two way of do a mTLS init connection.
1) The server ask for a certificate from the client (that's what Zephyr supports out of the box)
2) The client send the cert inside the handshake (that's what curl does).
Both can be true here, so I do not quite grasp the difference.
The server first asks for a cert, and then the client sends it as part of the handshake?
Do you mean by 2) that the server never requests the cert? That would be wierd as the spec says:
The server MUST send a Certificate message whenever the agreed-upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except PSK).
Disclaimer: I must admit that I have not looked very much at the TLS spec before so I might vert well be mistaken here
But I still would like to know a bit more about the two different methods mentioned here.
EDIT:
nvm I found this other section on certificate requests saying MAY. And that is what you are referring to:
A server which is authenticating with a certificate MAY optionally request a certificate from the client.
As you see from the edit on the message below, I agree that it looks possible yes.
So I asked our crypto team if they know how to configure mbedtls for this, if possible
Looking at mbedtls code, it only gives the certificate if it is requested.
However, having a another look at the spec:
The client MUST send a Certificate message if and only if the server
has requested client authentication via a CertificateRequest message
So only sending cert if requested seems to align with the spec after all.
This was a bit back and forth. Let me know if anything was unclear and what you think about this
The person that posted the issue on the Azure github seems to think it's a bug. I guess Microsoft doesn't agree as they haven't done anything to address it. So if there is a way to get Zephyr to offer up the certificate on it's own, that would be great. If not, I may be stuck unless the cloud provider offers me an alternate way to renew keys.
Thanks,
The person that posted the issue on the Azure github seems to think it's a bug. I guess Microsoft doesn't agree as they haven't done anything to address it. So if there is a way to get Zephyr to offer up the certificate on it's own, that would be great. If not, I may be stuck unless the cloud provider offers me an alternate way to renew keys.
Thanks,
I think first, it would be good to have a closer look into this, maybe we can get some new info.
Can you get a wireshark sniffer log from the error you get?
Do you get UART logs from the device when it fails?
Try to turn on mbedlts logging and see if you get more info then.
CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED=yCONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED=yCONFIG_MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED=yCONFIG_MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED=yCONFIG_MBEDTLS_KEY_EXCHANGE_ECDH_ECDSA_ENABLED=yCONFIG_MBEDTLS_KEY_EXCHANGE_ECDH_RSA_ENABLED=yCONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED=yCONFIG_MBEDTLS_KEY_EXCHANGE_PSK_ENABLED=yCONFIG_MBEDTLS_KEY_EXCHANGE_RSA_ENABLED=yCONFIG_MBEDTLS_KEY_EXCHANGE_RSA_PSK_ENABLED=y
I see that you have enabled 10 options while CONFIG_MBEDTLS_KEY_EXCHANGE_ALL_ENABLED selects 11. Off-chance, but maybe you are missing the last one?
The only one missing is ECJPAKE. Doubted that key juggling is something that Microsoft is doing but I tried it anyway. And it still doesn't work. I can't really do wireshark since I'm using a cell modem. The cloud team did with a Linux-based Zephyr setup and it basically shows that the certificate isn't being sent to the authorization server. I tried to enable MBEDTLS debugging, but the level keeps getting set to 0. I tried to hard wire it with CONFIG_MBEDTLS_DEBUG_LEVEL but I didn't get any debug and looking it autoconf.h it's still set to 0. So something in the build is hard wiring it to 0 and I don't know what it is.
Try CONFIG_MBEDTLS_DEBUG?
One has to set CONFIG_MBEDTLS_DEBUG to y before setting the debug level will not trigger an error. So yes, I've already set that config to y.
Do you know anything about TLS 1.3 support in Zephyr?
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.
"