Obtaining a Certificate for a TLS Context using CSR
You can request a digitally signed certificate from a Certification Authority (CA) for a TLS Context. This process is called a Certificate Signing Request (CSR). Use this method if your organization uses a Public Key Infrastructure (PKI) system.
When you generate a CSR, the device first creates a private-public key pair for the TLS Context, if one doesn't already exist. The private key stays on the device and is never included in the CSR or sent to the CA. The device then builds the CSR itself, which contains the public key along with the identifying information you configure, for example, the Distinguished Name (DN) fields and Subject Alternative Names (SANs), and signs the request using the private key to prove possession of it.
The result is a certificate request, not a certificate. It has no CA signature and isn't trusted by anything until the CA processes it and returns a signed certificate. Once you've received the signed certificate, you need to import back into the same TLS Context.
The CSR process consists of the following stages:
|
●
|
You can generate a CSR for a TLS Context only if ACME-based certificate management is disabled for the TLS Context. |
|
●
|
Because the certificate returned by the CA must match the private key generated with the original CSR, avoid regenerating the CSR for the TLS Context after submitting it to the CA. Doing so creates a new key pair, and importing a certificate signed against the earlier CSR results in a private-key mismatch. |
|
●
|
The certificate replacement process can be repeated whenever necessary (e.g., when the new certificate expires). |
|
●
|
You can also upload the certificate through the device's Automatic Provisioning mechanism, using the [HTTPSCertFileName] parameter. |