Project

General

Profile

Actions

Bug #10139

closed

Cannot verify LDAPS SSL certificate on Debian installation

Added by Vasil Mikhalenya over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Authentication
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description


Related issues 2 (0 open2 closed)

Related to Foreman - Support #2435: Unable to authentication with LDAP server using ldapsClosedActions
Related to Foreman - Bug #9858: CVE-2015-1816 - LDAP server SSL certificate not verifiedClosedMarek Hulán03/22/2015Actions
Actions #1

Updated by Dominic Cleal over 9 years ago

  • Related to Support #2435: Unable to authentication with LDAP server using ldaps added
Actions #2

Updated by Dominic Cleal over 9 years ago

  • Related to Bug #9858: CVE-2015-1816 - LDAP server SSL certificate not verified added
Actions #3

Updated by Dominic Cleal over 9 years ago

  • Tracker changed from Tracker to Bug
  • Subject changed from Please reopen #2435 as not fixes to Cannot verify LDAPS SSL certificate on Debian installation
  • Category set to Authentication
Actions #4

Updated by Dominic Cleal over 9 years ago

I'm unable to reproduce this at all, I tested on 1.7.4 and Ubuntu 14.04 with an LDAPS server that wouldn't verify out of the box, added my .crt to /usr/local/share/ca-certificates, ran update-ca-certificates and next time I logged in, it worked.

My only other idea, if the s_client is working, is whether the hostname in the LDAP authentication config in Foreman is exactly what's on the certificate?

Actions #5

Updated by Vasil Mikhalenya over 9 years ago

Sure. Name and Server exactly match first cert cn in chain.

v-foreman:~# openssl s_client -CApath /etc/ssl/certs -connect dc.corp.domain.local:636
CONNECTED
depth=2 CN = Corp Root CA
verify return:1
depth=1 CN = Corp Issuing SubCA 1
verify return:1
depth=0 CN = dc.corp.domain.local
verify return:1

only the option is to upgrade ubuntu to 14.04 ? going to try to complete it this week

Actions #6

Updated by Dominic Cleal over 9 years ago

Vasil Mikhalenya wrote:

only the option is to upgrade ubuntu to 14.04 ? going to try to complete it this week

No, I didn't mean to imply that makes any difference, I just happened to test 14.04.

Actions #7

Updated by Mizuki Kara over 9 years ago

Didn't Olivier from old ticket #2435 indicated his environment is 14.04.2?
Mine by the way is Debian latest wheezy 7.8.

Actions #8

Updated by Vasil Mikhalenya over 9 years ago

the issue present on Ubuntu 14.04 and Centos7 ( SCL ruby193-) foreman 1.8 - so its actually non debian related issue
I suppose root of the issue is in cert chain - I have two certs in chain.

[v-foreman ~]# openssl s_client -CApath /etc/pki/tls/certs/ -connect dc.corp.local:636
CONNECTED(00000003)
depth=1 CN = Corp Issuing SubCA 1
verify error:num=20:unable to get local issuer certificate
verify return:0
---

after trusting to both certs

[v-foreman ~]# openssl s_client -CApath /etc/pki/tls/certs/ -connect dc.corp.local:636
CONNECTED(00000003)
depth=2 CN = Corp Root CA
verify return:1
depth=1 CN = Corp Issuing SubCA 1
verify return:1
depth=0 CN = dc.corp.local
verify return:1
---
Actions #9

Updated by Vasil Mikhalenya over 9 years ago

Seems like we might close ticket after updating docs. I've got LDAPs working by joining both certs in one file.

cd /etc/pki/tls/certs
cat Corp_RCA.crt Corp_PICA.crt > Corp_INT.crt
ln -f -s Corp_INT.crt /etc/pki/tls/certs/$(openssl x509 -noout -hash -in /etc/pki/tls/certs/Corp_INT.crt).0

also works for ubuntu after update-ca-certificates -v -f

You'd also should stop and start httpd.

Actions #10

Updated by Dominic Cleal over 9 years ago

  • Status changed from New to Resolved

Thanks for the update Vasil - I updated the documentation to match your findings: https://github.com/theforeman/theforeman.org/commit/3affcfba41845fe47838d4bfc8cc4090d647b3f5

Actions #11

Updated by Vasil Mikhalenya over 9 years ago

It is obvious that all certs should be trusted, but it only works for foreman (ruby) when you add certs concatenated in one file (not separate i.e. cert per file as I did originally) to a trusted storage. That was my point and this is the difference with openssl s_client -CApath /etc/pki/tls/certs/ which works with both options.

Actions

Also available in: Atom PDF