# Icingaweb2 and LDAPS? **URL:** \ **Category:** Icinga Web\ **Tags:** icingaweb2\ **Created:** [September 4, 2021, 11:48pm UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144 "2021-09-04T23:48:55Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![flipp3003](https://community.icinga.com/user_avatar/community.icinga.com/flipp3003/32/2725_2.png) [@flipp3003](https://community.icinga.com/u/flipp3003)\ **Post date:** [September 4, 2021, 11:48pm UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/1 "2021-09-04T23:48:55Z")
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](https://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… ---
**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\ **Post date:** [September 6, 2021, 9:07am UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/2 "2021-09-06T09:07:08Z")
hi 🙂 I’m not very experienced with the whole topic, but maybe my thoughts help 🙂 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? ---
**Author:** ![flipp3003](https://community.icinga.com/user_avatar/community.icinga.com/flipp3003/32/2725_2.png) [@flipp3003](https://community.icinga.com/u/flipp3003)\ **Post date:** [September 6, 2021, 1:41pm UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/3 "2021-09-06T13:41:28Z")
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 ```auto 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 --- read: errno = 104 # ``` Does the output help analyze the problem ??? ---
**Author:** ![theFeu](https://community.icinga.com/user_avatar/community.icinga.com/thefeu/32/7277_2.png) [@theFeu](https://community.icinga.com/u/theFeu)\ **Post date:** [September 6, 2021, 2:19pm UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/4 "2021-09-06T14:19:21Z")
Heyhey, just chiming in: We always love to see posts formatted according to the [formatting guidelines](https://community.icinga.com/t/create-topics-and-master-markdown-formatting/69) which can help you make your posts a lot more readable 🙂 ---
**Author:** ![flipp3003](https://community.icinga.com/user_avatar/community.icinga.com/flipp3003/32/2725_2.png) [@flipp3003](https://community.icinga.com/u/flipp3003)\ **Post date:** [September 6, 2021, 2:22pm UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/5 "2021-09-06T14:22:46Z")
Oops, sorry. That will not happen again… ---
**Author:** ![theFeu](https://community.icinga.com/user_avatar/community.icinga.com/thefeu/32/7277_2.png) [@theFeu](https://community.icinga.com/u/theFeu)\ **Post date:** [September 6, 2021, 2:24pm UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/6 "2021-09-06T14:24:52Z")
Don’t worry about it 🙂 You can also edit any posts you made before if you wish to do so! ---
**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\ **Post date:** [September 6, 2021, 2:53pm UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/7 "2021-09-06T14:53:59Z")
> [@flipp3003](#): > > Can I also specify several in the resources.ini? Yes, you can put multiple servers separated by spaces in there. `hostname = "dc01.dev dc02.dev dc03.dev"` > [@flipp3003](#): > > I still have to check dpkg-reconfigure Please do, at least that give you the option to choose which new certificates you want to add ![image](https://community.icinga.com/uploads/default/original/2X/5/583f23c645278234297d6bf8cdb7128399d37dda.png) ![image](https://community.icinga.com/uploads/default/original/2X/3/3f7fbbab815ab41168442054eb31ff5becceeeb4.png) example (for the screenshots, not actually doing anything) ```auto # 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 😉 ---
**Author:** ![flipp3003](https://community.icinga.com/user_avatar/community.icinga.com/flipp3003/32/2725_2.png) [@flipp3003](https://community.icinga.com/u/flipp3003)\ **Post date:** [September 6, 2021, 8:25pm UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/10 "2021-09-06T20:25:32Z")
> [@log1c](#): > > Yes, you can put multiple servers separated by spaces in there. > `hostname = "dc01.dev dc02.dev dc03.dev"` Great, thanks for the hint! > [@log1c](#): > > Please do, at least that give you the option to choose which new certificates you want to add 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? ---
**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\ **Post date:** [September 7, 2021, 8:52am UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/11 "2021-09-07T08:52:18Z")
> [@flipp3003](#): > > What do you think of the output of: > openssl s\_client -connect server: 636 > > Is this ok? I’m not 100% sure, but there is a > [@flipp3003](#): > > ```auto > read: errno = 104 > > ``` 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](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` ---
**Author:** ![flipp3003](https://community.icinga.com/user_avatar/community.icinga.com/flipp3003/32/2725_2.png) [@flipp3003](https://community.icinga.com/u/flipp3003)\ **Post date:** [September 7, 2021, 12:43pm UTC](https://community.icinga.com/t/icingaweb2-and-ldaps/8144/12 "2021-09-07T12:43:50Z")
> [@log1c](#): > > 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` 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 !!!