Remove hard coded credentials from ansible playbook using conjur

Hello Crew,

I am using a simple ansible playbook to run a command to few managed nodes.ca.

I have installed the ansible conjur collection and securing the private keys from conjur in the playbook below.

Although I have the same root CA on both the controller and on Conjur machines, keep getting the below certification errors - not sure what i am missing here.

Any pointers would greatly help. Thanks in Advance

Hi @senko,
Can you please run the playbook with the ‘-vvvv’ flag and post the full output?
Also, what is the URL that Conjur is running at?
Thank you.

Hey @szh - Thanks, below is the output.

URL is highlighted on the screenshot

Just to clarify i am using conjur nodes as managed(clients) nodes from the ansible controller.

@senko

There are many reasons why the certificate validation could be failing. I would recommend submitting a ticket in our Support Portal so that someone may connect and troubleshoot this on a session.

The Follower certificate could be missing the load balancer FQDN as a SAN, the load balancer could be terminating SSL instead of allowing pass-through, and a few other reasons. If, from the Ansible Controller, you get an error with doing curl -v https://conjurlb.corp...../info it is an issue with the certificate trust in Conjur and needs to be investigated further by Support.

Feel free to also update here with any output, but submitting a Support Case will be the easiest path to solution.

Thanks @joe.garcia . I am not using follower to query the secrets, rather using the VIP. I have only only 1 follower.

Also what should be the ideal value of the env variable - “CONJUR_APPLIANCE_URL” ? should it have the LB VIP of master/standbys or the LB VIP of Followers ?

CONJUR_APPLIANCE_URL should be the URL of where you want to retrieve the secrets from. Since you want to retrieve the secrets from the follower, it will be the VIP of Followers.

1 Like

Hey Guys quick update - I resolved this by disabling the certificate validation. The documentation on the ansible site has a bug - ansible conjur URL

the “validate_certs” parameter accepts only True or False. After i flagged it to False, it worked. Similarly the “as_file” parameter must be set to “True/False” and not yes/no.

FYI below is my playbook with ssh keys fetched from Conjur.

Thanks,
Senthil Kothan

2 Likes

Hi @senko, I want to state that we don’t recommend disabling certificate validation. Doing this is risky and opens you up to a MITM attack.

The issue at hand is that the certificate in /home/azureuser/conjurlbcert.pem is failing to match the cert presented when Ansible hits that https://conjurlb.corp.<snip> address. You can use something like openssl x509 -text -noout -in /home/azureuser/conjurlbcert.pem to inspect the certificate and make sure the names are all correct as Joe mentioned earlier. Depending on how that certificate file was generated, it may include the leaf certificate as well. If so, you could try removing that and leaving just the signing CA chain (root and intermediates) and see if that behaves differently. I hope that helps!

Regards,
Nate

1 Like

Thanks @nathan.whipple . Ofcourse not in production. This is just a POC and and an ephemeral build.
When you say

If so, you could try removing that and leaving just the signing CA chain (root and intermediates) and see if that behaves differently.

Do you mean i should keep only root/intermediate certs on the ansible controller for the variable “CONJUR_CERT_FILE” ?? Doesn’t this should be the actual conjur cert with the LB names with SAN ?

Thanks in Advance,

Hi @senko, yes, you are correct, you would only keep the root/intermediate certificates. The leaf certificate is rarely needed, as very few SSL clients are implemented in a way to perform strict certificate checks. E.g., the leaf certificate and only the leaf certificate can be used for validation in addition to the certificate being signed by a trusted CA rather than the more common check to only see if the certificate was signed by a trusted CA. However, I’ve seen on more than one occasion where strict certificate checking occurs when the leaf is present even though the client doesn’t require it. That is a pretty uncommon edge case, but can cause issues when the leaf certificate that is trusted is different than the leaf certificate that the load balancer presents, even if the CN or SAN names are a match.

1 Like

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