Authenticating with LDAP/s using our internal CA

Authenticating with LDAP/s using our internal CA

by David Glass -
Number of replies: 13

Here is the scenario. We have a hosted VPS with inmotionhosting. We've acquired root access and currently have moodle installed on one of the user cPanels. We've hired a SME to customize moodle to our liking. The problem is trying to setup LDAP/s authentication for the purposes of creating users.

Since the moodle server is located on a VPS and we went the route of using our internal CA for authentication, we had to open port 636 on our firewall and allow communication from the VPS public IP. Once that was done we went about configuring the LDAP module in moodle. Here are our settings for the LDAP server (note that there is an internal host entry on the VPS for the host URL specified below):

Host URL: ldaps://server.contoso.local

Version: 3

Use TLS: No

LDAP encoding: utf-8

Hide Passwords: Yes

Dstinguished name: CN=svc-Moodle,OU=Svc,DC=contoso,DC=local

Password:  password

User type: MS ActiveDirectory

Contexts: ou=sd users,dc=contoso,dc=local

Search subcontexts: Yes

Dereference aliases: No

 

From our CA, we exported our CA cert and imported it into the VPS. We used this moodle doc to then attempt to establish a link using that certificate: http://docs.moodle.org/26/en/LDAP_authentication#Enabling_LDAPS_on_your_Moodle_server

From an SSH shell into the VPS, here are the exact commands we used to try and establish the secure link:

cd /etc/ssl/certs
openssl x509 -in <ca cert name>.cer -inform DER -out <ca cert name>.pem -outform PEM
openssl x509 -in <server cert name>.cer -inform DER -out <server cert name>.pem -outform PEM
c_rehash
cat <ca cert name>.pem | grep 'BEGIN.* CERTIFICATE' | wc -l
openssl x509 -noout -fingerprint -in <ca cert name>.pem
openssl x509 -noout -hash -in <ca cert name>.pem
ln -s ca_drsdc3.pem `openssl x509 -hash -noout -in <ca cert name>.pem`.0

 

Then to verify the certs were installed correctly, we used these commands:

openssl verify -verbose -CApath /etc/ssl/certs /etc/ssl/certs/<ca cert name>.pem

openssl verify -verbose -CApath /etc/ssl/certs /etc/ssl/certs/<server cert name>.pem

 

They returned an OK. The final step was to use this command to verify that we can connect and authenticate successfully with our internal CA:

openssl s_client -connect server.contoso.local:636

 

This is where the problem lies. This is the output from this command:

