Seeding for follower fails - "root key not present"

Hello - When i tried to seed the files from Leader for the follower nodes, i get the below error.

error: root key not present.

Seeding on the standby worked successfully and standbys are configured with no issues. Not sure what went wrong for the followers. What does the root key mean here ?

We made sure we copied all the cers/keys for the cluster as well as the followers during the cluster configuration.

Any thoughts ?

Thanks

Hi @senko ,

The error “root key not present” is related to the behavior for evoke when generating a seed file. I’ll explain this first, then provide a recommendation to address your challenge.

When importing a certificate with the evoke ca import command, evoke will read the CN from the certificate subject and store the certificate in the /opt/conjur/etc/ssl directory with <CN_from_subject>.pem as the file name. Lets assume my certificate CN is follower.nate.lab.

When generating a follower seed file with the command evoke seed follower follower.nate.lab leader.nate.lab, evoke will first look for a certificate file /opt/conjur/etc/ssl/follower.nate.lab.pem. If a file of that name is found, evoke then checks in that certificate to verify that the FQDN follower.nate.lab is in the subject or list of subject alternate names (SAN) in that certificate. In the event that both conditions are true, a seed file is generated with this certificate contained within. If either condition fails, evoke attempts to issue a new certificate for the name provided in the evoke seed follower command. This works in a self-signed certificate scenario, but as you are using certificates signed by an external CA the private key necessary for signing the certificate is no longer present on the Conjur server and thus the error “root key not present” is thrown.

The easiest step to resolution for you would be to issue a follower seed file using the CN name from the certificate subject. (use openssl x509 -text -noout -in certificate_filename to see this if you’re not sure) Alternatively, if you wished to issue a follower seed using a name only found in the SAN list of the certificate, then you can create a copy of both the certificate and it’s private key using the name found in the SAN. For example, I want to use the FQDN read-only.nate.lab for my follower seed and this name is only found the SAN of my certificate. The CN of the certificate subject is follower.nate.lab I could do something like:
docker exec conjur cp /opt/conjur/etc/ssl/follower.nate.lab.pem /opt/conjur/etc/ssl/read-only.nate.lab.pem
I need to also copy the key:
docker exec conjur cp /opt/conjur/etc/ssl/follower.nate.lab.key /opt/conjur/etc/ssl/read-only.nate.lab.key

Once that has been done, I can issue a follower seed:
docker exec conjur evoke seed follower read-only.nate.lab leader.nate.lab > /tmp/read-only_seed.zip

I hope that clears things up for you and gets you sorted out. Please let me know if further clarification is needed on any of this.

Regards,
Nate

2 Likes

@nathan.whipple … you are the best Nathan !! Thanks Much. Although this worked, just curious how this same command worked for standby, also when i checked the UI dashboard for Conjur cluster, i was able to see the node address for standbys but followers we were able to see only the load balancer address and IP address instead of the actual followers, is that normal - Thanks

Hi @senko

The evoke behavior when generating a standby seed is to use the certificate that is sym linked to /opt/conjur/etc/ssl/conjur.pem. In this scenario, the additional checks are not performed. As for the behavior you note in the cluster page of the UI, this is expected behavior. To obtain the IP of the actual follower you need to add your load balancer to the trusted_proxies on the leader and the load balancer must preserve the client IP (e.g. its a transparent proxy). Please see Trusted proxy requirements for more details.

Regards,
Nate

1 Like

That helps. Thanks Nate for all the help to the community.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.