[SR-Users] Mutual TLS with Skype for Business 2015
Daniel-Constantin Mierla
miconda at gmail.com
Thu Oct 26 11:51:14 CEST 2017
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] *On
> Behalf Of *Frank Carmickle
> *Sent:* Wednesday, October 25, 2017 17:01
> *To:* Kamailio (SER) - Users Mailing List <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
> <mailto: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]
> *Sent:* Wednesday, October 25, 2017 14:50
> *To:* Kamailio (SER) - Users Mailing List
> <sr-users at lists.kamailio.org
> <mailto:sr-users at lists.kamailio.org>>; Francisco Valentin
> Vinagrero <francisco.valentin.vinagrero at cern.ch
> <mailto: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 <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 at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171026/8787ad4d/attachment.html>
More information about the sr-users
mailing list