This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/CC3220S-LAUNCHXL: AWS IoT Certificate Unable to successfully connect

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

Tool/software: TI-RTOS

With the AWS IoT Shadow Sample I am having the usual troubles connecting to AWS with a full ROOT-CA Certificate.

I Followed these instructions, and have added the code to ignore the SL_ERROR_BSD_ESECUNKNOWNROOTCA error as per CC3220SF-LAUNCHXL: AWS IoT Error -24.

However, commenting this out should only be needed when working with an invalid root certificate, but I have a valid root certificate, in fact the same one as in the above post, but I still get the SL_ERROR_BSD_ESECUNKNOWNROOTCA error.

I loaded and executed the Java AWS_IOT_DEVICE_SDK_JAVA and it works fine as well, but it never uses a root certificate.

I'm wondering if it will ever work?

Is there a case where the root certificate is needed and works?

  • Karl,

    We are getting an engineer to look at this.

    Todd
  • Okay - sounds good.
  • Please find attached my cert.h file. (don't care if the private key is in there b/c once it's all working I could always regen a new certificate anyway). Screenshot shows the certificate is active.

    For what it's worth, WinGPG and Kleopatra imports the certificate but says it's not certified.

    certs.h

  • I don't know if it should work, but AWS won't allow you to register the certificate they generated.

  • I also found this thread -- my "region" is us-west-2 since my endpoint

    github.com/.../26
  • Hi Karl,

    Have you updated the root CA list in CC3220 with a valid file from the certificate-catalog folder? I think, SL_ERROR_BSD_ESECUNKNOWNROOTCA may appear if it is not done.

    Regards the certificate registration in AWS. this is for another purpose. You can register your own root ca certificate there and configure AWS such way that it will accept all client certificates generated by you using this root CA.

    Best regards,
    Eugene.
  • Hi,

    Well, yes, I'm pretty sure. I flashed the CC3220 blank and then I flashed with the

    C:\ti\simplelink_cc32xx_sdk_1_50_00_06\examples\rtos\CC3220S_LAUNCHXL\demos\out_of_box\uniflash\OOB_RS_tirtos.zip from the sdk as you can see. I set the Trusted Root-Certificate Catalog from certificate-catalog file and the signature source file from same directoy (see image, and the service pack).

    The readme says the list includes

    "VeriSign Class 3 Public Primary Certification Authority - G5" and this is the same authority that issued the AWS Root Certificate.

    The thing is the AWS-IoT certificate that is issued for use with MQTT doesn't seem to have any valid issuing path, so I'm pretty sure having the AWS root certificate around is meaningless since the AWS-IoT certificate can't chain to it anyway.

    The simplelink socket code may work with a valid certificate chain but the certificates being issued by AWS-IOT aren't certified. So I think it's a lost cause in the case that people are trying to use those certificates in this sample code. If the sample code is assuming the certificates are certified then it will always fail with the aforementioned error.

    $ openssl verify af02dc3615-certificate.pem.crt
    af02dc3615-certificate.pem.crt: C = US, ST = CA, L = San Francisco, O = Karl Nicholas, OU = Self, CN = 6abf887188407c736bad2a563d8d03cebe5bd0d1c64ae3f97e56b89e23988588, emailAddress = XXX
    error 20 at 0 depth lookup:unable to get local issuer certificate


  • Where did you get the certificates? We also use AWS IoT, we got certificates from AWS console: client certificate and private key was generated and root ca just downloaded. And yes, AWS IoT client certificate has no chain, but it works without it. It is used for creating TLS connection, so chain is not needed there. Root CA certificate is used to validate remote peer.
    I had SL_ERROR_BSD_ESECUNKNOWNROOTCA when used a self signed root ca certificate for our own mqtt broker. Since it was self signed, simplelink could not validate it against its own root ca list.
  • I am experience this same exact problem.

    Down in network_sl.c the call to connect fails with a -468:

    #define SL_ERROR_BSD_ESECUNKNOWNROOTCA (-468L) /* connected but the root CA used to validate the peer is unknown */

    I've updated the catalog using uniflash to no avail.

    Is there a fix for this issue?

    Thanks,
    Michael L. Gantz
  • Hi Eugene,

    You can see earlier in this thread that I'm getting the certificates from the AWS IoT console, client and private key generated, root ca just downloaded.

    Is your MQTT endpoint in US-EAST or US-WEST? Mine's on US-WEST-2. I saw on some github threads some conversation about this and AWS seemed to say it made a difference.

    Otherwise, I'd be happy to try to connect to an endpoint and certificate that you have that works, or visa versa if you want. I can send you my certificate and a screen-shot showing it's activated. Don't use the ones posted earlier in this thread because I have revoked them, but it's easy enough to create new ones or send you the one I'm trying at the moment.

    I'm really not doing anything fancy that I can tell.

  • Michael, see thread on  CC3220SF-LAUNCHXL: AWS IoT Error -24 for code workaround.

  • Hi Karl,

    My endpoint is us-east-1. Just compared - I use exact same root ca certificate.
    Not sure, what is the best way to debug. I catch traffic with wireshark in such cases. Another option - try to connect using the same certificates via some mqtt client, like MQTT.fx and see, if there any problem, check its log.

    Eugene
  • Hi Eugene,

    I think I misspoke when I said I thought that the root ca list in the CS3220 had been update with a valid file from the certificate-catalog folder.

    In fact I have been using the certificate-playground stuff, which is all "dummy" certificates.

    I tried flashing an OOB build with the certificate-catalog folder but I am not able to make it work, which is not particular surprising since I have not read any documentation on this yet. I got a "root ca unknown" error, or perhaps a "file not found" error depending on what I tried.

    My intention is to flash the a OOB binary with valid certificates from certificate-catalog and then have the aws shadow run okay without a SL_ERROR_BSD_ESECUNKNOWNROOTCA when I debug it from CCS-7.

    Does this even make sense?

    It is possible I need to have my own certificate in order to flash an OOB binary with the valid certificate-catalog certificates? If so, would a "code signing" certificate work, or a "self signed" certificate?

    Thanks.
  • Hi Karl,

    It sounds like you have configured your board to boot your application from flash. Is that correct?

    If that's correct, I'm wondering if you are able to run the Shadow example when you don't boot from flash? I.e. just load and run it via CCS, using the certificates that you get from Amazon and with the cert store option check box *checked*

    Steve

  • Hi Karl,

    Not sure, that I could help you with it too much, because I use CC3120 and UniFlash to flash everything. It has an option to upload new service pack and root ca list files.

    I had to upload a code signing certificate when used secure file system. When you upload some file and mark it as "secure" you need to provide a valid signature or a private key (in second case Uniflash can generate the file signature by itself). If you'll obtain a code signing certificate, check this my thread, I had some troubles with it:

    Best regards,

    Eugene.

  • Hi Steve.

    I don't think so. What I did was flash the OOB (Out of Box) application to the CC3220 and then run the Shadow example from CCS.

    When I flash the OOB application I can only successfully do so using the certificate-playground certificates. I have not been able to flash using default Trusted Root-Certificate Catalog (If I remember correctly I get a FS_FILE_NOT_FOUND ) or adding the certificates from the certificate-catalog (If I remember correctly I get a FS_ROOT_CA_UNKNOWN).

    So, my current supposition is that I need to flash an application, I presume any application, signed with a certificate that I purchased somewhere. My current supposition is then I will be able to use the proper certificates from the certificate-catalog.

    I'm thinking once those certificates from certificate-catalog are flashed in the CC3220 then the Shadow example will authenticate properly however I run it, either by flashing it or by running in debug mode from CCS.
  • HI Eugene.

    I'm not sure what you mean when you say you use UniFlash to flash. So do I. I use the option to upload root ca list files, but I can't get that option to work.

    I looked at Thawte for a code signing certificate, but they don't offer individual code signing certificates.
  • Hi Karl,

    Can you please try the following steps and let me know if they allow you to run the Shadow Example from CCS?

    1. Using Uniflash, configure the default cert store:  .

    Disconnect from Uniflash. Please make sure that your board is disconnected from CCS and powered down.

    (Note that the details of the below steps can be found in the AWS Quick Start Guide, sections "Building and running Examples in CCS" and "Example Pre-Build Steps")

    1. power the CC3220 back on and connect it to a terminal for program output.
    2. import the Shadow Example into CCS
    3. edit the file "aws_iot_config.h"
      1. update the macros with the proper account info for your device, as found in the AWS console when you log in.
    4. edit the "certs.h" file
      1. update the file with the content of the certs you downloaded from Amazon
    5. edit the wificonfig.h file
      1. update the macros with the SSID and password of your access point
    6. click the "debug" button to build the project, launch the CC3220 and load the app
    7. run

    (Again, the full details of the above steps are found in the AWS Quick Start Guide. Please refer to that in addition to the above).

    Are you able to run successfully?

    Steve

  • Hi Steve,

    I found the quickstart guide and all that as you pointed out.

    I used UniFlash and set the Use Default Trusted Root-Certificate Catalog as you mentioned.

    However, I'm still getting the same result. The Shadow example runs but gives me the SL_ERROR_BSD_ESECUNKNOWNROOTCA error.

    The thing is when I connect to the CC3220 with UniFlash and look at the files on the system there are no files "/files/certstore.lst" or "/files/certstore.lst.signed". Where would they come from?

    I tried copying "certcatalog20161113.lst" to "certstore.lst" (and the signed file) and writing those files to the above mentioned locations, but it did not help. I still get the same SL...UNKNOWNROOTCA.error.

    Where should I get able to get these /files/certstore.lst files? Are they in the SDK or somewhere online?
  • Hi Eugene,

    So, the root_ca certificate is just used to verify the connection to the host you said?

    So, I should be able to debug it by making sure that I can connect to the host using the aws_root_ca certificate to authenticate the connection by using some other tools, such as you suggested.
  • Hi Eugene,

    I tested the connection manually with openssl   -->  

    openssl s_client -connect a3joj5u9gv9t8f.iot.us-east-1.amazonaws.com:8883 -CAfile aws-root-ca.pem.crt -cert 545acc1c00-certificate.pem.crt -key 545acc1c00-private.pem.key

    And it seems to authenticate and connect and it's all happy as far as I can tell.

    So, yea, I think you're correct. All these comments about flashing and certstores don't mean anything. 

  • Hi,

    I am able to reproduce the problem with very straightforward simplelink only code. Is this an issue that has been fixed in more recent versions of CC3220? Is it possible to compare versions of the firmware or somehow flash an update the simplelink network processor?

    I am able to test the client connection and certificate from AWS with openssl.

    $ openssl s_client -connect iot.us-west-2.amazonaws.com:443 -CAfile aws-root-ca.pem.crt -cert 545acc1c00-certificate.pem.crt  -key 545acc1c00-private.pem.key
    CONNECTED(00000003)
    depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
    verify return:1
    depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4
    verify return:1
    depth=0 C = US, ST = Washington, L = Seattle, O = "Amazon.com, Inc.", CN = iot.us-west-2.amazonaws.com
    verify return:1
    ---
    Certificate chain
     0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=iot.us-west-2.amazonaws.com
       i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
     1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
       i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
    

    and the code

    //*****************************************************************************
    // includes
    //*****************************************************************************
    #include <stdlib.h>
    
    /* TI-DRIVERS Header files */
    #include <ti/display/Display.h>
    #include <ti/drivers/net/wifi/simplelink.h>
    #include "uart_term.h"
    
    //****************************************************************************
    //                      LOCAL FUNCTION PROTOTYPES
    //****************************************************************************
    
    #define AWS_IOT_MQTT_HOST              "a3joj5u9gv9t8f.iot.us-east-1.amazonaws.com" ///< Customer specific MQTT HOST. The same will be used for Thing Shadow
    #define AWS_IOT_MQTT_PORT              8883 ///< default port for MQTT/S
    
    #define AWS_IOT_ROOT_CA_FILENAME       "/cert/root-ca.crt" ///< Root CA file name
    #define AWS_IOT_CERTIFICATE_FILENAME   "/cert/545acc1c00-certificate.crt" ///< device signed certificate file name
    #define AWS_IOT_PRIVATE_KEY_FILENAME   "/cert/545acc1c00-private.key" ///< Device private key filename
    
    extern void NetWiFi_init();
    extern Display_Handle AWSIOT_display;
    
    
    //*****************************************************************************
    //
    //! mainThread
    //!
    //!  \param  pvParameters
    //!
    //!  \return none
    //!
    //!  \brief Task handler
    //
    //*****************************************************************************
    
    void *manualMainThread(void *arg0)
    {
        int32_t     status = -1;
        _u32 DestinationIP;
        SlSockAddrIn_t Addr;
    
        /* Initialize SimpleLink */
        NetWiFi_init();
    
        status = sl_NetAppDnsGetHostByName(AWS_IOT_MQTT_HOST, strlen(AWS_IOT_MQTT_HOST), &DestinationIP, SL_AF_INET);
        if ( status < 0 ) {
            Display_printf(AWSIOT_display, 0, 0, "sl_NetAppDnsGetHostByName fail: %d\n", status);
            return (NULL);
        }
    
        _i16 sHandle = sl_Socket(SL_AF_INET, SL_SOCK_STREAM, SL_SEC_SOCKET);
        if ( sHandle < 0 ) {
            Display_printf(AWSIOT_display, 0, 0, "sl_Socket fail: %d\n", status);
            return (NULL);
        }
    
        _u8 *pSecMethod;
        pSecMethod = malloc(sizeof(_u8));
        *pSecMethod = SL_SO_SEC_METHOD_SSLv3_TLSV1_2;
    //    *pSecMethod = SL_SO_SEC_METHOD_TLSV1_2;
    
        status = sl_SetSockOpt(sHandle, SL_SOL_SOCKET, SL_SO_SECMETHOD, pSecMethod, sizeof(_u8));
        if ( status < 0 ) {
            Display_printf(AWSIOT_display, 0, 0, "sl_SetSockOpt SL_SO_SECMETHOD fail: %d\n", status);
            return (NULL);
        }
    
        status = sl_SetSockOpt(sHandle, SL_SOL_SOCKET, SL_SO_SECURE_FILES_CA_FILE_NAME,
                   &AWS_IOT_ROOT_CA_FILENAME, strlen(AWS_IOT_ROOT_CA_FILENAME));
        if ( status < 0 ) {
            Display_printf(AWSIOT_display, 0, 0, "sl_SetSockOpt SL_SO_SECURE_FILES_CA_FILE_NAME fail: %d\n", status);
            return (NULL);
        }
    
        status = sl_SetSockOpt(sHandle, SL_SOL_SOCKET, SL_SO_SECURE_FILES_CERTIFICATE_FILE_NAME,
                               &AWS_IOT_CERTIFICATE_FILENAME, strlen(AWS_IOT_CERTIFICATE_FILENAME));
        if ( status < 0 ) {
            Display_printf(AWSIOT_display, 0, 0, "sl_SetSockOpt SL_SO_SECURE_FILES_CERTIFICATE_FILE_NAME fail: %d\n", status);
            return (NULL);
        }
    
        status = sl_SetSockOpt(sHandle, SL_SOL_SOCKET, SL_SO_SECURE_FILES_PRIVATE_KEY_FILE_NAME,
                           &AWS_IOT_PRIVATE_KEY_FILENAME, strlen(AWS_IOT_PRIVATE_KEY_FILENAME));
        if ( status < 0 ) {
            Display_printf(AWSIOT_display, 0, 0, "sl_SetSockOpt SL_SO_SECURE_FILES_PRIVATE_KEY_FILE_NAME fail: %d\n", status);
            return (NULL);
        }
    
        Addr.sin_family = SL_AF_INET;
        Addr.sin_port = sl_Htons(AWS_IOT_MQTT_PORT);
        Addr.sin_addr.s_addr = sl_Htonl(DestinationIP);
    
    // get a -468 here. status = sl_Connect(sHandle, (const SlSockAddr_t *)&Addr, sizeof(Addr)); if ( status < 0 ) { Display_printf(AWSIOT_display, 0, 0, "sl_Connect fail: %d\n", status); return (NULL); } status = sl_Close(sHandle); if ( status < 0 ) { Display_printf(AWSIOT_display, 0, 0, "sl_Close fail: %d\n", status); return (NULL); } Display_printf(AWSIOT_display, 0, 0, "CC3220 has socket success.\n"); return (NULL); }