Icingaweb2 and LDAPS?

Icinga Web
1

Hello freaks,

I’m not a Linux insider, but I have successfully installed Icinga2 and icingaweb2 and everything is going great.
In my company we want to make our systems more secure, so I switched icingaweb2 to https. This also works great. However, I have big problems with the authentication via LDAP. LDAP itself works fine, but not LDAPS.
What am I doing wrong?

I’m using a Debian 11 without a GUI. (Icinga r2.13.1-1, php 7.4.21)

authentication.ini:
[ad_user]
backend = “msldap”
resource = “active_directory”
filter = “! (objectClass = computer)”
base_dn = “DC=xx,DC=yy,DC=zz”

[active_directory]
type = “ldap”
hostname = “server.xx.yy.zz”
port = “389”
encryption = “none”
root_dn = “DC=xx,DC=yy,DC=zz”
bind_dn = “CN=Monitoring,OU=servies,OU=location,DC=xx,DC=yy,DC=zz”
bind_pw = “password”
timeout = “5”

This works great, but the following changes no longer:

port = “636”
encryption = “LDAPS”

The certificates for our CA’s are successfully installed in /etc/ssl/certs (c_rehash) …

The following error occurs during the connection test in the Icingaweb2 web interface:

Connect using LDAPS
NOTE: There might be an issue with the chosen encryption. Ensure that the LDAP server supports LDAPS and that the LDAP client is configured to accept its certificate.
LDAP bind (CN = Monitoring, OU = servies, OU = location, DC = xx, DC = yy, DC = zz / ***) to ldaps: //server.xx.yy.zz: 636 failed: Can’t contact LDAP server.

Note:
it works great on a CentOS, but that OS is not an option.

I am thankful for every help…

2

hi :slight_smile:
I’m not very experienced with the whole topic, but maybe my thoughts help :slight_smile:

On my ubuntu systems I always used dpkg-reconfigure ca-certificates to add new ca certs, not sure if there is a difference to c_rehash though.
What response do you get from openssl s_client -connect server:636? As you write that it works from centos I assume the DCs all have the correct certificates to allow LDAPS?

3

Thanks for your answer.

I still have to check dpkg-reconfigure, but I think this is used to reconfigure the entire system or individual packages. Besides that, HTTPS works …

Yes, it works with CentOS.
Yes, all of the DCs all have the correct certificates. However, so far I only connect with one. Can I also specify several in the resources.ini?

Output from: openssl s_client -connect server: 636

CONNECTED (00000003)
depth = 2 C = zz, O = Location, CN = Root CA-2020
verify return: 1
depth = 1 C = zz, O = Location, CN = Sub-CA-2020
verify return: 1
depth = 0 DC = zz, DC = yy = xx, OU = Domain Controllers, CN = server
verify return: 1
---
Certificate chain
 0 s: DC = zz, DC = yy, DC = xx, OU = domain controllers, CN = server
   i: C = zz, O = Location, CN = Sub-CA-2020
 1 s: C = zz, O = Location, CN = Sub-CA-2020
   i: C = zz, O = Location, CN = Root CA-2020
---
Server certificate
----- BEGIN CERTIFICATE -----
MIIJDzCCBsOgAwIBAgITHAAADE6h5CU0jgdBmgAAAAAMTjBBBgkqhkiG9w0BAQow
NKAPMA0GCWCGSAFlAwQCAQUAoRwwGgYJKoZIhvcNAQEIMA0GCWCGSAFlAwQCAQUA
...
...
...
MkhmS9TTqs + eV8uZmf9Xz5UgbpNaWB7bUj0 / smOEmoNx8MDnV2TTZqPAA + e / qWnn
y03NxdayYJUhy6RMStlC / uBlqg ==
----- END CERTIFICATE -----
subject = DC = zz, DC = yy, DC = xx, OU = Domain Controllers, CN = server

issuer = C = zz, O = Location, CN = Sub-CA-2020

