Red Hat Bugzilla – Bug 1255621
[setup] openldap does not recognize system certificates
Last modified: 2016-02-18 06:09:59 EST
Description of problem: ovirt-engine-extension-aaa-ldap-setup can't recognize system certificates Version-Release number of selected component (if applicable): ovirt-engine-extension-aaa-ldap-setup-1.1.0-0.0.master.el6ev.noarch RHEV 3.6.0-10 How reproducible: always Steps to Reproduce: 1. get RH CA cert trusted: wget -O /etc/pki/ca-trust/source/anchors/rh_ca_2009.pem https://password.corp.redhat.com/newca.crt update-ca-trust enable update-ca-trust 2. run ovirt-engine-extension-aaa-ldap-setup with: * Please specify user visible profile name: redhat.com * LDAP implementation: 11 - RHDS RFC-2307 Schema * Use DNS: yes * Available policy method: 2 - DNS domain LDAP SRV record * Please enter DNS domain: redhat.com * Please select protocol to use: startTLS or ldaps, doesn't matter * Please select method to obtain PEM encoded CA certificate (File, URL, Inline, System): System Actual results: [ INFO ] Resolving SRV record 'redhat.com' [ INFO ] Connecting to LDAP using 'ldap://first-server.redhat.com:389' [ INFO ] Executing startTLS [WARNING] Cannot connect using 'ldap://first-server.redhat.com:389': {'info': "TLS error -8172:Peer's certificate issuer has been mar ked as not trusted by the user.", 'desc': 'Connect error'} Expected results: connection works just fine Additional info: problem affects only -setup command, the extension itself works correctly when using config files directly - with aaa/profile1.properties containing startTLS without trustore specification, e.g.: include = <rfc2307.properties> vars.domain = redhat.com pool.default.serverset.type = srvrecord pool.default.serverset.srvrecord.domain = ${global:vars.domain} pool.default.ssl.startTLS = true
the problem is that the openldap and java probably use different stores, this was expected, unless there is something else wrong, will check.
this is a bug in either update-ca-trust or openldap port to rhel. openldap is reading /etc/openldap/cacerts directory for system ca trust. it is openssl cadir put x.pem and # ln -s x.pem $(openssl x509 -in a1.pem -noout -hash).0 notice the /etc/openldap/ldap.conf that refer to this directory explicitly. for some reason the update-ca-trust does not create openssl cadir anywhere but single ca bundle /etc/pki/tls/certs/ca-bundle.crt as a result, default ldap configuration file should be contain the following to integrate with rhel store: TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt workaround: set the following environment variable when running setup: LDAPTLS_CACERT=/etc/pki/tls/certs/ca-bundle.crt using system store is highly not recommended anyway. will open a separate bug against openldap.
(In reply to Alon Bar-Lev from comment #2) > this is a bug in either update-ca-trust or openldap port to rhel. > > openldap is reading /etc/openldap/cacerts directory for system ca trust. > I looked what the situation is and it seems that this is just a word collision here. From openldap perspective, "system" means what in /etc/openldap/certs, which is quite a narrow meaning after advent of Shared System Certificates architecture. There is a good reason however to keep this trust tighter than system default - limit the ability to provide identities to a single entity (OTOH blacklist/distrust support in shared system certificates is also nice here especially in larger deployments). You also implemented at my suggestion RFE to use Shared System Certificates by default (to be used when no cert store is specified in aaa/PROFILE.properties file) so I'd incline to understand System as Shared System Certs (because Java settings will take place by default during engine operation, not openldap ones IIUC). Finally (and a bit sideways), I don't intuitively like auto-conversion of .pem file supplied to -setup command to .jks store. Wouldn't it be better to include .pem file location in PROFILE.properties file and convert it to .jks file in /var or /run on engine startup? I'd expect engine to use the file specified all the time, not to export the cert(s) out of it and then forget the file. (but maybe word of somebody with experience from large deployments would be helpful here).
short answer - no, if openldap will not support system store as java is (java was also integrated into ca-certificate packages by downstream, it is not default) I will simply remove the system option from setup.
Did not wait for the dependencies, rpm package enforces uses the ca-certificates trust store.