Certificate management
Certificate management refers to the monitoring, processing, and execution of every process in the life cycle of an X.509v3 certificate. A certificate is a digital document that represent a user (customer), client, service, or device. X.509 is the standard format for public certificates.
X.509v3 is an ITU-T standard which consists of a hierarchical system of certificate authorities (CAs) that issue certificates that bind a public key to particular entity’s identification. In the Fabric Services System, an entity can be a client (with access to the Fabric browser, REST client, or Kafka) or nodes (managed or unmanaged). The entity’s identification can be a distinguished name or an alternative name such as FQDN or IP address.
A CA issues a certificate by signing an entity’s public key with its own private key. A CA can issue certificates for an entity as well as for another CA. When a CA certificate is issued by itself (signed by its own private key), this CA is called the root CA. An entity’s certificate can be issued by the root CA or by a subordinate CA (that is, issued by another subordinate CA or root CA). A certificate chain is a certificate that involved multiple CAs.
Role of the Fabric Services System in certificate management
In the Fabric Services System, certificate management includes the issuance, signing, renewal, and deployment of certificates.
- signing certificate: the issuer certificate provided to Cert-Manager and is used by Cert-Manager (an X.509 certificate controller) to sign any certificate request for the northbound interfaces certificate
- northbound server certificates: used to secure communication between the Fabric Services System and clients, such as a browser, the REST API, and Kafka
- node signing certificate: used to sign the gNMI server certificate for each fully managed SR Linux node during the bootstrap of that node. These gNMI server certificates are used to secure communication between the Fabric Services System and managed nodes
- gNMI-to-node certificates: used to secure communication between the gNMI interface of
unmanaged nodes and the Fabric Services System
These certificates are uploaded to the Fabric Services System trust store. Typically, each node has a certificate that was installed by the customer; the certificates are likely generated by the customer's internal certificate-generating service. Only the root certificate that signed all the certificates in each node is uploaded to the Fabric Services System trust store. For related information, see Uploading a customer-generated root CA to the trust store.
- certificate for LDAP service - these certificates are needed for the Keycloak service to
communicate with the LDAP service
For related information, see Configuring LDAP server details. During initial installation, the relevant parameters are trustoreFilename and trustorePassword, as described in
Editing the installation configuration file
in the Fabric Services System Software Installation Guide.
Certificate management during initial installation
- generates a self-signed root CA for signing the server certificates
- generates a self-signed root CA for signing the managed SR Linux node gNMI server certificates
- generates server certificates for all services in Kubernetes that need one
These certificates generated by the system are unique for every installation. By default, the root CAs are valid for 10 years; the northbound server certificates are valid for 365 days. The northbound server certificates are automatically renewed.
For managed nodes, the gNMI server certificates are generated with a 10 year validity and signed by the node signing certificate.
Certificate management after the software installation
The Fabric Services system provides the fss-certificate.sh utility to manage certificates after the initial Fabric Services System software installation.
- for managed nodes, provide their own certificates to replace the certificates generated by the system during initial installation
- for the northbound interface and UI, provide their own CA (root CA or subCA) signing certificate which is used to generate the server certificates
- provide a server certificate for northbound services, including the UI, REST API, and Kafka
- provide their own CA (root CA or subCA) for signing the certificates for managed nodes
- generate a certificate signing request (CSR) for the northbound server certificate or either of the subCA certificates
- trigger the system to replace the root CA and dependent certificates that were created during installation