Bug 1255621 - [setup] openldap does not recognize system certificates
[setup] openldap does not recognize system certificates
Product: ovirt-engine-extension-aaa-ldap
Classification: oVirt
Component: Setup (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ovirt-4.0.0-alpha
: 1.1.0
Assigned To: Yaniv Kaul
Ondra Machacek
Depends On: 1255651
  Show dependency treegraph
Reported: 2015-08-21 04:14 EDT by David Jaša
Modified: 2016-02-18 06:09 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-02-18 06:09:59 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.0.0+
ylavi: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 47210 None None None Never

  None (edit)
Description David Jaša 2015-08-21 04:14:37 EDT
Description of problem:
ovirt-engine-extension-aaa-ldap-setup can't recognize system certificates

Version-Release number of selected component (if applicable):
RHEV 3.6.0-10

How reproducible:

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
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
Comment 1 Alon Bar-Lev 2015-08-21 04:18:44 EDT
the problem is that the openldap and java probably use different stores, this was expected, unless there is something else wrong, will check.
Comment 2 Alon Bar-Lev 2015-08-21 04:58:02 EDT
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:


using system store is highly not recommended anyway.

will open a separate bug against openldap.
Comment 3 David Jaša 2015-08-21 11:02:19 EDT
(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).
Comment 4 Alon Bar-Lev 2015-08-21 11:38:31 EDT
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.
Comment 5 Alon Bar-Lev 2015-10-12 03:58:36 EDT
Did not wait for the dependencies, rpm package enforces uses the ca-certificates trust store.

Note You need to log in before you can comment on or make changes to this bug.