The Redstor Storage Platform servers use 2 certificates for incoming TLS connections.
The server decides which certificate to use for an incoming connection based on the Server Name Indication (SNI) header sent by browsers (and some other tools) in the initial TLS handshake packet.
The first is used when a browser connects to the server, and is a normal, browser-trusted certificate issued by DigiCert:
The second certificate is used when a Redstor backup agent (or another tool that doesn’t support SNI) connects to the server:
You’ll notice that the ‘Issued to’ and ‘Issued by’ fields are not the same, and the ‘Authority Key Identifier’ references a different certificate, and thus the certificate is not self-signed.
The certificates are in fact signed by the ‘Attix5 root’ certificate, which is the certificate of Redstor's internal CA server. The Redstor backup agents contain an embedded (build-time) constant that is the thumbprint of this issuer certificate and will only trust certificates signed by this ‘Attix5 root’ certificate. This is termed "certificate pinning".
These Redstor-CA-issued certificates have a lifetime as follows:
- When the software is initially installed, it generates a new, random, secure private key and a certificate signing request (CSR).
- This CSR is uploaded by the software to the Redstor Licence Server, which validates that the software is correctly licenced and activated.
- After validation, the CA certificate is used to sign the CSR with a validity until one month after the activation expires. This is typically about a year.
- The signed certificate is uploaded to the Licence Server.
- When the software next checks into the Licence Server (about once an hour), it gets the signed certificate and starts using it for incoming connections.