CC3220SF-LAUNCHXL: Image vs TLS certificates confusion

Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: UNIFLASH, CC3220SF

Dear TI,

I am currently trying to connect to my MQTT broker which uses TLSv1.2 signed by LetsEncrypt. I am getting certificate errors, but I am also a bit confused about the difference between certificates that are used for the image, and for HTTPS traffic.

If I understand correctly, an image is signed by a CA to make sure that image is valid for Secure Boot . These should be my own certificates, so that no one else will be able to manipulate the image. If I understand correctly, these can be configured using the "Trusted Root-Certificate Catalog" in UniFlash. What I don't understand, is which CA files are used to access HTTPS websites. On normal desktop browser, the browser normally contains a list of default CA files that can be trusted to verify a HTTPS connection. Is the default "Trusted Root-Certificate Catalog" something similar to that? or should CA files for HTTPS traffic be provided separately as files?

What I tried so far, is adding the LetsEncrypt Root and intermediate certficates as separate files, however I keep getting the following error:

.[SOCK ERROR] an event received on socket 0
[SOCK ERROR] Used wrong CA to verify the peer.
Connection to broker failed, Error code: -688

According to the errors.h file that is a

#define SL_ERROR_BSD_ESEC_ASN_NO_SIGNER_E                               (-688L) /* ASN no signer to confirm failure */

What am I doing wrong for the MQTT example (mqtt_client_CC3220SF_LAUNCHXL_tirtos_gcc)?
And just to verify: I shouldn't use these certificates as Trusted Root-Certificate Catalog right? Because otherwise everyone with the LetsEncrypt keys could potentially have access to the device.

over 6 years ago

0 Michael Reymond over 6 years ago

TI__Mastermind 40965 points

Hi MJ,

Our certificate handling guide is a good resource for understanding the different uses of certificates, and how certificates are used to connect to a secured MQTT server:

http://www.ti.com/lit/ug/swpu332/swpu332.pdf

In general, for any secured connection with the CC3220 as the client you will need to pass in the specific root CA certificate that will be used to verify the server's certificate chain. This certificate has to match the root CA cert that signs your server's certificate. The trusted root CA catalog is only a catalog of root CA cert hashes; it doesn't actually have the full root CA certs. Thus, you need to provide the actual root CA cert to be used when you start a secured connection with the CC3220. This root CA cert will have its hash compared with the one in the catalog to ensure authenticity, but other than that the catalog is not used during cert chain verification.

For the MQTT example the main thing you need to do is provide to correct root CA cert file to the serial flash with the filename specified in Mqtt_Client_secure_files of mqtt_client_app.c. Looking at the LetsEncrypt documentation it looks like all of their certificates are ultimately signed with the DST Root X3 root CA certificate. You can double check this by adding the following code to your SimpleLinkSockEventHandler case SL_SSL_NOTIFICATION_WRONG_ROOT_CA:

case SL_SSL_NOTIFICATION_WRONG_ROOT_CA:
            UART_PRINT("[SOCK ERROR] Used wrong CA to verify the peer.\r\n");
            UART_PRINT("Please install the following Root Certificate:\n\r");
            UART_PRINT("  %s\n\r", pSock->SocketAsyncEvent.SockAsyncData.pExtraInfo);
            break;

Once you have identified the root CA you need, you can either get it direct from the cert authority's website or you can actually copy it from your PC's root CA cert database following the instructions here:

https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/673247/2478357#2478357

Once you have the correct certificate flashed onto the CC3220 serial flash, you should no longer get error -688. The "ASN no signer to confirm" error basically means that the CC3220 cannot verify the authenticity of the server's cert chain since the root CA cert it was using the verify the chain doesn't match the root CA cert that's actually provided in the chain.

Let me know if you still run into issues after adding that root CA cert.

Regards,

Michael

0 MJ over 6 years ago in reply to Michael Reymond

Intellectual 950 points

Thanks a lot for the link of the certificates. It has been very helpful! My understanding for the code signing is a lot better now.
Only thing I was wondering if I have to be careful which certificate authority I pick when I want to purchase a code signing certificate. According to the document the hash needs to be in the catalog, but are all authorities in this catalog? I couldn't find a list of supported authorities.

For the MQTT: I had to use the DST Root X3 root CA certificate instead of the "ISRG Root X1 (self-signed)" or "Let’s Encrypt Authority X3 (IdenTrust cross-signed)". When I uploaded the correct certificate, connection was made successfully.

0 Michael Reymond over 6 years ago in reply to MJ

TI__Mastermind 40965 points

Hi MJ,

Glad you got the secured MQTT connection working.
The list of root CA certs can be found in the <sdk dir>/tools/cc32xx_tools/certificate-catalog/readme.html

Regards,
Michael

Wi-Fi

Wi-Fi forum

CC3220SF-LAUNCHXL: Image vs TLS certificates confusion