Bug 1255621 - [setup] openldap does not recognize system certificates
Summary: [setup] openldap does not recognize system certificates
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine-extension-aaa-ldap
Classification: oVirt
Component: Setup
Version: master
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ovirt-4.0.0-alpha
: 1.1.0
Assignee: Yaniv Kaul
QA Contact: Ondra Machacek
URL:
Whiteboard:
Depends On: 1255651
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-21 08:14 UTC by David Jaša
Modified: 2016-02-18 11:09 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-02-18 11:09:59 UTC
oVirt Team: Infra
Embargoed:
rule-engine: ovirt-4.0.0+
ylavi: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 47210 0 None MERGED setup: system trust store customization 2020-06-19 22:25:35 UTC

Description David Jaša 2015-08-21 08:14:37 UTC
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

Comment 1 Alon Bar-Lev 2015-08-21 08:18:44 UTC
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 08:58:02 UTC
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.

Comment 3 David Jaša 2015-08-21 15:02:19 UTC
(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 15:38:31 UTC
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 07:58:36 UTC
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.