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

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 &lt;sr-users(a)lists.kamailio.org&gt; *Subject:* Re: [SR-Users] Mutual TLS with Skype for Business 2015     On Oct 25, 2017, at 9:27 AM, Francisco Valentin Vinagrero &lt;francisco.valentin.vinagrero(a)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 &lt;sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>; Francisco Valentin Vinagrero &lt;francisco.valentin.vinagrero(a)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(a)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(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users