You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 9, 2024. It is now read-only.
##Bug description
h2. Is your feature request related to a problem? Please describe.
The CLI supports 2 certificate flows 1. signed 2. self-signed certificates. Self-signed cert flow - The current flow we have for initializing the client is ok and referred to as certificate pinning or trust on first use. In this flow, we save the certificate on the machine after accepting the fingerprint and each follow-up request requires us to send the pem.
Signed cert flow - For all requests, we must validate the certificate chain, the certificate hostname, etc and this is done in Python terms via verify=True . In this flow, we don’t need to save the certificate on the machine because the server sends the cert on each client request and we immediately verify it against the CA bundles that exist on the machine.
Even though we don't need to save the pem on the machine in this flow we still do to abstract away the implementation details from the user and keep the UX uniform.
We should reevaluate this because currently for both these flows, we save the certificate on the machine and ask them to verify the fingerprint (pining) even though for the CA signed cert, we don't use it.
h3. Proposed flow
Open socket with Conjur on {{init}}
Fetch the certificate
Evaluate if self-signed or signed by comparing if issuer == subject
If so, self-signed. If not, signed
a. If self-signed save the pem on the machine and update the conjurrc with the path
b. If signed don't save the pem on the machine and update the cert_file to '' / signed
##Bug description
h2. Is your feature request related to a problem? Please describe.
The CLI supports 2 certificate flows 1. signed 2. self-signed certificates.
Self-signed cert flow - The current flow we have for initializing the client is ok and referred to as certificate pinning or trust on first use. In this flow, we save the certificate on the machine after accepting the fingerprint and each follow-up request requires us to send the pem.
Signed cert flow - For all requests, we must validate the certificate chain, the certificate hostname, etc and this is done in Python terms via verify=True . In this flow, we don’t need to save the certificate on the machine because the server sends the cert on each client request and we immediately verify it against the CA bundles that exist on the machine.
Even though we don't need to save the pem on the machine in this flow we still do to abstract away the implementation details from the user and keep the UX uniform.
We should reevaluate this because currently for both these flows, we save the certificate on the machine and ask them to verify the fingerprint (pining) even though for the CA signed cert, we don't use it.
h3. Proposed flow
Open socket with Conjur on {{init}}
Fetch the certificate
Evaluate if self-signed or signed by comparing if issuer == subject
If so, self-signed. If not, signed
a. If self-signed save the pem on the machine and update the conjurrc with the path
b. If signed don't save the pem on the machine and update the cert_file to '' / signed
{{.conjurrc}} for self-signed
{code:java}
---
account: cucumber
appliance_url: https://conjur-server
cert_file: /Users/ssax/conjur-server.pem
plugins: []
{code}
{{.conjurrc}}
for signed
{code:java}
---
account: cucumber
appliance_url: https://conjur-server
cert_file: ''
plugins: []}}
h3. Implementation details
{code}
{{cert_file}} should only tell you the path to a CA certificate to verify peer against (SSL)
{{cert_file}} has a value. verify=cert_file
{{cert_file}} has no value. verify=True .
You want verify=False and so you run conjur --insecure …
##Found in version
12.1
##Workaround Complexity
No workaround
##Workaround Description
##Affects Version/s
##Link to JIRA bug
ONYX-10491
The text was updated successfully, but these errors were encountered: