Version 4 (modified by chris, 3 months ago) (diff)


Replacing Certificates

Certificates in Box Backup

Certificates ensure the security of the Box Backup server (bbstored) against malicious clients connecting, which could damage existing backups, prevent new backups from occurring, and waste CPU time and disk space on the server. Certificates and their keys are not used to encrypt client data at rest.

They also allow the client (bbackupd) to verify that it is connecting to the correct server, not an imposter, who could not decrypt the encrypted data, but could substitute bad data instead, or delete existing backups.

Box Backup uses X.509 certificates, which are generated on the server and clients. They are signed by a Certificate Authority (CA), usually a private (free) one created by the included scripts, which should be kept on a separate machine to all servers and clients, strongly protected from the Internet, and with an encrypted disk.

When to replace

Certificates can and sometimes must be changed, for example:

  • Every certificate has a built-in expiry date, which cannot be changed. Box Backup's certificates normally expire in the year 2038 for server certificates, and 5000 days (13 years) for client certificates.
  • If a client or server is compromised, it needs a new certificate.
  • If the CA is compromised, a new one should be created (on a fresh, secure box) and all certificates generated by the old one and still in use should be replaced. (This is a pain, which is why you should keep the CA really secure, to avoid the need to do this.)
  • Ever-increasing processor speeds and cryptographic techniques make it easier to crack encryption with shorter keys. Therefore the recommended key lengths increase too. At some point an old certificate will no longer be secure against a well-funded adversary, and should be replaced with a new one that uses a longer key.

Debian Security Level Update

Sometimes the developers of software that we use (e.g. OpenSSL, Debian) decide that the previous standard encryption key length or algorithm is no longer enough, and should be considered insecure from now on. This is usually because of advances in computing power, but could also happen if a weakness is discovered in a cryptographic algorithm. It is a subjective decision based on the estimated time, cost and energy of breaking the encryption on data using that key length or algorithm dropping below an arbitrary threshold.

Debian made such a decision when deploying OpenSSL 1.1.1, which is currently only in Debian Unstable (as of January 2019). Because the minimum RSA key length is now 2048 bits, and all keys generated by previous versions are 1024 bits long, you will encounter the following errors:

  • Server and client fail to start, with the error TLSLoadCertificatesFailed: SSL or crypto error: loading certificates from testfiles/clientCerts.pem: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small.
  • Test/basicserver and other tests that use bbstored will fail because of this.

Before (an unreleased version) it was not possible to configure the cipher strength specifically in Box Backup, without modifying the source and recompiling. It now is possible, but also, older versions can still use certificates and keys generated by this version and later, which are also compatible with Debian's new stricter security level. Therefore we recommend that you at least use this version (or later) to generate new CA, server and client certificates for the affected system(s) and any that they connect to.

This may require you to replace the CA certificate on all clients.

You can work around this by editing /etc/ssl/openssl.cnf and finding the following section (at the end of the file):

MinProtocol = TLSv1.2
CipherString = [email protected]=2

and changing SECLEVEL=2 to SECLEVEL=1. However you would be going against Debian's recommendations by doing this, and it also affects (reduces the security level of) the whole system, not just Box Backup. The different security levels of OpenSSL are defined here.

Consequences of replacing

Certificates themselves are public, not secret. Every certificate is linked to a private key (e.g. an RSA key) which provides its security. Many certificates can be generated using the same key. If the key is compromised, then a new one must be generated, and any certificates which refer to the old key must be revoked and discarded, to regain security of the system.

It is often technically possible to generate a new certificate while reusing the old key. However this is usually not a good idea because:

  • If the key is compromised, the new certificate is too, and security is not regained by just replacing the certificate.
  • Even if you think that the key has not been compromised, it may have been without your knowledge, and generating a new key would limit the damage.
  • An opportunity to increase the key length, and hence the security of the key, is missed.

Therefore we recommend always generating a new key. The supplied scripts (such as bbstored-certs) make this easy.

Replacing this key does not invalidate existing backups, since they are encrypted with different key which is not usually replaced. But it does mean that the certificate and key files will need to be replaced on all clients and servers which use that certificate.

In the case of a single server or client certificate, only that server or client needs to be reconfigured to use the new key. Other servers and clients use the CA's signature to determine whether to trust each other, and new certificates are required to be signed by a recognised CA.

If the CA key is compromised, then the attacker can create new certificates with valid signatures at will, and no amount of revoking existing certificates will protect you. At this point it is necessary to discard the old CA and generate a new one, with new certificates. All client and server certificates will need to be replaced, or at least resigned by the new CA. This is a pain, which is why you should keep the CA really secure, to avoid the need to do this.

How to replace

To actually generate new certificates, upgrade the version of Box Backup on your CA (at least) to (unreleased version) and then follow the Certificates and Account Management instructions to create a new CA, and new certificates for the server(s) and client(s). You can generate all the certificates and keys on the CA, you don't need to upgrade all the servers and clients just so that they can generate the new, stronger certificates.