Hello,
I'm trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster.
I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I'm just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors:
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file)
[server:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate's Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs
[client:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem
When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved.
The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate.
As the only difference between UM and Skype's Mediation is the certificate's Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this?
Thanks, Francisco.
Hello,
On 25.10.17 11:32, Francisco Valentin Vinagrero wrote:
Hello,
I’m trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster.
I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I’m just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors:
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file)
[server:default]
method = TLSv1+
verify_certificate = yes
require_certificate = yes
private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem
certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate’s Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names
ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs
[client:default]
method = TLSv1+
verify_certificate = yes
require_certificate = yes
private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem
certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem
ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem
When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved.
The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate.
As the only difference between UM and Skype’s Mediation is the certificate’s Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this?
afaik, the certificate validation is done by the libssl, kamailio is not doing much in this respect and no dns query inside kamailio tls module. Maybe some parameters must be set when asking for validation.
If you run with debug=3 inside kamailio.cfg, do you see any log messages that can help in identifying why it fails?
Cheers, Daniel
Hello Daniel,
Thanks for your answer.
I don't see much in the debug logs. Except the SSL verification error, the rest looks like the normal SSL handshake and the TCP connection setup:
DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa7edc0, 8, -1, 0x10) fd_no=2 called DEBUG: <core> [tcp_read.c:1490]: release_tcpconn(): releasing con 0x7f9191b1ade0, state -2, fd=8, id=8 ([<SfB IP1>]:56267 -> [<SfB IP1>]:5061) DEBUG: <core> [tcp_read.c:1491]: release_tcpconn(): extra_data 0x7f9191b39318 DEBUG: <core> [tcp_main.c:3243]: handle_tcp_child(): reader response= 7f9191b1ade0, -2 from 0 DEBUG: tls [tls_server.c:663]: tls_h_close(): Closing SSL connection 0x7f9191b39318 DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: <SfB IP1> DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56269, type 3 DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 3769:3996:3198, 9 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7f9191b1ade0), fd_no=20 DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=21 called DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1 DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 1 12(4808) for activity on [tls:<LOCAL IP>:5061], 0x7f9191b1ade0 DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7f9191b1ade0, fd=8 DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f9191861e98 ctx 0x7f9191887a10 sn []) DEBUG: tls [tls_domain.c:703]: sr_ssl_ctx_info_callback(): SSL handshake started DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=6692 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#026#003#003 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa7edc0, 8, 2, 0x7f9191b1ade0), fd_no=1 DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=7 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#025#003#003 ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
Maybe you can see some hint there that I don't see?
Cheers, Francisco.
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, October 25, 2017 14:50 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; Francisco Valentin Vinagrero francisco.valentin.vinagrero@cern.ch Subject: Re: [SR-Users] Mutual TLS with Skype for Business 2015
Hello,
On 25.10.17 11:32, Francisco Valentin Vinagrero wrote: Hello,
I'm trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster.
I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I'm just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors:
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file)
[server:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate's Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs
[client:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem
When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved.
The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate.
As the only difference between UM and Skype's Mediation is the certificate's Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this?
afaik, the certificate validation is done by the libssl, kamailio is not doing much in this respect and no dns query inside kamailio tls module. Maybe some parameters must be set when asking for validation.
If you run with debug=3 inside kamailio.cfg, do you see any log messages that can help in identifying why it fails?
Cheers, Daniel
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.comhttp://www.asipto.com
Kamailio World Conference - www.kamailioworld.comhttp://www.kamailioworld.com
On Oct 25, 2017, at 9:27 AM, Francisco Valentin Vinagrero francisco.valentin.vinagrero@cern.ch wrote:
Hello Daniel,
Thanks for your answer.
I don’t see much in the debug logs. Except the SSL verification error, the rest looks like the normal SSL handshake and the TCP connection setup:
DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa7edc0, 8, -1, 0x10) fd_no=2 called DEBUG: <core> [tcp_read.c:1490]: release_tcpconn(): releasing con 0x7f9191b1ade0, state -2, fd=8, id=8 ([<SfB IP1>]:56267 -> [<SfB IP1>]:5061) DEBUG: <core> [tcp_read.c:1491]: release_tcpconn(): extra_data 0x7f9191b39318 DEBUG: <core> [tcp_main.c:3243]: handle_tcp_child(): reader response= 7f9191b1ade0, -2 from 0 DEBUG: tls [tls_server.c:663]: tls_h_close(): Closing SSL connection 0x7f9191b39318 DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: <SfB IP1> DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56269, type 3 DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 3769:3996:3198, 9 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7f9191b1ade0), fd_no=20 DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=21 called DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1 DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 1 12(4808) for activity on [tls:<LOCAL IP>:5061], 0x7f9191b1ade0 DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7f9191b1ade0, fd=8 DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f9191861e98 ctx 0x7f9191887a10 sn []) DEBUG: tls [tls_domain.c:703]: sr_ssl_ctx_info_callback(): SSL handshake started DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=6692 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#026#003#003 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa7edc0, 8, 2, 0x7f9191b1ade0), fd_no=1 DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=7 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#025#003#003 ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
Maybe you can see some hint there that I don’t see?
Cheers, Francisco.
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com mailto:miconda@gmail.com] Sent: Wednesday, October 25, 2017 14:50 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>; Francisco Valentin Vinagrero <francisco.valentin.vinagrero@cern.ch mailto:francisco.valentin.vinagrero@cern.ch> Subject: Re: [SR-Users] Mutual TLS with Skype for Business 2015
Hello,
On 25.10.17 11:32, Francisco Valentin Vinagrero wrote: Hello,
I’m trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster.
I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I’m just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors:
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file)
[server:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate’s Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs
[client:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem
When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved.
You’ve verified this by using s_client? Getting a TLS session established with s_client first will likely shed light on a possible misconfiguration.
--FC
The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate.
As the only difference between UM and Skype’s Mediation is the certificate’s Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this?
afaik, the certificate validation is done by the libssl, kamailio is not doing much in this respect and no dns query inside kamailio tls module. Maybe some parameters must be set when asking for validation.
If you run with debug=3 inside kamailio.cfg, do you see any log messages that can help in identifying why it fails?
Cheers, Daniel
-- Daniel-Constantin Mierla www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com http://www.asipto.com/ Kamailio World Conference - www.kamailioworld.com http://www.kamailioworld.com/_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Frank,
Yes, I have tried s_client with a special ca_file (the same I’m using in my tls.cfg). I obtain for both the UM and Skype hosts/ alias : “Verify return code: 0 (ok)”.
I have also tried to download the public certificate first and then verify it offline with:
openssl verify -verbose -CAfile myCAfile.pem remote.pem
It all looks ok…
One weird thing is that when checking the tls.options through kamcmd, I always get an empty ca_list:
kamcmd tls.options { … ca_list: … }
Cheers, Francisco. From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Frank Carmickle Sent: Wednesday, October 25, 2017 17:01 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Mutual TLS with Skype for Business 2015
On Oct 25, 2017, at 9:27 AM, Francisco Valentin Vinagrero <francisco.valentin.vinagrero@cern.chmailto:francisco.valentin.vinagrero@cern.ch> wrote:
Hello Daniel,
Thanks for your answer.
I don’t see much in the debug logs. Except the SSL verification error, the rest looks like the normal SSL handshake and the TCP connection setup:
DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa7edc0, 8, -1, 0x10) fd_no=2 called DEBUG: <core> [tcp_read.c:1490]: release_tcpconn(): releasing con 0x7f9191b1ade0, state -2, fd=8, id=8 ([<SfB IP1>]:56267 -> [<SfB IP1>]:5061) DEBUG: <core> [tcp_read.c:1491]: release_tcpconn(): extra_data 0x7f9191b39318 DEBUG: <core> [tcp_main.c:3243]: handle_tcp_child(): reader response= 7f9191b1ade0, -2 from 0 DEBUG: tls [tls_server.c:663]: tls_h_close(): Closing SSL connection 0x7f9191b39318 DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: <SfB IP1> DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56269, type 3 DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 3769:3996:3198, 9 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7f9191b1ade0), fd_no=20 DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=21 called DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1 DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 1 12(4808) for activity on [tls:<LOCAL IP>:5061], 0x7f9191b1ade0 DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7f9191b1ade0, fd=8 DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f9191861e98 ctx 0x7f9191887a10 sn []) DEBUG: tls [tls_domain.c:703]: sr_ssl_ctx_info_callback(): SSL handshake started DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=6692 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#026#003#003 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa7edc0, 8, 2, 0x7f9191b1ade0), fd_no=1 DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=7 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#025#003#003 ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
Maybe you can see some hint there that I don’t see?
Cheers, Francisco.
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, October 25, 2017 14:50 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org>; Francisco Valentin Vinagrero <francisco.valentin.vinagrero@cern.chmailto:francisco.valentin.vinagrero@cern.ch> Subject: Re: [SR-Users] Mutual TLS with Skype for Business 2015
Hello,
On 25.10.17 11:32, Francisco Valentin Vinagrero wrote: Hello,
I’m trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster.
I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I’m just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors:
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file)
[server:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate’s Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs
[client:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem
When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved.
You’ve verified this by using s_client? Getting a TLS session established with s_client first will likely shed light on a possible misconfiguration.
--FC
The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate.
As the only difference between UM and Skype’s Mediation is the certificate’s Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this?
afaik, the certificate validation is done by the libssl, kamailio is not doing much in this respect and no dns query inside kamailio tls module. Maybe some parameters must be set when asking for validation.
If you run with debug=3 inside kamailio.cfg, do you see any log messages that can help in identifying why it fails?
Cheers, Daniel
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.comhttp://www.asipto.com/
Kamailio World Conference - www.kamailioworld.comhttp://www.kamailioworld.com/ _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
On 26.10.17 09:41, Francisco Valentin Vinagrero wrote:
Hi Frank,
Yes, I have tried s_client with a special ca_file (the same I’m using in my tls.cfg). I obtain for both the UM and Skype hosts/ alias : “Verify return code: 0 (ok)”.
I have also tried to download the public certificate first and then verify it offline with:
openssl verify -verbose -CAfile myCAfile.pem remote.pem
It all looks ok…
One weird thing is that when checking the tls.options through kamcmd, I always get an empty ca_list:
kamcmd tls.options
{
…
ca_list:
…
}
I think this is printing only the values for the structure set with modparam. At startup should be some info messages printing what is read from tls.cfg.
Eventually you can try setting ca_list via modparam and see how it goes, maybe it is not used properly from tls.cfg and this will help to figure out better if there is an issue...
Cheers, Daniel
Cheers, Francisco.
*From:*sr-users [mailto:sr-users-bounces@lists.kamailio.org] *On Behalf Of *Frank Carmickle *Sent:* Wednesday, October 25, 2017 17:01 *To:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Subject:* Re: [SR-Users] Mutual TLS with Skype for Business 2015
On Oct 25, 2017, at 9:27 AM, Francisco Valentin Vinagrero <francisco.valentin.vinagrero@cern.ch <mailto:francisco.valentin.vinagrero@cern.ch>> wrote: Hello Daniel, Thanks for your answer. I don’t see much in the debug logs. Except the SSL verification error, the rest looks like the normal SSL handshake and the TCP connection setup: DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa7edc0, 8, -1, 0x10) fd_no=2 called DEBUG: <core> [tcp_read.c:1490]: release_tcpconn(): releasing con 0x7f9191b1ade0, state -2, fd=8, id=8 ([<SfB IP1>]:56267 -> [<SfB IP1>]:5061) DEBUG: <core> [tcp_read.c:1491]: release_tcpconn(): extra_data 0x7f9191b39318 DEBUG: <core> [tcp_main.c:3243]: handle_tcp_child(): reader response= 7f9191b1ade0, -2 from 0 DEBUG: tls [tls_server.c:663]: tls_h_close(): Closing SSL connection 0x7f9191b39318 DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: <SfB IP1> DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56269, type 3 DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 3769:3996:3198, 9 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7f9191b1ade0), fd_no=20 DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=21 called DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1 DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 1 12(4808) for activity on [tls:<LOCAL IP>:5061], 0x7f9191b1ade0 DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7f9191b1ade0, fd=8 DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f9191861e98 ctx 0x7f9191887a10 sn []) DEBUG: tls [tls_domain.c:703]: sr_ssl_ctx_info_callback(): SSL handshake started DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=6692 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#026#003#003 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa7edc0, 8, 2, 0x7f9191b1ade0), fd_no=1 DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=7 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#025#003#003 ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading Maybe you can see some hint there that I don’t see? Cheers, Francisco. *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com] *Sent:* Wednesday, October 25, 2017 14:50 *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>; Francisco Valentin Vinagrero <francisco.valentin.vinagrero@cern.ch <mailto:francisco.valentin.vinagrero@cern.ch>> *Subject:* Re: [SR-Users] Mutual TLS with Skype for Business 2015 Hello, On 25.10.17 11:32, Francisco Valentin Vinagrero wrote: Hello, I’m trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster. I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I’m just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file) [server:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate’s Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs [client:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved.You’ve verified this by using s_client? Getting a TLS session established with s_client first will likely shed light on a possible misconfiguration.
--FC
The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate. As the only difference between UM and Skype’s Mediation is the certificate’s Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this? afaik, the certificate validation is done by the libssl, kamailio is not doing much in this respect and no dns query inside kamailio tls module. Maybe some parameters must be set when asking for validation. If you run with debug=3 inside kamailio.cfg, do you see any log messages that can help in identifying why it fails? Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com <http://www.asipto.com/> Kamailio World Conference - www.kamailioworld.com <http://www.kamailioworld.com/> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi All.
Francisco, according to your tls configuration your kamailio must request and validate SfB client certificate, as SfB acting as client in your case with OPTIONS.
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed This line means that kamailio fails to verify client certificate which provides to it by SfB.
Do you sure that in "ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem" present all necessary certificates to verify SfB client certificate?
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-10-26 12:51 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 26.10.17 09:41, Francisco Valentin Vinagrero wrote:
Hi Frank,
Yes, I have tried s_client with a special ca_file (the same I’m using in my tls.cfg). I obtain for both the UM and Skype hosts/ alias : “Verify return code: 0 (ok)”.
I have also tried to download the public certificate first and then verify it offline with:
openssl verify -verbose -CAfile myCAfile.pem remote.pem
It all looks ok…
One weird thing is that when checking the tls.options through kamcmd, I always get an empty ca_list:
kamcmd tls.options
{
… ca_list: …}
I think this is printing only the values for the structure set with modparam. At startup should be some info messages printing what is read from tls.cfg.
Eventually you can try setting ca_list via modparam and see how it goes, maybe it is not used properly from tls.cfg and this will help to figure out better if there is an issue...
Cheers, Daniel
Cheers, Francisco.
*From:* sr-users [mailto:sr-users-bounces@lists.kamailio.org sr-users-bounces@lists.kamailio.org] *On Behalf Of *Frank Carmickle *Sent:* Wednesday, October 25, 2017 17:01 *To:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org sr-users@lists.kamailio.org *Subject:* Re: [SR-Users] Mutual TLS with Skype for Business 2015
On Oct 25, 2017, at 9:27 AM, Francisco Valentin Vinagrero < francisco.valentin.vinagrero@cern.ch> wrote:
Hello Daniel,
Thanks for your answer.
I don’t see much in the debug logs. Except the SSL verification error, the rest looks like the normal SSL handshake and the TCP connection setup:
DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa7edc0, 8, -1, 0x10) fd_no=2 called
DEBUG: <core> [tcp_read.c:1490]: release_tcpconn(): releasing con 0x7f9191b1ade0, state -2, fd=8, id=8 ([<SfB IP1>]:56267 -> [<SfB IP1>]:5061)
DEBUG: <core> [tcp_read.c:1491]: release_tcpconn(): extra_data 0x7f9191b39318
DEBUG: <core> [tcp_main.c:3243]: handle_tcp_child(): reader response= 7f9191b1ade0, -2 from 0
DEBUG: tls [tls_server.c:663]: tls_h_close(): Closing SSL connection 0x7f9191b39318
DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: <SfB IP1>
DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56269, type 3
DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 3769:3996:3198, 9
DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7f9191b1ade0), fd_no=20
DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=21 called
DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1
DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 1 12(4808) for activity on [tls:<LOCAL IP>:5061], 0x7f9191b1ade0
DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7f9191b1ade0, fd=8
DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization
DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f9191861e98 ctx 0x7f9191887a10 sn [])
DEBUG: tls [tls_domain.c:703]: sr_ssl_ctx_info_callback(): SSL handshake started
DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending...
DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=6692 fd=8
DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#026#003#003
DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa7edc0, 8, 2, 0x7f9191b1ade0), fd_no=1
DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending...
DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=7 fd=8
DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#025#003#003
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
Maybe you can see some hint there that I don’t see?
Cheers, Francisco.
*From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com miconda@gmail.com] *Sent:* Wednesday, October 25, 2017 14:50 *To:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; Francisco Valentin Vinagrero francisco.valentin.vinagrero@cern.ch *Subject:* Re: [SR-Users] Mutual TLS with Skype for Business 2015
Hello,
On 25.10.17 11:32, Francisco Valentin Vinagrero wrote:
Hello,
I’m trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster.
I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I’m just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors:
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file)
[server:default]
method = TLSv1+
verify_certificate = yes
require_certificate = yes
private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem
certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate’s Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names
ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs
[client:default]
method = TLSv1+
verify_certificate = yes
require_certificate = yes
private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem
certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem
ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem
When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved.
You’ve verified this by using s_client? Getting a TLS session established with s_client first will likely shed light on a possible misconfiguration.
--FC
The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate.
As the only difference between UM and Skype’s Mediation is the certificate’s Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this?
afaik, the certificate validation is done by the libssl, kamailio is not doing much in this respect and no dns query inside kamailio tls module. Maybe some parameters must be set when asking for validation.
If you run with debug=3 inside kamailio.cfg, do you see any log messages that can help in identifying why it fails?
Cheers, Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com Kamailio World Conference - www.kamailioworld.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Sergey,
Yes, I have tried to validate with openssl and the same ca_list file and it gets validated.
Also the other Unified Messaging host that I mentioned gets verified with the same configuration, and its certificate it is signed by the same CA. The only difference is that this other host is not part of the mediation pool and the subject of the certificate is the FQDN, while for the Skype pool the subject is the DNS alias and the different FQDNs are part of the SANs, not the subject.
I would expect myself that everything that gets verified with openssl would get verified by the TLS module, but there must be something I’m missing.
Cheers, Francisco.
From: Sergey Basov [mailto:sergey.v.basov@gmail.com] Sent: Thursday, October 26, 2017 12:48 To: Daniel-Constantin Mierla miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Francisco Valentin Vinagrero francisco.valentin.vinagrero@cern.ch Subject: Re: [SR-Users] Mutual TLS with Skype for Business 2015
Hi All. Francisco, according to your tls configuration your kamailio must request and validate SfB client certificate, as SfB acting as client in your case with OPTIONS.
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed This line means that kamailio fails to verify client certificate which provides to it by SfB. Do you sure that in "ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem" present all necessary certificates to verify SfB client certificate?
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.commailto:sergey.v.basov@gmail.com
2017-10-26 12:51 GMT+03:00 Daniel-Constantin Mierla <miconda@gmail.commailto:miconda@gmail.com>:
Hello,
On 26.10.17 09:41, Francisco Valentin Vinagrero wrote: Hi Frank,
Yes, I have tried s_client with a special ca_file (the same I’m using in my tls.cfg). I obtain for both the UM and Skype hosts/ alias : “Verify return code: 0 (ok)”.
I have also tried to download the public certificate first and then verify it offline with:
openssl verify -verbose -CAfile myCAfile.pem remote.pem
It all looks ok…
One weird thing is that when checking the tls.options through kamcmd, I always get an empty ca_list:
kamcmd tls.options { … ca_list: … }
I think this is printing only the values for the structure set with modparam. At startup should be some info messages printing what is read from tls.cfg.
Eventually you can try setting ca_list via modparam and see how it goes, maybe it is not used properly from tls.cfg and this will help to figure out better if there is an issue...
Cheers, Daniel
Cheers, Francisco. From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Frank Carmickle Sent: Wednesday, October 25, 2017 17:01 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Subject: Re: [SR-Users] Mutual TLS with Skype for Business 2015
On Oct 25, 2017, at 9:27 AM, Francisco Valentin Vinagrero <francisco.valentin.vinagrero@cern.chmailto:francisco.valentin.vinagrero@cern.ch> wrote:
Hello Daniel,
Thanks for your answer.
I don’t see much in the debug logs. Except the SSL verification error, the rest looks like the normal SSL handshake and the TCP connection setup:
DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa7edc0, 8, -1, 0x10) fd_no=2 called DEBUG: <core> [tcp_read.c:1490]: release_tcpconn(): releasing con 0x7f9191b1ade0, state -2, fd=8, id=8 ([<SfB IP1>]:56267 -> [<SfB IP1>]:5061) DEBUG: <core> [tcp_read.c:1491]: release_tcpconn(): extra_data 0x7f9191b39318 DEBUG: <core> [tcp_main.c:3243]: handle_tcp_child(): reader response= 7f9191b1ade0, -2 from 0 DEBUG: tls [tls_server.c:663]: tls_h_close(): Closing SSL connection 0x7f9191b39318 DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: <SfB IP1> DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56269, type 3 DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 3769:3996:3198, 9 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7f9191b1ade0), fd_no=20 DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=21 called DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1 DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 1 12(4808) for activity on [tls:<LOCAL IP>:5061], 0x7f9191b1ade0 DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7f9191b1ade0, fd=8 DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f9191861e98 ctx 0x7f9191887a10 sn []) DEBUG: tls [tls_domain.c:703]: sr_ssl_ctx_info_callback(): SSL handshake started DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=6692 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#026#003#003 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa7edc0, 8, 2, 0x7f9191b1ade0), fd_no=1 DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f9191b1ade0 n=7 fd=8 DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf=#012#025#003#003 ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
Maybe you can see some hint there that I don’t see?
Cheers, Francisco.
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, October 25, 2017 14:50 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org>; Francisco Valentin Vinagrero <francisco.valentin.vinagrero@cern.chmailto:francisco.valentin.vinagrero@cern.ch> Subject: Re: [SR-Users] Mutual TLS with Skype for Business 2015
Hello,
On 25.10.17 11:32, Francisco Valentin Vinagrero wrote: Hello,
I’m trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster.
I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I’m just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors:
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file)
[server:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate’s Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs
[client:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem
When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved.
You’ve verified this by using s_client? Getting a TLS session established with s_client first will likely shed light on a possible misconfiguration.
--FC
The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate.
As the only difference between UM and Skype’s Mediation is the certificate’s Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this?
afaik, the certificate validation is done by the libssl, kamailio is not doing much in this respect and no dns query inside kamailio tls module. Maybe some parameters must be set when asking for validation.
If you run with debug=3 inside kamailio.cfg, do you see any log messages that can help in identifying why it fails?
Cheers, Daniel
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.comhttp://www.asipto.com/
Kamailio World Conference - www.kamailioworld.comhttp://www.kamailioworld.com/ _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.comhttp://www.asipto.com
Kamailio World Conference - www.kamailioworld.comhttp://www.kamailioworld.com
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi all,
I’m still stuck with this even if I built a new VM to avoid any buggy configuration.
Some thoughts on this:
1. I have tried to change verify_certificate = no on my server section of tls.cfg, so ideally the remote certificate will not be verified, but this is not changing anything.
2. My Kamailio cluster is part of a DNS alias, but the alias is defined as alias=<myalias>:5061 in the Kamailio.cfg. Could this be affecting somehow the verification? My tls.cfg only has server:default and client:default section.
3. Every time I reload the configuration, the TLS info and debug messages for client and server are coherent with what I would expect from my tls.cfg:
INFO: tls [tls_domain.c:278]: fill_missing(): TLSs<default>: tls_method=20
INFO: tls [tls_domain.c:290]: fill_missing(): TLSs<default>: certificate='/usr/local/etc/kamailio/tls/myCert.pem'
INFO: tls [tls_domain.c:297]: fill_missing(): TLSs<default>: ca_list='/usr/local/etc/kamailio/tls/myCAfile.pem'
INFO: tls [tls_domain.c:304]: fill_missing(): TLSs<default>: crl='(null)'
INFO: tls [tls_domain.c:308]: fill_missing(): TLSs<default>: require_certificate=1
INFO: tls [tls_domain.c:315]: fill_missing(): TLSs<default>: cipher_list='(null)'
INFO: tls [tls_domain.c:322]: fill_missing(): TLSs<default>: private_key='/usr/local/etc/kamailio/tls/myKey.pem'
INFO: tls [tls_domain.c:326]: fill_missing(): TLSs<default>: verify_certificate=1
INFO: tls [tls_domain.c:329]: fill_missing(): TLSs<default>: verify_depth=9
DEBUG: tls [tls_domain.c:968]: fix_domain(): using tls methods range: 20
DEBUG: tls [tls_domain.c:566]: load_crl(): TLSs<default>: No CRL configured
INFO: tls [tls_domain.c:658]: set_verification(): TLSs<default>: Client MUST present valid certificate
INFO: tls [tls_domain.c:278]: fill_missing(): TLSc<default>: tls_method=20
INFO: tls [tls_domain.c:290]: fill_missing(): TLSc<default>: certificate='/usr/local/etc/kamailio/tls/myCert.pem'
INFO: tls [tls_domain.c:297]: fill_missing(): TLSc<default>: ca_list='/usr/local/etc/kamailio/tls/myCAfile.pem'
INFO: tls [tls_domain.c:304]: fill_missing(): TLSc<default>: crl='(null)'
INFO: tls [tls_domain.c:308]: fill_missing(): TLSc<default>: require_certificate=1
INFO: tls [tls_domain.c:315]: fill_missing(): TLSc<default>: cipher_list='(null)'
INFO: tls [tls_domain.c:322]: fill_missing(): TLSc<default>: private_key='/usr/local/etc/kamailio/tls/myKey.pem'
INFO: tls [tls_domain.c:326]: fill_missing(): TLSc<default>: verify_certificate=1
INFO: tls [tls_domain.c:329]: fill_missing(): TLSc<default>: verify_depth=9
DEBUG: tls [tls_domain.c:968]: fix_domain(): using tls methods range: 20
DEBUG: tls [tls_domain.c:566]: load_crl(): TLSc<default>: No CRL configured
INFO: tls [tls_domain.c:658]: set_verification(): TLSc<default>: Server MUST present valid certificate
DEBUG: tls [tls_domain.c:1119]: load_private_key(): TLSs<default>: Key '/usr/local/etc/kamailio/tls/myKey.pem' successfuly loaded
DEBUG: tls [tls_domain.c:1119]: load_private_key(): TLSc<default>: Key '/usr/local/etc/kamailio/tls/myKey.pem' successfuly loaded
DEBUG: tls [tls_rpc.c:82]: tls_reload(): TLS configuration successfuly loaded
4. When the first handshake begins after reloading, it goes to the TLSs default domain:
DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 188.185.115.181
DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56404, type 3
DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 2351:1920:1122, 168
DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7ff243558420), fd_no=21
DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=22 called
DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1
DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 2 13(13472) for activity on [tls:<myLocalIP>:5061], 0x7ff243558420
DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7ff243558420, fd=8
DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization
DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7ff242d79b40 ctx 0x7ff2430cc448 sn [])
5. I wonder if anyone has configured this with Skype for Business 2015 lately? Any clue?
Cheers, Francisco.
Hello,
On 27.10.17 17:12, Francisco Valentin Vinagrero wrote:
Hi all,
I’m still stuck with this even if I built a new VM to avoid any buggy configuration.
Some thoughts on this:
1. I have tried to change verify_certificate = no on my server section of tls.cfg, so ideally the remote certificate will not be verified, but this is not changing anything.
to understand properly, even if you have verify_certificate = no, the certificated is verified and fails?
Otherwise I don't have access to Skype for Business 2015, so I cannot troubleshoot much.
Cheers, Daniel
2. My Kamailio cluster is part of a DNS alias, but the alias is defined as alias=<myalias>:5061 in the Kamailio.cfg. Could this be affecting somehow the verification? My tls.cfg only has server:default and client:default section.
3. Every time I reload the configuration, the TLS info and debug messages for client and server are coherent with what I would expect from my tls.cfg:
INFO: tls [tls_domain.c:278]: fill_missing(): TLSs<default>: tls_method=20
INFO: tls [tls_domain.c:290]: fill_missing(): TLSs<default>: certificate='/usr/local/etc/kamailio/tls/myCert.pem'
INFO: tls [tls_domain.c:297]: fill_missing(): TLSs<default>: ca_list='/usr/local/etc/kamailio/tls/myCAfile.pem'
INFO: tls [tls_domain.c:304]: fill_missing(): TLSs<default>: crl='(null)'
INFO: tls [tls_domain.c:308]: fill_missing(): TLSs<default>: require_certificate=1
INFO: tls [tls_domain.c:315]: fill_missing(): TLSs<default>: cipher_list='(null)'
INFO: tls [tls_domain.c:322]: fill_missing(): TLSs<default>: private_key='/usr/local/etc/kamailio/tls/myKey.pem'
INFO: tls [tls_domain.c:326]: fill_missing(): TLSs<default>: verify_certificate=1
INFO: tls [tls_domain.c:329]: fill_missing(): TLSs<default>: verify_depth=9
DEBUG: tls [tls_domain.c:968]: fix_domain(): using tls methods range: 20
DEBUG: tls [tls_domain.c:566]: load_crl(): TLSs<default>: No CRL configured
INFO: tls [tls_domain.c:658]: set_verification(): TLSs<default>: Client MUST present valid certificate
INFO: tls [tls_domain.c:278]: fill_missing(): TLSc<default>: tls_method=20
INFO: tls [tls_domain.c:290]: fill_missing(): TLSc<default>: certificate='/usr/local/etc/kamailio/tls/myCert.pem'
INFO: tls [tls_domain.c:297]: fill_missing(): TLSc<default>: ca_list='/usr/local/etc/kamailio/tls/myCAfile.pem'
INFO: tls [tls_domain.c:304]: fill_missing(): TLSc<default>: crl='(null)'
INFO: tls [tls_domain.c:308]: fill_missing(): TLSc<default>: require_certificate=1
INFO: tls [tls_domain.c:315]: fill_missing(): TLSc<default>: cipher_list='(null)'
INFO: tls [tls_domain.c:322]: fill_missing(): TLSc<default>: private_key='/usr/local/etc/kamailio/tls/myKey.pem'
INFO: tls [tls_domain.c:326]: fill_missing(): TLSc<default>: verify_certificate=1
INFO: tls [tls_domain.c:329]: fill_missing(): TLSc<default>: verify_depth=9
DEBUG: tls [tls_domain.c:968]: fix_domain(): using tls methods range: 20
DEBUG: tls [tls_domain.c:566]: load_crl(): TLSc<default>: No CRL configured
INFO: tls [tls_domain.c:658]: set_verification(): TLSc<default>: Server MUST present valid certificate
DEBUG: tls [tls_domain.c:1119]: load_private_key(): TLSs<default>: Key '/usr/local/etc/kamailio/tls/myKey.pem' successfuly loaded
DEBUG: tls [tls_domain.c:1119]: load_private_key(): TLSc<default>: Key '/usr/local/etc/kamailio/tls/myKey.pem' successfuly loaded
DEBUG: tls [tls_rpc.c:82]: tls_reload(): TLS configuration successfuly loaded
4. When the first handshake begins after reloading, it goes to the TLSs default domain:
DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 188.185.115.181
DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56404, type 3
DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 2351:1920:1122, 168
DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7ff243558420), fd_no=21
DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=22 called
DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1
DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 2 13(13472) for activity on [tls:<myLocalIP>:5061], 0x7ff243558420
DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7ff243558420, fd=8
DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization
DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7ff242d79b40 ctx 0x7ff2430cc448 sn [])
5. I wonder if anyone has configured this with Skype for Business 2015 lately? Any clue?
Cheers, Francisco.
Francisco,
Please share your s_client command and output that is connecting appropriately.
--FC
On Oct 30, 2017, at 1:43 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 27.10.17 17:12, Francisco Valentin Vinagrero wrote:
Hi all,
I’m still stuck with this even if I built a new VM to avoid any buggy configuration.
Some thoughts on this:
I have tried to change verify_certificate = no on my server section of tls.cfg, so ideally the remote certificate will not be verified, but this is not changing anything.to understand properly, even if you have verify_certificate = no, the certificated is verified and fails?
Otherwise I don't have access to Skype for Business 2015, so I cannot troubleshoot much.
Cheers, Daniel
My Kamailio cluster is part of a DNS alias, but the alias is defined as alias=<myalias>:5061 in the Kamailio.cfg. Could this be affecting somehow the verification? My tls.cfg only has server:default and client:default section.Every time I reload the configuration, the TLS info and debug messages for client and server are coherent with what I would expect from my tls.cfg:INFO: tls [tls_domain.c:278]: fill_missing(): TLSs<default>: tls_method=20 INFO: tls [tls_domain.c:290]: fill_missing(): TLSs<default>: certificate='/usr/local/etc/kamailio/tls/myCert.pem' INFO: tls [tls_domain.c:297]: fill_missing(): TLSs<default>: ca_list='/usr/local/etc/kamailio/tls/myCAfile.pem' INFO: tls [tls_domain.c:304]: fill_missing(): TLSs<default>: crl='(null)' INFO: tls [tls_domain.c:308]: fill_missing(): TLSs<default>: require_certificate=1 INFO: tls [tls_domain.c:315]: fill_missing(): TLSs<default>: cipher_list='(null)' INFO: tls [tls_domain.c:322]: fill_missing(): TLSs<default>: private_key='/usr/local/etc/kamailio/tls/myKey.pem' INFO: tls [tls_domain.c:326]: fill_missing(): TLSs<default>: verify_certificate=1 INFO: tls [tls_domain.c:329]: fill_missing(): TLSs<default>: verify_depth=9 DEBUG: tls [tls_domain.c:968]: fix_domain(): using tls methods range: 20 DEBUG: tls [tls_domain.c:566]: load_crl(): TLSs<default>: No CRL configured INFO: tls [tls_domain.c:658]: set_verification(): TLSs<default>: Client MUST present valid certificate INFO: tls [tls_domain.c:278]: fill_missing(): TLSc<default>: tls_method=20 INFO: tls [tls_domain.c:290]: fill_missing(): TLSc<default>: certificate='/usr/local/etc/kamailio/tls/myCert.pem' INFO: tls [tls_domain.c:297]: fill_missing(): TLSc<default>: ca_list='/usr/local/etc/kamailio/tls/myCAfile.pem' INFO: tls [tls_domain.c:304]: fill_missing(): TLSc<default>: crl='(null)' INFO: tls [tls_domain.c:308]: fill_missing(): TLSc<default>: require_certificate=1 INFO: tls [tls_domain.c:315]: fill_missing(): TLSc<default>: cipher_list='(null)' INFO: tls [tls_domain.c:322]: fill_missing(): TLSc<default>: private_key='/usr/local/etc/kamailio/tls/myKey.pem' INFO: tls [tls_domain.c:326]: fill_missing(): TLSc<default>: verify_certificate=1 INFO: tls [tls_domain.c:329]: fill_missing(): TLSc<default>: verify_depth=9 DEBUG: tls [tls_domain.c:968]: fix_domain(): using tls methods range: 20 DEBUG: tls [tls_domain.c:566]: load_crl(): TLSc<default>: No CRL configured INFO: tls [tls_domain.c:658]: set_verification(): TLSc<default>: Server MUST present valid certificate DEBUG: tls [tls_domain.c:1119]: load_private_key(): TLSs<default>: Key '/usr/local/etc/kamailio/tls/myKey.pem' successfuly loaded DEBUG: tls [tls_domain.c:1119]: load_private_key(): TLSc<default>: Key '/usr/local/etc/kamailio/tls/myKey.pem' successfuly loaded DEBUG: tls [tls_rpc.c:82]: tls_reload(): TLS configuration successfuly loaded
When the first handshake begins after reloading, it goes to the TLSs default domain:DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 188.185.115.181 DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56404, type 3 DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 2351:1920:1122, 168 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7ff243558420), fd_no=21 DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=22 called DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1 DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 2 13(13472) for activity on [tls:<myLocalIP>:5061], 0x7ff243558420 DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7ff243558420, fd=8 DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7ff242d79b40 ctx 0x7ff2430cc448 sn [])
I wonder if anyone has configured this with Skype for Business 2015 lately? Any clue?Cheers, Francisco.
-- Daniel-Constantin Mierla www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com http://www.asipto.com/ Kamailio World Conference - www.kamailioworld.com http://www.kamailioworld.com/_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Frank and all,
After digging deeper with the Skype for Business team, we found that there was a misconfiguration on their side. The SfB server was using a self-signed certificate for the client connections, while I was able to verify their server certificate.
This was automatically decided by the Skype server because the certificate template was missing an obscure field…..just Microsoft things I guess….¯_(ツ)_/¯
Thanks for the help anyway!
Cheers, Francisco.
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Frank Carmickle Sent: Monday, October 30, 2017 18:51 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Mutual TLS with Skype for Business 2015
Francisco,
Please share your s_client command and output that is connecting appropriately.
--FC
On Oct 30, 2017, at 1:43 PM, Daniel-Constantin Mierla <miconda@gmail.commailto:miconda@gmail.com> wrote:
Hello,
On 27.10.17 17:12, Francisco Valentin Vinagrero wrote: Hi all,
I’m still stuck with this even if I built a new VM to avoid any buggy configuration.
Some thoughts on this:
1. I have tried to change verify_certificate = no on my server section of tls.cfg, so ideally the remote certificate will not be verified, but this is not changing anything. to understand properly, even if you have verify_certificate = no, the certificated is verified and fails?
Otherwise I don't have access to Skype for Business 2015, so I cannot troubleshoot much.
Cheers, Daniel
2. My Kamailio cluster is part of a DNS alias, but the alias is defined as alias=<myalias>:5061 in the Kamailio.cfg. Could this be affecting somehow the verification? My tls.cfg only has server:default and client:default section.
3. Every time I reload the configuration, the TLS info and debug messages for client and server are coherent with what I would expect from my tls.cfg:
INFO: tls [tls_domain.c:278]: fill_missing(): TLSs<default>: tls_method=20 INFO: tls [tls_domain.c:290]: fill_missing(): TLSs<default>: certificate='/usr/local/etc/kamailio/tls/myCert.pem' INFO: tls [tls_domain.c:297]: fill_missing(): TLSs<default>: ca_list='/usr/local/etc/kamailio/tls/myCAfile.pem' INFO: tls [tls_domain.c:304]: fill_missing(): TLSs<default>: crl='(null)' INFO: tls [tls_domain.c:308]: fill_missing(): TLSs<default>: require_certificate=1 INFO: tls [tls_domain.c:315]: fill_missing(): TLSs<default>: cipher_list='(null)' INFO: tls [tls_domain.c:322]: fill_missing(): TLSs<default>: private_key='/usr/local/etc/kamailio/tls/myKey.pem' INFO: tls [tls_domain.c:326]: fill_missing(): TLSs<default>: verify_certificate=1 INFO: tls [tls_domain.c:329]: fill_missing(): TLSs<default>: verify_depth=9 DEBUG: tls [tls_domain.c:968]: fix_domain(): using tls methods range: 20 DEBUG: tls [tls_domain.c:566]: load_crl(): TLSs<default>: No CRL configured INFO: tls [tls_domain.c:658]: set_verification(): TLSs<default>: Client MUST present valid certificate INFO: tls [tls_domain.c:278]: fill_missing(): TLSc<default>: tls_method=20 INFO: tls [tls_domain.c:290]: fill_missing(): TLSc<default>: certificate='/usr/local/etc/kamailio/tls/myCert.pem' INFO: tls [tls_domain.c:297]: fill_missing(): TLSc<default>: ca_list='/usr/local/etc/kamailio/tls/myCAfile.pem' INFO: tls [tls_domain.c:304]: fill_missing(): TLSc<default>: crl='(null)' INFO: tls [tls_domain.c:308]: fill_missing(): TLSc<default>: require_certificate=1 INFO: tls [tls_domain.c:315]: fill_missing(): TLSc<default>: cipher_list='(null)' INFO: tls [tls_domain.c:322]: fill_missing(): TLSc<default>: private_key='/usr/local/etc/kamailio/tls/myKey.pem' INFO: tls [tls_domain.c:326]: fill_missing(): TLSc<default>: verify_certificate=1 INFO: tls [tls_domain.c:329]: fill_missing(): TLSc<default>: verify_depth=9 DEBUG: tls [tls_domain.c:968]: fix_domain(): using tls methods range: 20 DEBUG: tls [tls_domain.c:566]: load_crl(): TLSc<default>: No CRL configured INFO: tls [tls_domain.c:658]: set_verification(): TLSc<default>: Server MUST present valid certificate DEBUG: tls [tls_domain.c:1119]: load_private_key(): TLSs<default>: Key '/usr/local/etc/kamailio/tls/myKey.pem' successfuly loaded DEBUG: tls [tls_domain.c:1119]: load_private_key(): TLSc<default>: Key '/usr/local/etc/kamailio/tls/myKey.pem' successfuly loaded DEBUG: tls [tls_rpc.c:82]: tls_reload(): TLS configuration successfuly loaded
4. When the first handshake begins after reloading, it goes to the TLSs default domain:
DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 188.185.115.181 DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 56404, type 3 DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 2351:1920:1122, 168 DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0xa25be0, 30, 2, 0x7ff243558420), fd_no=21 DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa25be0, 30, -1, 0x0) fd_no=22 called DEBUG: <core> [tcp_main.c:4131]: handle_tcpconn_ev(): sending to child, events 1 DEBUG: <core> [tcp_main.c:3813]: send2child(): selected tcp worker 2 13(13472) for activity on [tls:<myLocalIP>:5061], 0x7ff243558420 DEBUG: <core> [tcp_read.c:1566]: handle_io(): received n=8 con=0x7ff243558420, fd=8 DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7ff242d79b40 ctx 0x7ff2430cc448 sn [])
5. I wonder if anyone has configured this with Skype for Business 2015 lately? Any clue?
Cheers, Francisco.
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.comhttp://www.asipto.com/
Kamailio World Conference - www.kamailioworld.comhttp://www.kamailioworld.com/ _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Francisco Valentin Vinagrero -
Frank Carmickle -
Sergey Basov