The Redstor Storage Platform servers use two 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.
You’ll see mention of SNI, as well as the two certificates, on the SSLLabs Security Report for https://api.pro.redstor.com for example.
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. 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. Redstor backup agents contain an embedded (build-time) constant that is the thumbprint of this issuer certificate and will only trust certificates signed by the ‘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 LicenceServer, 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 LicenceServer.
- When the software next checks into the LicenceServer (about once an hour), it gets the signed certificate and starts using it for incoming connections.
Comments
0 comments
Please sign in to leave a comment.