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.

CC3220SF: SL_ERROR_BSD_ESEC_ASN_NO_SIGNER_E (-688)

Part Number: CC3220SF
Other Parts Discussed in Thread: CC3200

I am attempting to use the AWS IoT Core MQTT using the CC3220SF but seem to have a problem with a missing intermediate CA certificate.

These are my steps:

1. A device was onboarded with Iot Core which provided a Device Certificate and a Device Private Key.
2. The Root CA cert, device cert, and device private key were loaded into the CC3220SF module.
3. When connecting to the MQTT server, the processor reports SL_ERROR_BSD_ESEC_ASN_NO_SIGNER_E (-688) which translates as "ASN no signer to confirm failure". One forum post suggested that "a certificate in the chain could not be verified, likely because the CA programmed in the file system is not the CA that signed the chain."

That makes sense. IoT Core provided the Root CA cert but not the intermediate CA which was used to sign the device cert. Printing the certificate with OpenSSL gives:

    Issuer: OU=Amazon Web Services O=Amazon.com Inc. L=Seattle ST=Washington C=US

Is this likely to be the source of the error?

Where does AWS save their intermediate certificates?

  • Hi Mark,

    What root CA cert are you currently providing to the CC3220? As you figured out, the error you are getting indicates that the root CA cert you are using to connect to AWS is incorrect.

    If you are using an MQTT endpoint secured by Amazon Trust Services (ATS), then the correct root CA to use is the Starfield Class 2 Certificate Authority. If you look at the certificate chain that the ATS endpoint gives you as part of the server hello, you will see that the Amazon Root CA certificate files are actually issued and signed by a couple Starfield certs, which terminates in the Starfield Class 2 Certificate Authority cert as the final issuer in the chain. Thus, the CC3220 NWP expects that Starfield cert to be provided during the startTLS() sequence, and not the Amazon Root CA certificate. The intermediate certs in the chain do not need to be provided, as the server is expected to provide them during the TLS handshake.

    To get the Starfield cert, you can use the link embedded in Amazon's ATS explanation page:
    aws.amazon.com/.../
    It should be linked at the sentence "The certificate can be downloaded from here."

    Let me know if that doesn't resolve your issue or if you have further questions on using AWS with the CC3220.

    Regards,
    Michael
  • Hello Michael,

    I am using "Amazon Root CA 3" which was downloadable from a link provided on the page in the AWS IoT Core page where the thing was onboarded and the device certificate and key were downloaded.  That root certificate is listed in the README for the SDK 2.40 certificate catalog.

    My observation is that although the root should be good, the signer of the device certificate is "AWS IoT Certificate" which I do not have a certificate for.  There is no mention of Starfield in the device certificate.

    To complete the chain of trust, it is necessary to have the certificate of the entity which signed the device certificate.  Correct?

    Mark

  • Hi Mark,

    The error you are seeing, SL_ERROR_BSD_ESEC_ASN_NO_SIGNER_E, has to do with how the CC3220 cannot verify the server's certificate chain. The client certificate will be verified by the server, and you do not need to include any intermediary certs for this process to occur successfully.

    You are correct in that the Amazon Root CAs are included in the latest certificate store provided in the SDK. However, the root cause of the issue that you are seeing is that the certificate chain that the AWS server sends to the CC3220 does not provide a Amazon Root CA that's self-signed. Instead, the Amazon Root CA is signed and marked as issued by a Starfield cert chain which terminates with the Starfield Class 2 Certificate Authority certificate. Thus, the CC3220 will not recognize the Amazon Root CA certificate as a root CA, and will continue upwards in the cert chain to the Starfield certificate when performing cert chain verification.

    Please try providing that Starfield certificate and see if it resolves your issue.

    Regards,
    Michael
  • I have not yet resolved the issue but am understanding it better.  The OpenSSL s_client utility is very helpful.  In my case, it shows this chain:

    Certificate chain
    0 s:/CN=*.iot.us-east-1.amazonaws.com
    i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
    1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
    i:/C=US/O=Amazon/CN=Amazon Root CA 1
    2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
    i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
    3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
    i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority

    It is interesting that the AWS device creation page provides a link to "Amazon Root CA 3" but "Amazon Root CA 1" appears to be needed in the chain.

    Should all of the files be included independently or should that PEM files be concatenated?

  • Hi Mark,

    You only need to include the final Starfield Class 2 Certification Authority certificate, by itself in its own PEM file. The Amazon Root CA certificates should not be included.

    Regards,
    Michael
  • Hello Michael,

    I did include the final Starfield Class 2 Certification Authority certificate, by itself in its own PEM file and still received the NO_SIGNER -688 error. I had concerns about capitalization and spaces in the filename but that does not seem to be an issue. If the filename does not match the cert, regardless of case, a ESECBADCAFILE -456 error is generated so the cert looks right at the CC3220SF level.

    The openssl s_client command worked from Linux with the Starfield Class 2 Certification Authority certificate and the Amazon Root CA 1 so I tried that one too but still get -688. Then I tried them in DER format and still get -688.

    Does this error originate at the CC3220SF or AWS?

    I searched for SL_ERROR_BSD_ESEC_ASN_NO_SIGNER_E in the source and didn't see it (other than the header file definition) .

    There does not seem to be any AWS log activity for the device.

    Mark
  • Hi Mark,

    This error is generated by the CC3220 network processor (NWP). Having no trace of activity in the AWS cloud logs makes sense as the TLS socket to AWS is closed before it can complete the connection process from the client (CC3220) side.

    How are you providing the root CA certificate to the CC3220? Are you using an example from the SimpleLink SDK AWS plugin? Are you using the AWS FreeRTOS SDK? Or are you using your own method to connect to AWS?

    Regards,
    Michael
  • Hello Michael,

    I am using the AT Commands example, SWRU534A, which does work with user/password MQTT which was tested with https://www.cloudmqtt.com/  

    For AWS, the CA certificate is loaded into the CC3220SF filesystem.  It is visible with AT+FileGetFilelist and it is possible to open it and dump the contents which I have done.  The dump contained the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers the the other contents were not verified.

    +filegetfilelist:starfield services root certificate authority - g2,3656,not_failsafe,1

    Also, the code signing works so presumably the procedure for specifying and entering the certificates is correct.  The name used in the filesystem and for the MQTT create command is the certificate name field (CN).  No user/password is specified for the AWS MQTT.

    The AT Commands does meet our needs nicely but I am open to other suggestions.

    Mark

  • Hi Mark,

    It may be possible to connect to AWS IoT using AT commands, but I have not run that successfully before. What is the exact AT command string you are passing to the CC3220 when you are attempting create and connect to AWS?

    One thing to keep in mind is that when you are writing the certificates and private key to the CC3220 filesystem, you need to include the newline characters at the end of each line of the certificate. For example, the root CA cert should have newlines included so that the data looks like this:

    unsigned char root_ca_pem[] =
    "-----BEGIN CERTIFICATE-----\r\n"
    "MIIEDzCCAvegAwIBAgIBADANBgkqhkiG9w0BAQUFADBoMQswCQYDVQQGEwJVUzEl\r\n"
    "MCMGA1UEChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMp\r\n"
    "U3RhcmZpZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDQw\r\n"
    "NjI5MTczOTE2WhcNMzQwNjI5MTczOTE2WjBoMQswCQYDVQQGEwJVUzElMCMGA1UE\r\n"
    "ChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMpU3RhcmZp\r\n"
    "ZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3\r\n"
    "DQEBAQUAA4IBDQAwggEIAoIBAQC3Msj+6XGmBIWtDBFk385N78gDGIc/oav7PKaf\r\n"
    "8MOh2tTYbitTkPskpD6E8J7oX+zlJ0T1KKY/e97gKvDIr1MvnsoFAZMej2YcOadN\r\n"
    "+lq2cwQlZut3f+dZxkqZJRRU6ybH838Z1TBwj6+wRir/resp7defqgSHo9T5iaU0\r\n"
    "X9tDkYI22WY8sbi5gv2cOj4QyDvvBmVmepsZGD3/cVE8MC5fvj13c7JdBmzDI1aa\r\n"
    "K4UmkhynArPkPw2vCHmCuDY96pzTNbO8acr1zJ3o/WSNF4Azbl5KXZnJHoe0nRrA\r\n"
    "1W4TNSNe35tfPe/W93bC6j67eA0cQmdrBNj41tpvi/JEoAGrAgEDo4HFMIHCMB0G\r\n"
    "A1UdDgQWBBS/X7fRzt0fhvRbVazc1xDCDqmI5zCBkgYDVR0jBIGKMIGHgBS/X7fR\r\n"
    "zt0fhvRbVazc1xDCDqmI56FspGowaDELMAkGA1UEBhMCVVMxJTAjBgNVBAoTHFN0\r\n"
    "YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xMjAwBgNVBAsTKVN0YXJmaWVsZCBD\r\n"
    "bGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8w\r\n"
    "DQYJKoZIhvcNAQEFBQADggEBAAWdP4id0ckaVaGsafPzWdqbAYcaT1epoXkJKtv3\r\n"
    "L7IezMdeatiDh6GX70k1PncGQVhiv45YuApnP+yz3SFmH8lU+nLMPUxA2IGvd56D\r\n"
    "eruix/U0F47ZEUD0/CwqTRV/p2JdLiXTAAsgGh1o+Re49L2L7ShZ3U0WixeDyLJl\r\n"
    "xy16paq8U4Zt3VekyvggQQto8PT7dL5WXXp59fkdheMtlb71cZBDzI0fmgAKhynp\r\n"
    "VSJYACPq4xJDKVtHCN2MQWplBqjlIapBtJUhlbl90TSrE9atvNziPTnNvT51cKEY\r\n"
    "WQPJIrSPnNVeKtelttQKbfi3QBFGmh95DmK/D5fs4C8fF5Q=\r\n"
    "-----END CERTIFICATE-----";

    If you do not have those newlines, try adding them and seeing if that helps.

    Other than that, you can also take a look at other methods to connect to AWS using the CC3220. I have written some details on that in my post here:

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

    Regards,

    Michael

  • My PEM file only had newlines without carriage returns. I modified it to to carriage return linefeed and continue to get -688.

    My current command is:

    AT+MqttCreate=,url|sec,a32gt48ilkm22x-ats.iot.us-east-1.amazonaws.com,8883,TLSV1_2,tls_ecdhe_rsa_with_aes_128_gcm_sha256|tls_ecdhe_ecdsa_with_aes_128_gcm_sha256,aws iot key,aws iot certificate,Starfield Services Root Certificate Authority - G2,,v3_1_1,1,0


    ***

    Today I modified the mqtt_client example to use security. It also returns -688. Here are the results:

    ============================================
    MQTT client Example Ver: 1.1.1
    ============================================

    CHIP: 0x31000019
    MAC: 2.0.0.0
    PHY: 2.2.0.6
    NWP: 3.10.0.5
    ROM: 0
    HOST: 3.0.1.46
    MAC address: d4:36:39:ac:7b:7c

    ============================================




    *************************************************
    CC32xx MQTT client Application
    *************************************************



    Device came up in Station mode
    [WLAN EVENT] STA Connected to the AP: sensor_molex , BSSID: c:8d:db:93:4c:48
    [NETAPP EVENT] IP acquired by the device

    Device has connected to sensor_iot
    Device IP Address is 10.189.30.46

    .Connection to broker failed, Error code: -1
    BRIDGE DISCONNECTION

    On-board Client Disconnected

    [SOCK ERROR] an event received on socket 0
    [SOCK ERROR] SSL handshake failed with error -688
    .
    TO Complete - Closing all threads and resources
    Unsubscribed from the topic /Broker/To/cc32xx
    Unsubscribed from the topic /cc3200/ToggleLEDCmdL1
    Unsubscribed from the topic /cc3200/ToggleLEDCmdL2
    Unsubscribed from the topic /cc3200/ToggleLEDCmdL3

    Client Stop completed
  • Hello Michael,

    The AWS plugin did not get detected by CCS but I was able to import the subscribe_publish_sample anyway. It failed with SSL_CONNECTION_ERROR (-4) which implied that the radio actually did communicate with AWS. Out of desperation, I replaced my "Starfield Services Root Certificate Authority - G2" cert with your "Starfield Services Root Certificate Authority" and it worked!

    This doesn't really make sense based on the results of the openssl s_client command:

    Certificate chain
    0 s:/CN=*.iot.us-east-1.amazonaws.com
    i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
    1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
    i:/C=US/O=Amazon/CN=Amazon Root CA 1
    2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
    i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
    3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
    i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority

    It shows "Starfield Services Root Certificate Authority - G2" as the CA. Also the command will succeed with either "Starfield Services Root Certificate Authority - G2" or "Amazon Root CA 1". Another interesting point is that the AWS IoT Core page which provieds the Private Certificate and Private Key has a link to the "Amazon Root CA 3" certificate which *does not* work with openssl s_client which makes sense because it is not in the certificate chain.

    QUESTION: How does an engineer determine the correct certificate to use????

    More information: I tracked down the SSL_CONNECTION_ERROR (-4) and found that it was generated when SlNetSock_startSec() failed but it is *not* the original error code. SlNetSock_startSec() was returning SL_ERROR_BSD_ESEC_ASN_NO_SIGNER_E (-688)!  So that error does not originate with the NWP, it originates with the MQTT server.

    Applying this to the AT Commands example project does result in a change in behavior.  With the CA file that you provided, attempting an MQTT connection now results in SL_ERROR_BSD_ESECDATEERROR (-461).  I have just begun to investigate that but the date was updated prior to attempting the connection.

    Mark

  • Hi Mark,

    Yes, you need to use the Starfield Services Root Certificate Authority as the root CA when using the CC3220 and connecting to AWS. When you look at the cert chain with openssl, the final cert in the chain, the Starfield Services Root Certificate Authority - G2 cert, is not self-signed. Thus, it is not a root CA, nor is it the ultimate root of trust for that certificate chain. The root CA is instead the issuer of the Starfield Services Root Certificate Authority - G2 certificate, which is the Starfield Class 2 Certification Authority cert. As a rule, the top-level certificate must be provided to the CC3220 when connecting over TLS, and this top-level cert must be a root CA (ie, self-signed).
    With some TLS implementations, the device can successfully verify a cert chain as long as one of the certs in the chain is trusted. With those implementations, if the Amazon Root CA was trusted, then cert chain verification would succeed at there and the further Starfield certs on the chain will not be checked. This is not the case for the CC3220.

    The error you are now getting (-461) simply indicates that the date and time of the device needs to be set, so that the CC3220 can verify the expiry date of certificates against its internal time. To do so, you can use SNTP to fetch the network time. There should be an example of this being done in the AWS examples, in the startsntp.c source file. Alternatively, you can use the skip_date_verify flag to skip the cert expiry check entirely.

    Regards,
    Michael
  • I see now that Windows seems to have mislead me. When opening the "Starfield Services Root Certificate Authority - G2" cert, it shows itself in the "Issued to" and "Issued by" fields.

    Currently I am using ClockSync_get() which updates the local time if needed. This updates the unix epoch correctly. Is that not sufficient to set the device time?
  • Hi Mark,

    ClockSync_get() should work in setting the time. As you say, ClockSync_get() will call ClockSync_update() if needed, which ultimately updates the NWP time through a explicit sl_DeviceSet() call.

    To isolate the problem to the time settings of the device, what happens if you use that skip_date_verify flag? If using that flag makes the connection work, then we can assume that the device is not being set to the correct time and then further debug your program.

    Regards,
    Michael
  • Calling ClockSync_get() was not sufficient probably because it does not call setNwpTime().  I copied startsntp.c into the project from the MQTT Pub/Sub project and was able to get connack.  The publish was failing with SL_ERROR_BSD_E2BIG until the retain parameter was changed from 1 to 0.

    Publishing and subscribing to AWS Iot Core is now successful.

    Thank you Michael