[SR-Users] Mutual TLS with Skype for Business 2015

Thu Oct 26 12:48:23 CEST 2017

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 at gmail.com

2017-10-26 12:51 GMT+03:00 Daniel-Constantin Mierla <miconda at 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 at lists.kamailio.org
> <sr-users-bounces at lists.kamailio.org>] *On Behalf Of *Frank Carmickle
> *Sent:* Wednesday, October 25, 2017 17:01
> *To:* Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
> <sr-users at 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 at 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 at gmail.com
> <miconda at gmail.com>]
> *Sent:* Wednesday, October 25, 2017 14:50
> *To:* Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>;
> Francisco Valentin Vinagrero <francisco.valentin.vinagrero at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171026/a7e3fe24/attachment.html>