fred.bloggs Posted February 13, 2021 Report Share Posted February 13, 2021 Hi, we are trying to get our phones using the phone book via LDAP TLS. All of our phones are from yealink. Having the phones provisioned via Vodia 66.0.7 build (5.2.2021) works fine and also phonebook bia LDAP does work. But we have a hard time migrating to LDAP TLS. Here are the Vodia logs after changing from LDAP to LDAPS: [9] 10:00:22.600 LDAP xx.xx.xx.xx: Receive Client Hello(xxxxxxx)ⓘ [9] 10:00:22.600 LDAP xx.xx.xx.xx:123: No session ID in client helloⓘ [9] 10:00:22.600 LDAP xx.xx.xx.xx:123: Matched cipher suite RSA_WITH_AES_256_CBC_SHAⓘ [9] 10:00:22.614 LDAP xx.xx.xx.xx:123: Send Server Hello(xxxxxxx)ⓘ [9] 10:00:22.614 LDAP xx.xx.xx.xx:123: Send Certificate(xxxxxxx)ⓘ [9] 10:00:22.614 LDAP xx.xx.xx.xx:123: Send Hello Done()ⓘ [5] 10:00:22.648 LDAP xx.xx.xx.xx:123: Alert Fatal (2): Unknown CA (48)ⓘ So Vodia responds with "unkonwn ca". I also tried to use Thunderbird which is also able to connect to LDAPS phone books. It succesfully connects over TLS: [9] 10:03:08.585 LDAP xx.xx.xx.xx:123: Receive Client Hello(xxxxxxx)ⓘ [7] 10:03:08.585 LDAP xx.xx.xx.xx:123: TLS in domain pbx.somedomain.testⓘ [9] 10:03:08.585 Supported Versions 0403040303ⓘ [6] 10:03:08.585 LDAP xx.xx.xx.xx:123: Session xxxxxxx not foundⓘ [9] 10:03:08.585 LDAP xx.xx.xx.xx:123: Matched cipher suite ECDHE_RSA_WITH_AES_128_CBC_SHAⓘ [7] 10:03:08.585 LDAP xx.xx.xx.xx:123: Received client hello for pbx.somedomain.testⓘ [9] 10:03:08.585 LDAP xx.xx.xx.xx:123: Send Server Hello(xxxxxxx)ⓘ [9] 10:03:08.585 LDAP xx.xx.xx.xx:123: Send Certificate(xxxxxxx)ⓘ [9] 10:03:08.717 LDAP xx.xx.xx.xx:123: Send Server Key Exchange(xxxxxxx)ⓘ [9] 10:03:08.717 LDAP xx.xx.xx.xx:123: Send Hello Done()ⓘ [9] 10:03:08.747 LDAP xx.xx.xx.xx:123: Receive Client Key Exchange(xxxxxxx)ⓘ [9] 10:03:08.762 LDAP xx.xx.xx.xx:123: Pre Master Secret(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Client Random(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Server Random(6xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Master Secret(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Receive Change Cipher Spec(01)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Send Change Cipher Spec(01)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Perform Change Cipher Spec(c013)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Key Block(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Client Write MAC Secret(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Server Write MAC Secret(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Client Write Key(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Server Write Key(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Receive Process Finished(xxxxxxx)ⓘ [9] 10:03:08.764 LDAP xx.xx.xx.xx:123: Send Finished(xxxxxxx)ⓘ [9] 10:03:08.787 Processing LDAP request type 0 (55 bytes)ⓘ [9] 10:03:08.787 Try to bind to username@pbx.somedomain.testⓘ [6] 10:03:08.787 Successfully bind to user pbx.somedomain.test\usernameⓘ [9] 10:03:08.813 Processing LDAP request type 3 (1129 bytes)ⓘ [7] 10:03:08.813 Search request (&((|(cn=*test*)(givenName=*test*)(sn=*test*)(mozillaNickname=*test*)(mail=*test*)(mozillaSecondEmail=*test*)((&(description=*test*)))(o=*test*)(ou=*test*)(title=*test*)(mozillaWorkUrl=*test*)(mozillaHomeUrl=*test*))))ⓘ [9] 10:03:08.813 Search local extensionsⓘ [9] 10:03:08.813 Search address book of userⓘ [9] 10:03:08.813 Search address book of domainⓘ [6] 10:03:08.814 Search came up with 2 resultsⓘ [8] 10:03:08.814 Returning result testⓘ [8] 10:03:08.814 Search doneⓘ Can you point me to some direction what needs to be done to make LDAP over TLS work on yealink? We have connecetd phones via direct internet access to the Vodia (no VPN), and I do not feel comfortable passing address book information and login data unencrypted via the internet. Thanks. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 13, 2021 Report Share Posted February 13, 2021 The problem is that the LDAP client does not use the SNI extension for TLS. We have raised the issue with Yealink and they have added a setting for SIP, but not for LDAP. Wondering if anybody is using TLS with SIP?! Anyway until that flag is also available for LDAP, there is no reliable way to have LDAPS in a multi tenant environment. Quote Link to comment Share on other sites More sharing options...
fred.bloggs Posted February 13, 2021 Author Report Share Posted February 13, 2021 Ok, thanks for your fast reply. We are using only one tenant, that is one domain and we have a dedicated IP. Is it possible to bypass SNI of the vodia web server some how? Btw. we are using TLS with SIP over the whole path right to the SIP Trunk provider Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 13, 2021 Report Share Posted February 13, 2021 If you are using a valid certificate as the default certificate well then IMHO the Yealink should take it. But I am not very sure. It seems LDAPS is not a mainstream feature with Yealink. On a side note, this is why the PBX generates a separate password for LDAP, so that when an insecure protocol is used and someone gets it, the damage is limited to the address book. Quote Link to comment Share on other sites More sharing options...
fred.bloggs Posted February 13, 2021 Author Report Share Posted February 13, 2021 We do have a valid LE certificate thanks to the support of DNS made easy But the Yealinks don't take it unfortunately. There should no SNI be involved - strange. Do you support XML phone book? Quote Link to comment Share on other sites More sharing options...
fred.bloggs Posted February 13, 2021 Author Report Share Posted February 13, 2021 Ok, thanks to your comment I got it working The trick is to set the "System management DNS address" on system level to the same name as the domain name. So you get two LE certificates. One for the domain using SNI and one for the system not unsing SNI. Because the DNS names are the same, it works. Hope this does not cause any side effects though Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 13, 2021 Report Share Posted February 13, 2021 Yes that is fine. When there is no match the system indeed goes back to the system management address as a "last resort" to find a name. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.