CC3200: Unable to connect with AWS IOT core using CC3200

The link you provided doesn't show the certificates.

have you linked the socket to the certificate using sl_SetSockOpt (see example below)?

Sl_SetSockOpt(sockID, SL_SOL_SOCKET, SL_SO_SECURE_FILES_CA_FILE_NAME, ”rootCA.der”, strlen(“rootCA.der”));

function static _i32 create_socke API is already doing that .I have attached code snippet for your reference . 

Please confirm Sl_SetSockOpt(sockID, SL_SOL_SOCKET, SL_SO_SECURE_FILES_CA_FILE_NAME, ”rootCA.der”, strlen(“rootCA.der”)); do we need to do this explicitly. 

i have also sent the certificates in private chat 

Are you getting SL_ESECBADCAFILE (-456)?

This means either the file is corrupted (however the root CA format looks fine) or the file path is wrong (can you store the file in the root folder of the file system, so you will not need any slashes in the path?).

I also don't think that this is the right root CA for the AWS server, but that will cause a different error code.

sorry we are getting (-458)  /* error secure level bad private file */ error. When we provide all 3 certificates in the order ,Private key , Device cert next root ca in secure files .

using same certificates i am able to connect with AWS iot core using MQTT.fx .

Did you check with the files in the root folder?

certificates are copied to f00_cer_private.der.Please let me know if this need to be changed ?

how did you copied the certificate? in an OTA or using uniflash?

The path+name in the file system should be exactly what you give in "Sl_SetSockOpt". 

You can use "sl_FsGetInfo" to check if the file exists.

we used uniflash to download the file. i have verified path name using sl_FsGetInfo function and it return the status as '0'.I think we have no issue with file location , if possible can you please try to connect AWs iot core from your side using the certificates  provided by me .I can provide the endpoint details.

the -458 means that the stack can't find the private key file in the file system (assuming you used the provided private key).

where did you use the following file name: f00_cer_private.der?

Kobi,

I am working with Linga in this project. Including more details . "f00_cer_private.der" is reference in our CC3XX_template.xml file.

file system obtained from the target device using uniflash

verified that the file exists and used the function ReadFile() from simplelink to get the actual number of bytes of the certificate. Matches with the file system. Still having -458 error 

can you capture the NWP log? (see chapter 19 in https://www.ti.com/lit/pdf/SWRU368C)

Enclosed the NWP logs. Please take a look and let you know your thoughts

NWP.zip

something is wrong with the logs. I can't parse them.

Kobi Enclosed the logs .Please review them. Included both text and binary version. NWPCC3200.zip

I can see that we were able to read the root ca file but it failed the parsing (returning BADCA=-456 response).

Make sure the file written to "/cer/ca.der" is exactly the ca.der you sent me. I couldn't find any reason for the parsing failure (assuming the file content is correct) but we'll review/test it internally. If i find anything, i'll let you know.

Have you installed the latest CC3200 service pack (I can't see this in the log)? 

Kobi i am using the same files that has been shared with you .Also the ats endpoint is same.The partition name where I have the certificate is /cer/ca.der. Service pack details are ,

Host Driver Version: 1.0.1.14
NWP Version: 2.15.0.1
FW Version: 31.1.6.0.2
Phy Version: 1.0.3.37
Build Version 2.15.0.1.31.1.6.0.2.1.0.3.37
Chip Id 67108880

ok. i will try this root CA on my end.

It may takes couple of days and I let you know my findings as soon as it is done.

Kobi,

Finally we are able to connect with AWs iot core after below list of changes .

Converted private key file to .der using the below command . 

openssl rsa -inform pem -in aws_prvkey.key -outform der -out aws_prvkey.der

Converted device cert file to .der using below command 

openssl x509 -inform pem -in aws_deviceCert.crt -outform der -out aws_rootCA.der

Root-ca was used as specified in this ticket: https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/881308/cc3200-launchxl-cc3200

But one thing i am not able to understand why we need to use only the " Starfield Class 2 Certification Authority root ca" why not other rootca provided by AWS.

Based on aws provided details in link :  to Prepare for AWS’s Move to Its Own Certificate Authority | AWS Security Blog (amazon.com).It does not own the " Starfield Class 2 Certification Authority root ca" certificate. Please may i know what changes we need to do in CC3200 SDK /Source for supporting regular root ca provided by AWS or Starfield Services Root Certificate Authority - G2.

The major difference between Starfield Class 2 Certification Authority root ca and AWS / Starfield Services Root Certificate Authority - G2 is signature algorithm.

Starfield Class 2 Certification Authority root ca used : sha1RSA

AWS / Starfield Services Root Certificate Authority - G2 root ca used : sha256RSA

Do we update anything in CC3200 SDK to support sha256RSA.

Kobi ,

 i have sent my endpoint details in personal chat.

This is a question for AWS. 

Sorry Kobi .This is may not be AWS question because client is rejecting the connection. AWS root CA are working with all other micro controller and PC application only TI is not accepting that certificate. May i know TI CC3200 supports sha256 or not ? Can we connect CC3200 to AWS IOT using AWS root ca ?

yes, with a service pack it should support sha256.

I don't understand, were you able to connect with the "Starfield Class 2 Certification Authority root ca"?

If yes, why are you trying to use other root ca for this endpoint?

i am able to connect with Starfield Class 2 Certification Authority root ca but not able to connect with AWS root CA. Please refer the link : How to Prepare for AWS’s Move to Its Own Certificate Authority | AWS Security Blog (amazon.com)

As per this link Starfield Class 2 Certification Authority root ca is not maintained by AWS and that certificate is also going to expire in 2034 that's why we don't want use that certificate. We we would like to use the certificates which is maintained  by AWS so that process will be easy for us when their is any change in certificate .

Yes i am using latest service pack : CC3100_CC3200_ServicePack_1.0.1.14-2.12.2.8 

Please let me know what we need to change to use AWS Root CA.

Hi Kobi ,

 Please may i know is their any update on AWS root CA support changes required on TI SDK.

Each socket can be assigned with one root CA. If the server is about to replace the root CA, what you can do is adding a code that will try to connect using one root CA (e.g. Starfield) and in case of failure it will try to connect again with the 2nd root CA (Amazon root ca).

Kobi,

please my question was why TI 3200 is closing TLS connection with BAD certificate error when we use AWS Root CA.I do understand every socket will be assigned to root ca. Please let me know if you looking for any logs. Can you please check connecting CC3200 to  AWS IOT core using AWS root CA.

When we tried to connect to AWS it was using the Starfield Root CA.

Currently AWS is not maintaining the Starfield Class 2 Certification Authority root ca .Please may i know when TI can support AWS root CA with CC3200.

We can't support any new updates on CC3200. If there is a problem with the specific certificate (checking the content i don't see a reason). You can try using an external TLS stack (such as mbedTLS) on top of the CC3200 TCP socket. 

 "You can try using an external TLS stack (such as mbedTLS) on top of the CC3200 TCP socket. " Please may i know how this solution will work because it has still use the sl_ZZZZ network api's which will have the same issue .

It will use the unsecure TCP sl_socket (so use the network stack in the NWP, but not the TLS stack).

On the host you will implement the TLS stack. In the next CC32XX (3220/35) SDK we will include such solution for TLS1.3 support (as the internal TLS stack only supports TLS1.2 and can't be fixed with an SP). This should work with CC3200 as well.

The certificate in this case will only be handled by the host-based TLS stack.