And eventually redirected my domain name to my new server.
When I tried to connect to the application, I got a message “Sorry, the server key has changed … etc.” and a button asking me to confirm the new key.
I searched the subject on the forum but got confused. I’m not a cryptography specialist, and don’t understand what is happening. I suppose that it has something to do with these private and public keys that the backup guide asks us to save.
I have a few questions:
Can someone be kind enough to explain me in a simple way what is the role of these server keys?
What is the risk if we lose them.
Taking into account that it’s just a recovery test, is it ok to press the button, or will I have problem afterwards when I’ll come back on my production server (I don’t see how, but I’d like to be sure).
If the restoration of these keys are necessary, How do I restore them in the docker containers?
Before I directly answer them I’ve got a couple links for you though. This page is about rotating the keys(this is in essence what you did) and this page is about moving from one docker install to a new one which is likely the page you’ll want to follow for a full restore instead of the new install plus restoring database.
The role of these keys are to provide security. As you saw you get a warning if they don’t match what is expected. This would reduce the risk of someone impersonating your Passbolt instance as hopefully your users would contact you when they get that to confirm that you did in fact rotate the keys.
If you just lose them as in they are deleted you’d get this warning when you put a new one in/rotate the keys. If you lose them like someone gets a copy of your private key you’d run the risk of someone impersonating your site, so don’t let someone get the private key.
As it is just a test you are likely fine to click that button, but you’ll want to make sure the fingerprint matches. That being said, I’d suggest following the instructions I linked to above about moving from one docker install to a new one to test out that process.
As you see with the warning it isn’t “necessary” but definitely a good idea to restore them. How to do this is included in the moving from one docker to another instructions.
Let me know if anything is unclear in the instructions on the help site or if you need more clarification on anything.
First I would like to wish you a happy new year, to you and to this fantastic Passbolt community !
Thank you for your explanation and for the references. It helped me to successfully complete my restoration work, without any annoying message. I have now a fully operational Passbolt application, with its automated backups and restoration procedure
Remain a few questions regarding the functioning of these gpg keys. It’s just for my education (and maybe for some readers who will read this post :-)):
1 - I understood that the private gpg key, located on the server, is used to check that the application server is the legitimate one. What is still not clear to me is where the public key that should be used at the user level is stored? I think that the server, on the first time a user connects to the application, must send its public key. But where? In the browser? I checked the browser’s local storage and haven’t found anything. Or am I completely wrong in how it works?
2 - The second question regards the restoration of these keys. The restoration guide requests, among other things, to add 2 environment variables to the docker-compose-ce.yaml file (PASSBOLT_GPG_SERVER_KEY_FINGERPRINT and PASSBOLT_KEY_EMAIL). I did that and it works, but I didn’t understand why. What is the purpose of these 2 variables, knowing that the keys are then copied into the container? To identity the keys?
Glad to hear you’ve gotten a fully operational backup and restore procedure set up for your Passbolt instance!
You are correct here, the public key is transmitted on the first connection. It is stored in the browser extension though. This link is to the section of our security white paper that goes over this.
Your assumption here is correct as well. The variables are to identify the correct keys as you could theoretically have more than one in the container/on the server so the application has to have some way to know which to use.
