Created attachment 1272956 [details]
Description of problem:
When selecting SSL trusting custom CA as a Security Protocol option and feeding it an incorrect certificate the validation passes successfully
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Go to Compute --> Containers --> Providers
2. Select Configuration --> Add Existing Provider
3. Add provider's name/hostname/port/token and select SSL trusting custom CA as the option for Sec Protocol
4. In Trusted CA Certificates text area add a correctly formatted but incorrect custom certificate (example attached)
5. Try to validate and add the provider
The validation works and the provider is added successfully
The validation should fail
Attached a correctly formatted yet incorrect custom certificate.
Created attachment 1272957 [details]
Wrong Cert log
Unable to reproduce: I added an OCP provider using the BadCertificate.crt in attachment and the error is: "Credential validation was not successful: HTTP status code , SSL_connect returned=1 errno=0 state=error: certificate verify failed"
Assigning to Beni for further investigation.
Assigning to beni per comment 3.
Beni I believe this is a duplicate of another bug you mentioned?
I can reproduce. You can't try attached cert on any provider (that's caught correctly), need to take correct cert and modify its end a little.
Example of cert mutation (including `openssl x509 -text` diff) on my provider vm-48-131.eng.lab.tlv.redhat.com:
I'm getting »Credential validation was successful«
I'm not sure it's a security bug.
The cert I tell CFME to trust differs from CA's real root in its self-signature. Nobody really cares (?) how a self-singing cert signs itself, only that the openshift cert is still signed by it, which it is.
- `oc login --oc login --certificate-authority=ca.crt.bad` connects happily with such cert (and I can use commands like `oc status`, no complaints)!
- Curl refuses:
curl: (35) You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert.
Kurt - can you help us figure out if I got this right, and if Ruby trusting such modified CA cert is a problem?
See email thread, but in short:
this appears to be hardening, but we want to make sure there isn't some way to abuse this.
oh also this may also be a flaw/issue/hardening upstream in Ruby on Rails, once we know a bit more I'll rope them in if needed.
Not in Rails, perhaps ruby's OpenSSL lib (seems to ship with ruby as well as separate gem, not sure of the relation)
I'd like to close as NOTABUG for CFME.
To repeat, the CFME scenario is:
- A private CA with self-signed root cert R
issued a cert P for say myopenshift.example.com.
- A user adds myopenshift.example.com as a CFME provider, telling CFME to trust
certs signed by R', where R' is R with a typo.
The typo is in the self-signing part of R (R'.signature != R.signature);
crucially the chain is still valid:
- P.issuer == R'.subject == R.subject
- P.signature can be verified by R'.public_key == R.public_key
- CFME trusts myopenshift.example.com that presents P.
Kurt, is there a better place to track this (*if* there is anything to track)?
My conclusions reading RFC 3280: https://security.stackexchange.com/a/162244
I'm going to bring this up with ruby on rails, sorry for going awol (stackguard is done! yippeee!). Can I share all the details with upstream?
(In reply to Kurt Seifried from comment #11)
> Can I share all the details with upstream?
Closing this for now.