Hello Devin, 2015-11-19 0:17 GMT+01:00 Devin Reade <g...@gno.org>: > My alerting system tells me that I have some file daemons that have been > merrily encrypting their data for quite a while. In particular, the > expiry dates for the data encryption x509 certs are coming up soon.
You can renew your certs. I think that way described on the following link should be sufficient: http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x195.html#AEN215 > Well, this brings up an interesting question that I'd not really > considered in depth: Given that you can only specify two keys > in the bacula-fd.conf file, what is the best strategy during key > rollover? That is, that time period after making a new client > keypair available, and the retention time of the backups that were > made with the old keypair? I think that important is understand that data stored by Bacula is not encrypted by ANY from public keys. Data is encrypted (symetric) by session keys and these session keys are stored on Bacula volumes in (asymetric) encrypted (by public keys) form. So data encryption in Bacula uses session keys stored in encrypted ASN.1 standard structure. In short it means that you are able to decrypt session key not by only ONE key, but by Client private key and private Master Key. Some time ago I prepared a few diagrams that show Bacula data encryption algorighm. Here are the diagrams in English version: http://www.bacula.pl/data_encryption.html > First off, I think that the master key specification doesn't enter > the picture; there is still a need for encrypting with the master > public key, for the usual reasons. > > The first section of the data encryption chapter says to not change > the location of the client keypair. Fair enough. This implies that > the new keypair should be used to overwrite the old. That's great > for performing backups, but what about doing restores? You can do restore as long as you have private Master Key, because in this case for decrypt session keys from volumes there is used private Master Key as only one valid. Of course, you have to provide the private Master Key to your Client. I hope that it helps. Best regards. Marcin Haba (gani) > I suspect the answer is: > 1. Save a copy of the old keypair (presumably there are copies > offline already, but best to be explicit) > 2. Overwrite the old client keypair with the new keypair. > 3. Resume backup operations. > 4. If you have to restore data from a time after the key replacement, > then it's business as usual. > 5. If you have to restore data from a time prior to the key replacement, > then you need to copy the old keypair over top of the new, > (presumably) restart the file daemon, perform the restore, > copy the new keypair back on top of the old, restart the file daemon, > and then continue with normal operations again. > > This implies that you also need to keep track of what the flag day > is when you change the certificate for a given client. (Although this > may be recorded in your certificate maintenance system, if any.) > > Does anyone have a better procedure? > > Devin > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- "Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie za przyjaciół swoich." Jezus Chrystus ------------------------------------------------------------------------------ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