root@vps11666 [/etc/ssl/certs]# openssl s_client -connect drs-dc3.drsystems.local:636
CONNECTED(00000003)
depth=0 CN = DRS-DC3.drsystems.local
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = DRS-DC3.drsystems.local
verify error:num=27:certificate not trusted
verify return:1
depth=0 CN = DRS-DC3.drsystems.local
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=DRS-DC3.drsystems.local
i:/DC=local/DC=drsystems/CN=drsystems-DRS-DC3-CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFezCCBGOgAwIBAgIKVup9CQAAAAAAAzANBgkqhkiG9w0BAQsFADBRMRUwEwYK
CZImiZPyLGQBGRYFbG9jYWwxGTAXBgoJkiaJk/IsZAEZFglkcnN5c3RlbXMxHTAb
BgNVBAMTFGRyc3lzdGVtcy1EUlMtREMzLUNBMB4XDTE0MDUwMTE5MzQ0NVoXDTE1
MDUwMTE5MzQ0NVowIjEgMB4GA1UEAxMXRFJTLURDMy5kcnN5c3RlbXMubG9jYWww
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJs3wLsRo+BzY3JUf+l6IDDPOsaS
qzZSqFaofu3KwspeJ/GxshljY1rA4AF+suhn+h4XRgV6sYKz8evQpkOsKS6pJXnC
ZZ79TPF6yHz4vMAVBOFTqSZk9CNTzgDTIFnf3QpsCJnQ9LYZEFsZQWcqY4Xdv7SN
Sdyfq1WdinNm7QFNAgMBAAGjggMGMIIDAjAvBgkrBgEEAYI3FAIEIh4gAEQAbwBt
AGEAaQBuAEMAbwBuAHQAcgBvAGwAbABlAHIwHQYDVR0lBBYwFAYIKwYBBQUHAwIG
CCsGAQUFBwMBMAsGA1UdDwQEAwIFoDB4BgkqhkiG9w0BCQ8EazBpMA4GCCqGSIb3
DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
LTALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEFMAcGBSsOAwIHMAoGCCqGSIb3DQMH
MB0GA1UdDgQWBBT25GR2GDwPF1mo2k1MAzAEdb3qcjAfBgNVHSMEGDAWgBT8b2a8
t0IJXIESofzvOFUzu8nx+zCB1gYDVR0fBIHOMIHLMIHIoIHFoIHChoG/bGRhcDov
Ly9DTj1kcnN5c3RlbXMtRFJTLURDMy1DQSxDTj1EUlMtREMzLENOPUNEUCxDTj1Q
dWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0
aW9uLERDPWRyc3lzdGVtcyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M
aXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgcoGCCsG
AQUFBwEBBIG9MIG6MIG3BggrBgEFBQcwAoaBqmxkYXA6Ly8vQ049ZHJzeXN0ZW1z
LURSUy1EQzMtQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZHJzeXN0ZW1zLERDPWxvY2Fs
P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0
aG9yaXR5MEMGA1UdEQQ8MDqgHwYJKwYBBAGCNxkBoBIEEIsvjpzVePhKkbx4IlfO
/emCF0RSUy1EQzMuZHJzeXN0ZW1zLmxvY2FsMA0GCSqGSIb3DQEBCwUAA4IBAQCW
WJfsgAaO3L/qCqjYNhWcuheC2FrMKTArcxMWZMXrosPk5bboU6+JNXfNSJu/D5vg
fwP4Fj5P+fptUEbQDHhU8rS/kOUEE9odp4K+DxjQEdGqSzQwXR2wL+qb/apiQsJX
vQ2eBxKqjkyqXOwurfZU1Ajfy/bj4H9B/0CKhZ3yJN2tcYIsQ9N7911HAHrwOBrq
HjD3QKIs8dZ1uf5FLZNAtjuUpU6hRpmoT4582SDsWsvpZJZlZk4TcjkpEyy0iQF1
U16B6qnb4nokGQtFtRrdJZeykrqdQelR9YtAwUV2grYtmHG4urhUWXmoZcMLcPqd
elFb9EhIamnwmBl3swaW
-----END CERTIFICATE-----
subject=/CN=DRS-DC3.drsystems.local
issuer=/DC=local/DC=drsystems/CN=drsystems-DRS-DC3-CA
---
Acceptable client certificate CA names
/DC=local/DC=drsystems/CN=drsystems-DRS-DC3-CA
/CN=DRS-DC3.drsystems.local
/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2
/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority
/CN=NT AUTHORITY
---
SSL handshake has read 3149 bytes and written 727 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID: 943E0000B7B527FEE5D8D9F3CCED6C97FBAE964C9576AC23B0B6E55EDA747F41
Session-ID-ctx:
Master-Key: C10756E19E017B8AFB224C014E64B0C2C9F11FBDA534675FEC13327FF76BF9F2F90C67A51EED14B6E3597956C97BE371
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1399313846
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---

read:errno=104

 

I'm not an openssl expert by any means, but I can see that there are verification problems when connecting to our server. Does anyone have any ideas on how to help us?

Average of ratings: -
In reply to David Glass

Re: Authenticating with LDAP/s using our internal CA

by David Glass -

Are there any moderators on here. Can you please delete the previous post? I accidentally included our cert information on here.

Average of ratings: -
In reply to David Glass

Re: Authenticating with LDAP/s using our internal CA

by Adam Turner -

Hi David,

I know this post is a bit old, but did you ever find a solution to this problem.  I'm having a nearly identical issue and followed the same steps as you did.

Thanks,

Adam

Average of ratings: -
In reply to Adam Turner

Re: Authenticating with LDAP/s using our internal CA

by Dave Perry -
Picture of Testers

If you can't add a custom CA (which is what we do internally here - mainly as the proxy sniffs HTTPS traffic), which I don't know how to do, couldn't you get a pay for certificate from a proper CA?

Average of ratings: -
In reply to Dave Perry

Re: Authenticating with LDAP/s using our internal CA

by Adam Turner -

Well, I was able to install the certificate from the AD Domain Controller without a problem.  It is just that the moodle server doesn't seem to look at the ldap.conf file when initiating the connection with the AD DC.   While I'm not 100% sure, there doesn't seem to be a problem with the AD certificate - especially as it has worked on other servers.  

Thanks for the thought however.

Adam

Average of ratings: -
In reply to Adam Turner

Re: Authenticating with LDAP/s using our internal CA

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers
Is Moodle running on LInux or Windows?  Have you changed the TLS_Reqcert setting to Never?
Average of ratings: -
In reply to Emma Richardson

Re: Authenticating with LDAP/s using our internal CA

by Adam Turner -

It is running on Linux.   

I have tried the "TLS_REQCERT never" command on the ldap.conf file but it doesn't seem to work either way.  Ideally, I would use the "TLS_REQCERT demand" and point to the right certificate pem file but it isn't working under either configuration.

Thanks,
Adam



Average of ratings: -
In reply to Adam Turner

Re: Authenticating with LDAP/s using our internal CA

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

Are you getting the same error as the original post?  The can't verify or find first certificate error?

Average of ratings: -
In reply to Emma Richardson

Re: Authenticating with LDAP/s using our internal CA

by Adam Turner -

Hi, this is the result I get when i do a ldapsearch command to help see where the problems are.

