RPC Rotate allows the controller to rotate an active certificate on the server. After the rotation is completed, a new certificate can be used without affecting existing TLS connections.
The following cases are supported for a certificate rotation:
server capable of generating a CSR (see Figure: RPC Rotate message flow for CSRs generated on the SR OS node)
server not capable of generating a CSR (see Figure: RPC Rotate message flow when CSRs are not generated on the SR OS node)
The SR OS supports both scenarios, although it is assumed that in most cases the CSR is generated on SR OS node.
The following steps apply to both scenarios:
Generate the CSR.
Sign the CSR by the Certificate Authority (CA).
Load the new certificate on the server.
Verify the new certificate by creating a new connection.
Finalize by confirming that the new certificate is being used.
After the RPC Rotate is completed, all new connections use new keys.
From the perspective of the interaction of the controller and the server (SR OS) two stages are the most important:
message exchange to generate the CSR
message exchange to load the new certificates on the server
Figure: GenerateCSR message flow shows a detailed content of the messages that are exchanged for CSR generation. The SR OS accepts requests only for the X509 certificate type, RSA key type, and a minimum key length of 512 bits.
For RPC Rotate, the certificate_id points to an existing certificate on the node. All the other parameters in the GenerateCSRRequest message are not checked by the SR OS software explicitly. They are used by the internal API to generate the CSR and that result is transparently passed to the controller.
After the CA signs the certificates, the files are loaded to the server using LoadCSRRequest and LoadCSRResponse message exchange, as shown in Figure: LoadCSRRequest/Response message flow. If this message exchange is used in the context of RPC Rotate, the certificate_id should not be present in LoadCSRRequest message. When the SR OS receives the message, it performs all the necessary steps to load this certificate, including storing the certificate and key files on the disk.
The controller is responsible for verifying the connection with the new certificate (Step 4 in Figure: RPC Rotate message flow for CSRs generated on the SR OS node and Figure: RPC Rotate message flow when CSRs are not generated on the SR OS node); SR OS treats this as an optional step.
After the whole RPC is successfully closed, the system can use the new certificate to start new TLS connections.