How exactly the OTA agent checks the firmware signature depends on the implementation you use on your IoT devices, so it's ultimately up to you which certificates are involved. Common agent implementations like the one from the AWS IoT Device SDK for Embedded C only use a single certificate to check the signature. They do not build any certificate chains, so it's irrelevant whether the code signing certificate has been issued by a particular CA or is self-signed.

In general, the OTA agent only has to implement the OTA Platform Abstraction Layer (PAL) interface, as explained in the design documentation. The function responsible for the signature check has the type OtaPalCloseFile_t with the following definition:

typedef OtaPalStatus_t(* OtaPalCloseFile_t) (OtaFileContext_t *const pFileContext)

The OtaFileContext_t struct has a pCertFilepath member which is documented as follows:

Pathname of the certificate file used to validate the receive[d] file.

So the interface only specifies that the signature is checked against some certificate. It doesn't say anything about CA certificates. In principle, you could implement a trust store with specific root CAs on your IoT devices and have the agent verify that the code signing certificate has been issued by one of those CAs, but this isn't mandatory.

When you look at the implementation from the C-SDK, you can see that it simply extracts the public key from the certificate located at pCertFilepath (or alternatively a hard-coded certificate in the header file) and checks the firmware signature against this key.

So in the context of OTA updates, the recommendation to purchase a code signing certificate from a well-known CA doesn't make a lot of sense. However, if the updates are obtained through other means (e.g., manually by the user), then having a certificate which has been issued by a trusted CA is definitely recommended.

The recommendation doesn't necessarily apply to OTA updates. It seems to be more about cases where a user is involved (like when a firmware update is installed manually).

How exactly the OTA agent checks the firmware signature depends on the implementation you use on your IoT devices, so it's ultimately up to you which certificates are involved. Common agent implementations like the one from the AWS IoT Device SDK for Embedded C only use a single certificate to check the signature. They do not build any certificate chains, so it's irrelevant whether the code signing certificate has been issued by a particular CA or is self-signed.

In general, the OTA agent only has to implement the OTA Platform Abstraction Layer (PAL) interface, as explained in the design documentation. The function responsible for the signature check has the type OtaPalCloseFile_t with the following definition:

typedef OtaPalStatus_t(* OtaPalCloseFile_t) (OtaFileContext_t *const pFileContext)

The OtaFileContext_t struct has a pCertFilepath member which is documented as follows:

Pathname of the certificate file used to validate the receive[d] file.

So the interface only specifies that the signature is checked against some certificate. It doesn't say anything about CA certificates. In principle, you could implement a trust store with specific root CAs on your IoT devices and have the agent verify that the code signing certificate has been issued by one of those CAs, but this isn't mandatory.

When you look at the implementation from the C-SDK, you can see that it simply extracts the public key from the certificate located at pCertFilepath (or alternatively a hard-coded certificate in the header file) and checks the firmware signature against this key.

So in the context of OTA updates, the recommendation to purchase a code signing certificate from a well-known CA doesn't make a lot of sense. However, if the updates are obtained through other means (e.g., manually by the user), then having a certificate which has been issued by a trusted CA is definitely recommended.

How exactly the OTA agent checks the firmware signature depends on the implementation you use on your IoT devices, so it's ultimately up to you which certificates are involved. Common agent implementations like the one from the AWS IoT Device SDK for Embedded C only use a single certificate to check the signature. They do not build any certificate chains, so it's irrelevant whether the code signing certificate has been issued by a particular CA or is self-signed.

In general, the OTA agent only has to implement the OTA Platform Abstraction Layer (PAL) interface, as explained in the design documentation. The function responsible for the signature check has the type OtaPalCloseFile_t with the following definition:

typedef OtaPalStatus_t(* OtaPalCloseFile_t) (OtaFileContext_t *const pFileContext)

The OtaFileContext_t struct has a pCertFilepath member which is documented as follows:

Pathname of the certificate file used to validate the receive[d] file.

So the interface only specifies that the signature is checked against some certificate. It doesn't say anything about CA certificates. In principle, you could implement a trust store with specific root CAs on your IoT devices and have the agent verify that the code signing certificate has been issued by one of those CAs, but this isn't mandatory.

When you look at the implementation from the C-SDK, you can see that it simply extracts the public key from the certificate located at pCertFilepath (or alternatively a hard-coded certificate in the header file) and checks the firmware signature against this key.

How exactly the OTA agent checks the firmware signature depends on the implementation you use on your IoT devices, so it's ultimately up to you which certificates are involved. Common agent implementations like the one from the AWS IoT Device SDK for Embedded C only use a single certificate to check the signature. They do not build any certificate chains, so it's irrelevant whether the code signing certificate has been issued by a particular CA or is self-signed.

In general, the OTA agent only has to implement the OTA Platform Abstraction Layer (PAL) interface, as explained in the design documentation. The function responsible for the signature check has the type OtaPalCloseFile_t with the following definition:

typedef OtaPalStatus_t(* OtaPalCloseFile_t) (OtaFileContext_t *const pFileContext)

The OtaFileContext_t struct has a pCertFilepath member which is documented as follows:

Pathname of the certificate file used to validate the receive[d] file.

So the interface only specifies that the signature is checked against some certificate. It doesn't say anything about CA certificates. In principle, you could implement a trust store with specific root CAs on your IoT devices and have the agent verify that the code signing certificate has been issued by one of those CAs, but this isn't mandatory.

When you look at the implementation from the C-SDK, you can see that it simply extracts the public key from the certificate located at pCertFilepath (or alternatively a hard-coded certificate in the header file) and checks the firmware signature against this key.

So in the context of OTA updates, the recommendation to purchase a code signing certificate from a well-known CA doesn't make a lot of sense. However, if the updates are obtained through other means (e.g., manually by the user), then having a certificate which has been issued by a trusted CA is definitely recommended.