---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA + SHA256: RSA + SHA384: RSA + SHA1: ECDSA + SHA256: ECDSA + SHA384: ECDSA + SHA1: DSA + SHA1: RSA + SHA512: ECDSA + SHA512
Shared Requested Signature Algorithms: RSA + SHA256: RSA + SHA384: ECDSA + SHA256: ECDSA + SHA384: RSA + SHA512: ECDSA + SHA512
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4785 bytes and written 419 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL session:
    Protocol: TLSv1.2
    Cipher: ECDHE-RSA-AES256-GCM-SHA384
    Session ID: 6F0400004BE6223A454004F0B62A55B459B7D3A9D09BBF02AB663C38BA285AAC
    Session ID ctx:
    Master key: C0395AABAE639A9A6E8914FA52F551F3992E015B28A548A568D68687BDF2F4E74F52457BD5DFFC6310C1032B38024BB4
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1630932406
    Timeout: 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
--- <ENTER>
read: errno = 104
#

Does the output help analyze the problem ???

4

Heyhey, just chiming in:
We always love to see posts formatted according to the formatting guidelines which can help you make your posts a lot more readable :slight_smile:

5

Oops, sorry. That will not happen again…

6

Don’t worry about it :slight_smile:
You can also edit any posts you made before if you wish to do so!

7

Yes, you can put multiple servers separated by spaces in there.
hostname = "dc01.dev dc02.dev dc03.dev"

Please do, at least that give you the option to choose which new certificates you want to add

image
image955×455 7 KB

image
image842×392 10.2 KB

example (for the screenshots, not actually doing anything)

# dpkg-reconfigure ca-certificates
        Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Processing triggers for ca-certificates (20210119~20.04.1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

A c_rehash or update-ca-certificates is not needed after this I think (I mostly do it anyways^^). But as said this is not a strong topic of mine :wink:

10

Great, thanks for the hint!

Are they all from mozilla? My company’s root certificate is not displayed at all. But I definitely copied these two certificates to the /etc/ssl/certs directory + c_rehash.
How can I then insert it?

What do you think of the output of:
openssl s_client -connect server: 636

Is this ok?

11

I’m not 100% sure, but there is a

in the output, so I assume there is still something wrong. Like the CA cert not being correctly imported.
Quick search on that:
Quote from https://superuser.com/questions/297889/does-openssl-errno-104-mean-that-sslv2-is-disabled

At least on Linux, 104 is ECONNRESET for “Connection reset by peer” – in other words, the connection was forcibly closed with a TCP RST packet, either sent out by the server or spoofed by an intermediary.

Here is what I did on the Linux VM to be able to use LDAPS:

export the root-cert of the CA as DER-file. Then:

  1. copy the der file to the monitoring server
  2. openssl x509 -inform der -in certificate.cer -out certificate.pem to convert the certificate to the correct format
  3. save the correctly formatted cert under /usr/share/ca-certificates/extra/
    a. sudo cp certificate.pem /usr/share/ca-certificates/extra/certificate.crt
  4. run sudo dpkg-reconfigure ca-certificates, add the new certificate and then run sudo update-ca-certificates
12

Yeah, Yeah, it works!
The error was in the certificate. The Linux format may ONLY contain the following, otherwise it will not be included in the /etc/ssl/certs/ca-certificates.crt file by update-ca-certificates:

----- BEGIN CERTIFICATE -----
MIIKejCCCGKgAwIBAgIQMY0kskYpkX5n6X9RpkYYujANBgkqhkiG9w0BAQsFADBk
MQswCQYDVQQGEwJERTEZMBcGA1UECgwQRnJlaXN0YWF0IEJheWVybjEPMA0GA1UE
CwwGSVQtRExaMSkwJwYDVQQDDCBCYXllcm4tU29mdHRva2VuLUlzc3VpbmctQ0Et
…
…
…
2rBfQZTczStxf / k1R3w6WLDy + CwppMD6vTSC7 + 3mqnRQIpsmsnhSJZKbbSg / 9VHy
c0xevQA2w / EvK4kiFuZpJaxHdFvGUiJd0rEGijEoEh + 9tgLzObvu8pxjhZAaXUCx
E + hmgPnmhzlptPAtMvQjSf0tPyrJd86fvxhR / XBIysaPsq8TjlA793QALLybJQ ==
----- END CERTIFICATE -----

Thank you very much for your help and support and send greetings from Leipzig, Germany !!!