I have a question for you guys. Does it make sense to store certificates and rotate them on Conjur?
I’m not talking about Conjur’s own certificate, it is certificates used for other applications.
The reason of this question is that I’ll probably have to implement the Rotator using kind of access/retrieve of the certificate from the CA and then use it to generate a new one for the child ones. And more, for the target service to actually update the certificate I’ll have to shut down the process, replace the file and turn on again (which I’m not sure if it will be possible with the Rotator implementation inside of Conjur OSS).
So, I want to know the opinion on that of you guys.
Thanks!!
I think certificate storage and rotation is a perfectly valid use-case for your Conjur deployment. It is true that you would need to implement a new rotator. Here is a link to the design documentation for rotators, https://github.com/cyberark/conjur/blob/master/design/ROTATORS.md. The interface is relatively simple and focuses on allowing the implementer to do some work to generate new credential values, update the stored values and update the values in the usage system. As far as I know there’s no requirement for the update of values in the usage system to be synchronous… which is to say cert rotation can work with a sort of eventual consistency.
which I’m not sure if it will be possible with the Rotator implementation inside of Conjur OSS
I think it’s possible to have a rotator that can set off a myriad of side-effects but they don’t have to take place in Conjur. The rotator could just kick-off the process by sending a message to some other system that you control, then that system can execute arbitrary logic. I can imagine the message passing being done using a durable queue, which means once a message is on the queue there’s extremely high likelihood that the values on the usage system will be updated soon.
Let me know if any of that^ helps. Happy to continue the conversation and figure out some approach that might work for you.