7. The device uses its trust anchor (the Cisco root certificate) to validate the ownership voucher. The ownership voucher must be signed by the IOSXE_SZTP private key. The IOSXE_SZTP certificate is signed by a Cisco root, but the trust chain for the voucher must use the IOSXE_SZTP key: any other certificate signed by the Cisco root will fail. Note that only the ownership voucher is validated against the device trust anchor. All other bootstrapping artifacts are validated with the customer's pinned-domain-certificate that is found in the ownership voucher. 8. If the onboarding information includes a requirement for a specific OS version, the device checks the running OS version.
In case of a mismatch, the device downloads and installs the specific version. After the OS installation is complete, the device reboots and the Secure ZTP process restarts. 9. The device starts the Guest Shell after the onboarding information is downloaded from the bootstrap server. Guest Shell is used to run customer-specific scripts, and to apply the downloaded configuration. The configuration can be in Cisco IOS CLI format or in the form of NETCONF edit-config requests. The Guest Shell is shut down after bootstrapping is completed. 10. The device sends progress messages to the server if the server is trusted.
Secure ZTP Transport Protocol Secure ZTP uses HTTPS as the transport protocol when communicating with the RESTCONF bootstrapping servers. When establishing a connection, the device provides its Cisco Secure Unique Device Identifier (SUDI) certificate during the TLS handshake. The certificate serves as an authentication token. No other authentication is supported. The SUDI certificate validates the device on the server side. The bootstrapping server provides its own certificate during the TLS handshake to the device.
If the device has the server-trust anchor corresponding to this server, the device performs an X.509 certificate validation of the server certificate against the server-trust anchor. (The device can get the server-trust anchor from the redirect server.) If the device does have a server-trust anchor, but the X.509 certificate is not validated successfully, the device must discard the server-trust anchor, accept the connection, and mark the server as not trusted. If the device does not have a server-trust anchor, it accepts the server certificate, but marks it as not trusted.
According to the RESTCONF protocol, a device must first initiate the root-resource discovery, before it can proceed with RPC requests. The following is a sample root-discovery request: GET /.well-known/host-meta HTTP/1.1 Host: example.com Accept: application/xrd+xml The following is a sample root-discovery response: HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn xmlns=’http://docs.oasis-open.org/ns/xri/xrd-1.0’> rel=’restconf’ href=’/restconf_root’/> Zero-Touch Provisioning Secure ZTP Transport Protocol Zero-Touch Provisioning 5