Key Rollover vs Certifier rollover
Daniel Nashed – 25 October 2024 10:36:17
This is probably a topic many admins never really looked into and you might still run with your very old 630 key size.
Key size and certificate key size play an important role in your security and you should be aware of it.
Key Rollover
Rolling over keys is a quite normal operation.
It's a best practice to rotate keys at least when the recommended key strength changed.
Rolling over a key is client side initiated but requires an admin action.
When you rollover a key, the old key remains in your notes.id and you can still use it to decrypt existing data.
So it is important to use a key rollover and not just create a new ID!
The key is created by the user or for a server there are settings in the admin tab of the server document when to create a new key.
Once the key has been created, the key needs to be certified by the according Notes certifier.
The signed key is then added to the server document and is picked up by the Notes client or server and merged into the Notes.ID
For Notes clients the client takes care of updating the Notes.ID in ID Vault if configured.
This flow works well without having any physical ID Notes client or server ID in hand.
The certificate chain remains the same and you are just getting a new certificate issued.
Certifier Rollover
When rolling over certifiers you are creating a new key for your certifier and sign it with the right signing ID.
For your organization certifier this will be the organization certifier itself which signs itself.
Once that operation completes you have to re-sign all OU certifiers, server IDs and Notes.IDs step by step in this order.
You also have to take care of all cross certificates, Vault trust certificates.
The process is quite complex and needs planning:
https://help.hcl-software.com/domino/14.0.0/admin/conf_certificateauthoritykeyrollover_t.html
Don't perform Key rollover and certifier rollover at the same time
The most important part is that you should be aware of is that combining both operations are not a good idea.
You should either perform a key rollover or a certifier rollover at any given time.
Combining both could end up in an undesirable state.
Key rollovers are standard operations which are performed on a single client.id or server.id.
They are client driven and might be spread over weeks to avoid all operations starting at the same time.
The client side is triggered by the security policy. For the server side the trigger is the admin tab of the server document.
I just performed a key rollover last night for all my server keys. Which was a very straight forward process.
But it needed a reboot of the server.
Probably I would perform the key rollover first if you have very old server or client.ids.
Then look at your certifier and OU certifiers if you need to also roll them over.
But this needs planning and you should avoid client and server key rollover during that time.
You might also look into your existing trust like cross certificates.
I just cleaned up many old cross certificates last night as a preparation step.
Notes.ID encryption
Another component in security is also important but separate.
Notes.IDs with a password encrypt IDs locally with an encryption standard and a way to hash the password.
The encryption of a Notes.ID locally can be set when you change your password.
But you can also specify the Notes.ID file encryption and hash algorithm used in the security policy.
The most secure option you can select today in your security policy is:
Mandated encryption standard: 256 bit AES and SHA-512
Once set all your Notes.IDs should be changed step by step to this encryption standard.
This doesn't change the content of the Notes.ID, just the local encryption.
- Comments [0]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}