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.

CC3235SF: Not Authorized when using Intermediate CA outside of Cert Catalog

Part Number: CC3235SF
Other Parts Discussed in Thread: UNIFLASH


I'm using a Self-Signed Root CA to issue Vendor/Leaf Certificates to connect devices to an IOT-hub on Azure. To improve the security, I want to add an Intermediate CA that can be switched out if necessary. From my understanding, only the Root CA needs to be in the Cert Catalog (in DER format, without extension, and with its name exactly as its "issued to" field).

Since I have already locked the OTP, I simply tried adding the InterCA to the file system and installed it on the server. This returned: "Connection Not Accepted: 0x5: Not Authorized". When I tried the Dummy Certs, it only worked with a Dummy Intermediate Cert. Which leads me to think that the Intermediate Cert also need to be in the Catalog.

Is this the case? If so, then switching them out will not be possible. Or am I missing something here?

Would love some help here, thanks in advance!

Kind Regards


  • Intermediate certificate don't need to be in the catalog. Only the root CA should be included. But both files should be available on the device file system (with names that is exactly as their common name, without any extension).

    The intermeidate should be signed by the Self-Signed Root CA (so the name of the "issued by" will be the common name of the root ca).

    The catalog doesn't contain the full content of the certificate but only its digest. Thus the root ca still need to on the file system.

    I'm not sure  what is the source of "0x5: Not Authorized" (is it from the Azure SDK?) - if you can provide the return code from the SL API (sl_Connect, or sl_StartTLS) that triggered the error - I'll be able to further assist in finding the root cause.

  • Yes, this is from the Azure SDK. I could not find "sl_Connect" or "sl_StartTLS", we use the "tlsio_sl_open" from "tlsio_sl.c" in the Azure SDK. Are the functions you mention called before or after this? 

    Here is the entire error message (minus the username and such)

    -> 10:40:17 CONNECT | VER: 4 | KEEPALIVE: 60 | FLAGS: 128 | USERNAME: -----------------&DeviceClientType=iothubclient---------------- | CLEAN: 0
    <- 10:40:17 CONNACK | SESSION_PRESENT: false | RETURN_CODE: 0x5
    Error: File:../../sdk/iothub_client/src/iothubtransport_mqtt_common.c Func:mqtt_operation_complete_callback Line:1749
    Connection Not Accepted: 0x5: Not Authorized

  • in tlsio_sl_open - you can find the call to SlNetSock_startSec.

    Please print the return code of this function.

  • This returns -468: "SLNETERR_ESEC_UNKNOWN_ROOT_CA", which was turned off as it is only a warning if I understand correctly. The Software-Signing Cert and the Intermediate CA are both created from the same Root CA, and the connection works fine when the Leaf Cert is issued directly by the Root. 

    Is the -468 given for all self-signed Root CA's? Or does this mean the device cannot find the chain from the Leaf -> Intermediate -> Root?

  • I did a test, and yes, even when we issue the Leaf directly from the Root we do get the same -468 error code. So it seems like this is not the issue (since it connects just fine) and that using self-signed roots always gives this warning. 

  • -468 means you are not providing the right server root CA (Server's certificate was not signed by the provided root CA). 

    To see the root CA required by the server, please refer to chapter 2.5.1 "Finding a Server’s Root CA" in the certificate handling guide.

  • I found the problem, we had installed an old Intermediate CA on the server so the Leaf/Vendor Cert could not be authenticated properly. There was also a problem with the way I created my Intermediate CA. It had "basicConstraints=CA:true" active but was missing the "keyUsage=keyCertSign". It was therefor not allowed to sign certificates, which led to a failed validation of the chain.

    This was difficult to spot, use "openssl verify -CAfile PathToRootCA.pem -untrusted  PathToCA.pem  PathToCert.pem" to check. 

    Once we created new ones (that matched) and installed them on the server it worked just fine. 

    It is still kind of weird that we get -468 even with the correct Baltimore Cert. Do you know why the error is given despite having a working connection? Just want to make sure that we don't have to change things later on.

    Kind regards

  • it means that the certificate is not included in the installed certificate catalog (are you using the dummy "PlayGround" catalog?).

    The TI formal catalog contains the "Baltimore CyberTrust Root" - if you are using different certificate or the dummy catalog - you will get this warning (-468) but the connection will still get open. you can ignore the return code or disable the catalog verification (see SL_SO_SECURE_DISABLE_CERTIFICATE_STORE or SLNETSOCK_SEC_ATTRIB_DISABLE_CERT_STORE socket option).if you are using the mqtt from the SDK you can set the MQTTCLIENT_NETCONN_SKIP_CERTIFICATE_CATALOG_VERIFICATIONto the netconnFlags (in MQTTClient_ConnParams).

    In the MQTT example for example we are setting:


  • (We have a custom catalog already locked into the OTP, but I try new things out with the dummy catalog and dummy certs sometimes)

    Okay, that makes much more sense. Azure is switching out its Baltimore Root CA to a DigiCert Global Root CA. We have not yet added the Baltimore to the catalog, and I have seen that there are ways of changing the catalog (adding/removing certs later). But the OTP contains a signature of the initial catalog. How can the catalog be changed if the OTP cannot be reprogrammed? For example, to add the Baltimore CA, do I need to make a new "otp.inf" and a new catalog signature? Or are thous things handled automatically?

  • the OTP only contains the "self-signed" certificate to verify the catalog signature, The catalog is just a file signed by this key.

    The new catalog just needs to be signed with the relative private key. 

    If you are using the TI OTA library, you can use the uniflash or CCS to create an OTA Image with the catalog you want to replace. or you can just overwrite the

    "/sys/certstore.lst" file.
  • Ahh, okay. Thanks for the clarification!