bitnami@MoodleTraining:~$ ldapsearch -x -d 1 -b  "ou=dc=MyDomain,dc=com" -H ldaps://ActiveDirectoryServer.com:PortNumber -D "CN=My User,OU=Service Accounts,DC=MyDomain,DC=com" -w "Password" -v

ldap_url_parse_ext(ldaps://:30001/)

ldap_initialize( ldaps://ActiveDirectoryServer.com:PortNumber/??base )

ldap_create

ldap_url_parse_ext(ldaps://ActiveDirectoryServer.com:PortNumber/??base)

ldap_sasl_bind

ldap_send_initial_request

ldap_new_connection 1 1 0

ldap_int_open_connection

ldap_connect_to_host: TCP ldaps://ActiveDirectoryServer.com:PortNumber

ldap_new_socket: 3

ldap_prepare_socket: 3

ldap_connect_to_host: Trying IP_Address:PortNumber

ldap_pvt_connect: fd: 3 tm: -1 async: 0

TLS trace: SSL_connect:before/connect initialization

TLS trace: SSL_connect:unknown state

TLS trace: SSL_connect:SSLv3 read server hello A

TLS certificate verification: depth: 0, err: 20, subject: /CN=ActiveDirectoryServer.com, issuer: /DC=com/DC=Domain/CN=Domain-SubDomain-CA

TLS certificate verification: Error, unable to get local issuer certificate

TLS trace: SSL3 alert write:fatal:unknown CA

TLS trace: SSL_connect:error in SSLv3 read server certificate B

TLS trace: SSL_connect:error in SSLv3 read server certificate B

TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get local issuer certificate).

ldap_err2string

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

I then found a command to find where the server is looking for the ldap.conf file.  I ran that as follows with the resulting code:

bitnami@MoodleTraining:~$ strace ldapsearch -v -H ldaps://ActiveDirectoryServer.com:PortNumber 2>&1 | grep ldap.conf

open("/bitnami/lampstack-linux-x64/output/common/etc/openldap/ldap.conf", O_RDONLY) = -1 ENOENT (No such file or directory)

I believe this confirms my original thoughts that the server wasn't reading the ldap.conf file that I was editing.  I originally was editing the file at the etc/ldap/ location but this wasn't being read. From there, I to created a directory at the /etc/openldap/ location and put the ldap.conf file there but that didn't work either.  Given the feedback on this command, I tried editing the ldap.conf file that was already in place at the following location: /opt/bitnami/common/etc/openldap.  

Unfortunately I'm still getting the same result:

open("/bitnami/lampstack-linux-x64/output/common/etc/openldap/ldap.conf", O_RDONLY) = -1 ENOENT (No such file or directory)

I'm not an expert on Linux or it's various distributions, but the /bitnami/ directory and following (from the error above) doesn't exist either.  Any thoughts?   Is this due to this being a bitnami distribution in some way?  

Thanks,

Adam

Average of ratings: -
In reply to Adam Turner

Re: Authenticating with LDAP/s using our internal CA

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

Not sure about the Bitnami distribution.  In my experience, if the cert has been imported, it is normally the TLS ReqCert setting that needs changed.  We would all prefer not to set that setting to never but I ended deciding that I wanted it working and that did fix it.  Did you try changing that setting in the ldap.conf file that the program is actually looking for?

Average of ratings: -
In reply to Emma Richardson

Re: Authenticating with LDAP/s using our internal CA

by Adam Turner -

Hi Emma,  Thanks for the responses.

Yes, I have tried the 'TLS_REQCERT never' command in the ldap.conf file but I believe the problem is that the server is looking in the wrong place for that ldap.conf file.  

I'm not sure if it is possible to tell the server where to look for the conf file, but that seems like it could be a solution.

Thanks,

Adam

Average of ratings: -
In reply to Adam Turner

Re: Authenticating with LDAP/s using our internal CA

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

Did you try copying the file to the location that it is looking in?  With the TLS never command?

Average of ratings: -
In reply to Emma Richardson

Re: Authenticating with LDAP/s using our internal CA

by Adam Turner -

Hi Emma,

So, I finally did make the directory "/bitnami/lampstack-linux-x64/output/common/etc/openldap/" and place the ldap.conf file in that location and the ldapsearch finally worked.  In fact, I even changed the TLS_REQCERT command to "demand" and it still worked - meaning my certificate is being accepted.  

Strangely, after pausing work overnight, the web access just started working too.  Granted, I have TLS turned off, but my LDAP server URL is set to the secure ldaps at ldaps://MyDomain.com:PortNumber.  I think this is the right behavior, setting up the proper security.

Does that seem right to you?

Thanks,

Adam

Average of ratings: -
In reply to Adam Turner

Re: Authenticating with LDAP/s using our internal CA

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

You actually got further than me because I have never been able to get my linux server to accept the certificate unless the ReqCert is set to never. 

I would think you are in good shape - some higher level security experts here might confirm as well??

Average of ratings: -