The device then verifies the required serial-number data field. The serial number of the device is learned by the server from the device’s SUDI certificate sent to the server during the TLS handshake. The serial number helps the server to send the right configuration data to the right device. When all the checks are successful, the device extracts the data field pinned-domain-cert , which is the main payload of the ownership voucher. The pinned domain certificate must be Base64 encoded. The device performs a Base64 decoding before handling the certificate. The decoded certificate is an X.509 certificate in DER format.
If an error occurs during validation, the ownership voucher is not verified, and the bootstrapping data is considered invalid. Owner Certificate The owner certificate is an X.509 certificate that binds an owner's identity to a public key, which a device can use to validate a signature in the conveyed information. After verifying the ownership voucher, the device uses the pinned domain certificate extracted from the ownership voucher to validate the owner certificate. The data field in the bootstrapping data that represents the owner certificate is Base64 encoded. The device then performs a Base64 decoding.
The output of this decoding is a degenerate CMS structure, is DER-encoded, and is of the content type signedData. (Degenerate structure is a format that is commonly used to distribute X.509 certificates. These structures do not contain any signatures, but can have attached intermediate certificates.) The owner certificate is an x509 certificate, and the owner certificate artifact is a degenerate CMS structure that carries the x509 certificate. Conveyed Information The conveyed information artifact encodes the essential bootstrapping data for a device. This artifact is used to encode the redirect and onboarding information types.
The final step in validating the signed information is the verification of the signed-CMS structure that contains the conveyed information. The data field for the conveyed information is Base64 encoded. The device first performs Base64 decoding. The device then verifies the signature using the certificates from the owner certificate's CMS structure and the pinned domain certificate as the trust anchor. Image Update Support When the bootstrapping data requires a specific OS version, the device checks the version of the software that it is currently running.
In case of a mismatch, even if the running version is newer, the device uses the URL provided in the bootstrapping data, and downloads the specified image. No modifications are done to the URL, and no additional authentication information is added by the device. If several URLs are specified in the bootstrapping data, the device will loop over the list of URLs until the first successful attempt or until the list is exhausted. After an image is downloaded, if the image-verification data is included in the bootstrapping information, the device uses the specified algorithm to calculate the hash of the image and compares the result with the hash string included in the bootstrapping data.
If multiple algorithms or hashes are provided in the bootstrapping data, the device picks the first-supported algorithm in the list to calculate and compare the hash. After the image is verified, the image is installed, and the device reboots. State information is not stored before the reboot. When the device boots up, it enters the Secure ZTP process again and repeats all the steps till the Zero-Touch Provisioning Owner Certificate Zero-Touch Provisioning 8