• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 267 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3230SF: Certificate Expiration Date Check for OTA Code Signing and Root CA

Thomas Schmid1
Intellectual 270 points

Part Number: CC3230SF
Other Parts Discussed in Thread: CC3235SF, SYSCONFIG

Hi TI Support Team,

We are currently working with the CC3230SF in Production Mode and are utilizing the Secure Filesystem for OTA updates.

During our recent testing, we noticed that our custom Vendor/Code Signing Certificate (which is used to sign the ota.cmd manifest and generate te ota.sign file) has expired. However, to our surprise, the CC3230SF still successfully verifies the signature and installs the OTA update without throwing any security alerts.

We found a few older forum posts suggesting that the NWP might ignore the expiration date for code signing purposes to prevent devices from bricking in the field.

Could you please clarify the following points regarding the NWP behavior during OTA and Secure Filesystem operations:

  1. Code Signing Certificate: Does the CC3235SF network processor intentionally ignore the expiration date ("Not After" field) of the Code Signing Certificate when verifying the ota.sign file?

  2. Root CA in Catalog: Does the same logic apply to the Root CA stored inside the Certificate Catalog? If the Root CA expires, will the device still accept signatures derived from it?

  3. Future Behavior: Is it safe to assume we can continue updating our devices in the field with an expired code signing certificate, or are there any plans to enforce expiration dates in future Service Packs / ROM updates?

Having a definitive answer on this will greatly help us in planning our long-term OTA migration strategy.

Thanks in advance for your support!

Regards

Thomas

  • 0
    TI__Genius 9195 points

    Hi Thomas,

    Apologies for the delay here. I do not have a lot of experience in this area but you can try a few things:

    To test if CA certificate expiry is validated, you can use the dummy root CA we have, and you can set the date to something after September 2026 to see if the connection is rejected.

    To test if the OTA certificate expiry is validated, you can use the certificate under the ota-example-cert directory and create a secured OTA download and see if it fails. You'll also need to set a future date from August 2027. 

    From the research I've been able to do, I would expect CA certificate to be validated but maybe not the OTA certificate.

    Let me know if you have any additional questions.

    Best Regards,

    Josh Prushing

  • 0 in reply to Josh Prushing
    Intellectual 270 points

    Hi Josh,

    Thanks for getting back to me and for the suggestions.

    Before trying the dummy CA approach, I actually ran a very practical test on my end to see how the CC3235SF handles date validation.

    I completely blocked outgoing traffic on Port 123 (NTP) in my router to prevent the device from syncing its internal RTC. After that, I freshly flashed the CC3235SF and triggered a secured OTA update.

    The result: The OTA update downloaded and completed successfully without any errors.

    Since the device had absolutely no way to fetch the current time (and likely booted up at a default epoch date well outside the certificate's validity period), this leads me to the conclusion that the device does not strictly validate the expiration (notAfter) or start (notBefore) dates of the certificates during the OTA process, or it simply skips the date check entirely if the internal clock hasn't been synced.

    Does the NWP or the OTA library intentionally bypass date validation if the RTC time is not set?

    Thanks again for your help!

    Best regards,

    Thomas

  • 0 in reply to Thomas Schmid1
    TI__Genius 9195 points

    Hi Thomas,

    In otauser.h there is a #define for OTA_SERVER_AUTH_IGNORE_DATA_TIME_ERROR, I believe this might be why the OTA update is successful. This is later referenced in OtaHttpClient.c, where there is an error that is ignored if this is defined.

    Not sure if your vendor code has this defined, if so, could you comment it out and run your experiment again? 

    Best Regards,

    Josh Prushing

  • 0 in reply to Josh Prushing
    Intellectual 270 points

    Hi Josh,

    Thanks for looking into this and for the great catch regarding OTA_SERVER_AUTH_IGNORE_DATA_TIME_ERROR!

    You are absolutely right that this flag handles the date/time validation for the HTTPS connection to the OTA server. We are actually using the OTA_IF module with our own custom OTA vendor integration, so managing the server authentication is definitely one part of the puzzle.

    However, my main question is actually about the second layer of validation: the signature verification of the MCU image itself by the hardware/Bootloader.

    Once the archive is downloaded, it will be extracted and validates the cryptographic signature of the MCU image against the certificate chain we programmed into the SFLASH via SysConfig (e.g., our GeoTrust/DigiCert certificates). My NTP-blocking test showed that this specific, hardware-level signature verification still passes, even if the device has no valid RTC time.

    Could you please clarify this specific step? Does the internal Bootloader/NWP signature validation (not the HTTPS server auth) intentionally ignore the certificate's notBefore and notAfter expiration dates?

    Thanks again for your continuous support!

    Best regards,

    Thomas

  • +1 in reply to Thomas Schmid1
    TI__Genius 9195 points

    Hi Thomas,

    Thanks for the clarification on what you're looking for!

    It looks like there is no date verification at all in the signature verification. So, you are correct, the internal bootloader does not check the notBefore/notAfter  expiration date in signature validation.

    Let me know if you have any additional questions!

    Best Regards,

    Josh Prushing