Hi all
Been trying to grab the TLS cert details from incoming connections, but failing :-(
So with lines just before AUTH is called like this;
if (proto == TLS) { xlog("L_INFO", "TLSDUMP $ci peer_subject : $tls_peer_subject\n");
Gets met with a log line line this;
INFO: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from 1.2.3.4:11797 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 INFO: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: 5.6.7.8:5061 INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate ... INFO: tls [tls_select.c:168]: get_cert(): Unable to retrieve peer TLS certificate from SSL structure
This is with verify_certificate and require_certificate set to no in tls.cfg
If I try and set the following in tls.cfg
[server:default] method = TLSv1.2+ verify_certificate = no require_certificate = yes
I see in the logs;
INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSs<default>: tls_method=22 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/tls-certs/cert.pem' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSs<default>: require_certificate=1 INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/tls-certs/privkey.pem' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSs<default>: verify_certificate=0 INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 NOTICE: tls [tls_domain.c:1095]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... INFO: tls [tls_domain.c:692]: set_verification(): TLSs<default>: Client MUST present valid certificate INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSc<default>: tls_method=20 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSc<default>: certificate='(null)' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSc<default>: require_certificate=1 INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSc<default>: verify_certificate=1 INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 INFO: tls [tls_domain.c:692]: set_verification(): TLSc<default>: Server MUST present valid certificate ... ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Which looks like verification is being enabled when I add require?
Would someone be kind enough to point out what I am missing please? (Assuming it’s not a bug :-)
Thanks Mark
Hello,
what is the SIP client app you used? Is it configured to use its own tls certificate when connecting to the SIP server?
Cheers, Daniel
On 02.07.20 18:51, Mark Boyce wrote:
Hi all
Been trying to grab the TLS cert details from incoming connections, but failing :-(
So with lines just before AUTH is called like this;
if (proto == TLS) { xlog("L_INFO", "TLSDUMP $ci peer_subject : $tls_peer_subject\n");
Gets met with a log line line this;
INFO: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from 1.2.3.4:11797 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 INFO: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: 5.6.7.8:5061 INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate ... INFO: tls [tls_select.c:168]: get_cert(): Unable to retrieve peer TLS certificate from SSL structure
This is with verify_certificate and require_certificate set to no in tls.cfg
If I try and set the following in tls.cfg
[server:default] method = TLSv1.2+ verify_certificate = no require_certificate = yes
I see in the logs;
INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSs<default>: tls_method=22 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/tls-certs/cert.pem' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSs<default>: *require_certificate=1* INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/tls-certs/privkey.pem' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSs<default>: *verify_certificate=0* INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 NOTICE: tls [tls_domain.c:1095]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... INFO: tls [tls_domain.c:692]: set_verification(): TLSs<default>:*Client MUST present valid certificate* INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSc<default>: tls_method=20 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSc<default>: certificate='(null)' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSc<default>: *require_certificate=1* INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSc<default>: *verify_certificate=1* INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 INFO: tls [tls_domain.c:692]: set_verification(): TLSc<default>: *Server MUST present valid certificate* ... ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Which looks like verification is being enabled when I add require?
Would someone be kind enough to point out what I am missing please? (Assuming it’s not a bug :-)
Thanks Mark -- Mark Boyce Dark Origins Ltd
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel
I’m testing with a Yealink T57W. It comes with a factory install certificate which will probably fail validation as the common name is the MAC.
I'm not trying validate the client device’s certificate just get it to offer what it has so I can check the details.
Thanks Mark
On 3 Jul 2020, at 08:38, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
what is the SIP client app you used? Is it configured to use its own tls certificate when connecting to the SIP server?
Cheers, Daniel On 02.07.20 18:51, Mark Boyce wrote:
Hi all
Been trying to grab the TLS cert details from incoming connections, but failing :-(
So with lines just before AUTH is called like this;
if (proto == TLS) { xlog("L_INFO", "TLSDUMP $ci peer_subject : $tls_peer_subject\n");
Gets met with a log line line this;
INFO: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from 1.2.3.4:11797 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 INFO: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: 5.6.7.8:5061 INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate ... INFO: tls [tls_select.c:168]: get_cert(): Unable to retrieve peer TLS certificate from SSL structure
This is with verify_certificate and require_certificate set to no in tls.cfg
If I try and set the following in tls.cfg
[server:default] method = TLSv1.2+ verify_certificate = no require_certificate = yes
I see in the logs;
INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSs<default>: tls_method=22 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/tls-certs/cert.pem' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSs<default>: require_certificate=1 INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/tls-certs/privkey.pem' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSs<default>: verify_certificate=0 INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 NOTICE: tls [tls_domain.c:1095]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... INFO: tls [tls_domain.c:692]: set_verification(): TLSs<default>: Client MUST present valid certificate INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSc<default>: tls_method=20 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSc<default>: certificate='(null)' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSc<default>: require_certificate=1 INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSc<default>: verify_certificate=1 INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 INFO: tls [tls_domain.c:692]: set_verification(): TLSc<default>: Server MUST present valid certificate ... ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Which looks like verification is being enabled when I add require?
Would someone be kind enough to point out what I am missing please? (Assuming it’s not a bug :-)
Thanks Mark -- Mark Boyce Dark Origins Ltd
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
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com/ www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla https://www.paypal.me/dcmierla
Mark
Hello,
the client has to be configured to present a certificate, and it doesn't do it based on kamailio log message:
INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate
Check the phone config to see if you can set such option. Kamailio can just see if a certificate is sent and if not reject the connection, if you have require_certificate = yes in the server profile of tls.cfg
You can eventually test with 'openssl s_client ...' to see details of client side certs in kamailio -- iirc, it has the options to specify client side certificate with -cert ... -key ...
Cheers, Daniel
On 03.07.20 09:52, Mark Boyce wrote:
Hi Daniel
I’m testing with a Yealink T57W. It comes with a factory install certificate which will probably fail validation as the common name is the MAC.
I'm not trying validate the client device’s certificate just get it to offer what it has so I can check the details.
Thanks Mark
On 3 Jul 2020, at 08:38, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
what is the SIP client app you used? Is it configured to use its own tls certificate when connecting to the SIP server?
Cheers, Daniel
On 02.07.20 18:51, Mark Boyce wrote:
Hi all
Been trying to grab the TLS cert details from incoming connections, but failing :-(
So with lines just before AUTH is called like this;
if (proto == TLS) { xlog("L_INFO", "TLSDUMP $ci peer_subject : $tls_peer_subject\n");
Gets met with a log line line this;
INFO: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from 1.2.3.4:11797 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 INFO: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: 5.6.7.8:5061 INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate ... INFO: tls [tls_select.c:168]: get_cert(): Unable to retrieve peer TLS certificate from SSL structure
This is with verify_certificate and require_certificate set to no in tls.cfg
If I try and set the following in tls.cfg
[server:default] method = TLSv1.2+ verify_certificate = no require_certificate = yes
I see in the logs;
INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSs<default>: tls_method=22 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/tls-certs/cert.pem' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSs<default>: *require_certificate=1* INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/tls-certs/privkey.pem' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSs<default>: *verify_certificate=0* INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 NOTICE: tls [tls_domain.c:1095]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... INFO: tls [tls_domain.c:692]: set_verification(): TLSs<default>:*Client MUST present valid certificate* INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSc<default>: tls_method=20 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSc<default>: certificate='(null)' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSc<default>: *require_certificate=1* INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSc<default>: *verify_certificate=1* INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 INFO: tls [tls_domain.c:692]: set_verification(): TLSc<default>: *Server MUST present valid certificate* ... ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Which looks like verification is being enabled when I add require?
Would someone be kind enough to point out what I am missing please? (Assuming it’s not a bug :-)
Thanks Mark -- Mark Boyce Dark Origins Ltd
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
Mark -- Mark Boyce Dark Origins Ltd e: mark@darkorigins.com mailto:mark@darkorigins.com t: 0345 0043 043 f: 0345 0043 044
Hi Daniel
Ah, that’s the bit I misunderstood. I thought that require_certificate would trigger mutual auth / mTLS rather than enforcing its presence.
No sign of a setting on the Yealink to send it’s certificate. Will go unpack a Cisco and see what that offers.
Thanks Mark,
On 3 Jul 2020, at 09:09, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
the client has to be configured to present a certificate, and it doesn't do it based on kamailio log message:
INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate
Check the phone config to see if you can set such option. Kamailio can just see if a certificate is sent and if not reject the connection, if you have require_certificate = yes in the server profile of tls.cfg
You can eventually test with 'openssl s_client ...' to see details of client side certs in kamailio -- iirc, it has the options to specify client side certificate with -cert ... -key ... Cheers, Daniel On 03.07.20 09:52, Mark Boyce wrote:
Hi Daniel
I’m testing with a Yealink T57W. It comes with a factory install certificate which will probably fail validation as the common name is the MAC.
I'm not trying validate the client device’s certificate just get it to offer what it has so I can check the details.
Thanks Mark
On 3 Jul 2020, at 08:38, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
what is the SIP client app you used? Is it configured to use its own tls certificate when connecting to the SIP server?
Cheers, Daniel On 02.07.20 18:51, Mark Boyce wrote:
Hi all
Been trying to grab the TLS cert details from incoming connections, but failing :-(
So with lines just before AUTH is called like this;
if (proto == TLS) { xlog("L_INFO", "TLSDUMP $ci peer_subject : $tls_peer_subject\n");
Gets met with a log line line this;
INFO: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from 1.2.3.4:11797 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 INFO: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: 5.6.7.8:5061 INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate ... INFO: tls [tls_select.c:168]: get_cert(): Unable to retrieve peer TLS certificate from SSL structure
This is with verify_certificate and require_certificate set to no in tls.cfg
If I try and set the following in tls.cfg
[server:default] method = TLSv1.2+ verify_certificate = no require_certificate = yes
I see in the logs;
INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSs<default>: tls_method=22 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/tls-certs/cert.pem' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSs<default>: require_certificate=1 INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/tls-certs/privkey.pem' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSs<default>: verify_certificate=0 INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 NOTICE: tls [tls_domain.c:1095]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... INFO: tls [tls_domain.c:692]: set_verification(): TLSs<default>: Client MUST present valid certificate INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSc<default>: tls_method=20 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSc<default>: certificate='(null)' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSc<default>: require_certificate=1 INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSc<default>: verify_certificate=1 INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 INFO: tls [tls_domain.c:692]: set_verification(): TLSc<default>: Server MUST present valid certificate ... ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Which looks like verification is being enabled when I add require?
Would someone be kind enough to point out what I am missing please? (Assuming it’s not a bug :-)
Hello,
On 03.07.20 11:12, Mark Boyce wrote:
Hi Daniel
Ah, that’s the bit I misunderstood. I thought that require_certificate would trigger mutual auth / mTLS rather than enforcing its presence.
well, the server indicates it wants to see client certificate during the handshake, but it has no control in forcing the client to do so. From Kamailio point of view, all this is done by underlying libssl used by tls module. The result after handshake, based on the error message, is that client didn't present any certificate.
Typically the clients do not present their certificate by default, there has to be some configuration for that. From my experience, the hardphones have certificates only for provisioning/management APIs.
For SIP, there has an option of uploading the client side certificate, because it has to match somehow the SIP user and SIP service to be able to do proper mutual TLS authentication.
Cheers, Daniel
No sign of a setting on the Yealink to send it’s certificate. Will go unpack a Cisco and see what that offers.
Thanks Mark,
On 3 Jul 2020, at 09:09, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
the client has to be configured to present a certificate, and it doesn't do it based on kamailio log message:
INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate
Check the phone config to see if you can set such option. Kamailio can just see if a certificate is sent and if not reject the connection, if you have require_certificate = yes in the server profile of tls.cfg
You can eventually test with 'openssl s_client ...' to see details of client side certs in kamailio -- iirc, it has the options to specify client side certificate with -cert ... -key ...
Cheers, Daniel
On 03.07.20 09:52, Mark Boyce wrote:
Hi Daniel
I’m testing with a Yealink T57W. It comes with a factory install certificate which will probably fail validation as the common name is the MAC.
I'm not trying validate the client device’s certificate just get it to offer what it has so I can check the details.
Thanks Mark
On 3 Jul 2020, at 08:38, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
what is the SIP client app you used? Is it configured to use its own tls certificate when connecting to the SIP server?
Cheers, Daniel
On 02.07.20 18:51, Mark Boyce wrote:
Hi all
Been trying to grab the TLS cert details from incoming connections, but failing :-(
So with lines just before AUTH is called like this;
if (proto == TLS) { xlog("L_INFO", "TLSDUMP $ci peer_subject : $tls_peer_subject\n");
Gets met with a log line line this;
INFO: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from 1.2.3.4:11797 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 INFO: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: 5.6.7.8:5061 INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate ... INFO: tls [tls_select.c:168]: get_cert(): Unable to retrieve peer TLS certificate from SSL structure
This is with verify_certificate and require_certificate set to no in tls.cfg
If I try and set the following in tls.cfg
[server:default] method = TLSv1.2+ verify_certificate = no require_certificate = yes
I see in the logs;
INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSs<default>: tls_method=22 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/tls-certs/cert.pem' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSs<default>: *require_certificate=1* INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/tls-certs/privkey.pem' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSs<default>: *verify_certificate=0* INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 NOTICE: tls [tls_domain.c:1095]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... INFO: tls [tls_domain.c:692]: set_verification(): TLSs<default>:*Client MUST present valid certificate* INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSc<default>: tls_method=20 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSc<default>: certificate='(null)' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSc<default>: *require_certificate=1* INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSc<default>: *verify_certificate=1* INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 INFO: tls [tls_domain.c:692]: set_verification(): TLSc<default>: *Server MUST present valid certificate* ... ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Which looks like verification is being enabled when I add require?
Would someone be kind enough to point out what I am missing please? (Assuming it’s not a bug :-)
Hi
Looking at the libssl docs it looks like the require/verify setting triggers the client cert request to be sent. When set to ‘verify none' no request is sent.
Either way the Yealink seems to be ignoring the request.
As always, thanks for your assistance
Mark
On 3 Jul 2020, at 11:38, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 03.07.20 11:12, Mark Boyce wrote:
Hi Daniel
Ah, that’s the bit I misunderstood. I thought that require_certificate would trigger mutual auth / mTLS rather than enforcing its presence.
well, the server indicates it wants to see client certificate during the handshake, but it has no control in forcing the client to do so. From Kamailio point of view, all this is done by underlying libssl used by tls module. The result after handshake, based on the error message, is that client didn't present any certificate.
Typically the clients do not present their certificate by default, there has to be some configuration for that. From my experience, the hardphones have certificates only for provisioning/management APIs.
For SIP, there has an option of uploading the client side certificate, because it has to match somehow the SIP user and SIP service to be able to do proper mutual TLS authentication.
Cheers, Daniel
No sign of a setting on the Yealink to send it’s certificate. Will go unpack a Cisco and see what that offers.
Thanks Mark,
On 3 Jul 2020, at 09:09, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
the client has to be configured to present a certificate, and it doesn't do it based on kamailio log message:
INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate
Check the phone config to see if you can set such option. Kamailio can just see if a certificate is sent and if not reject the connection, if you have require_certificate = yes in the server profile of tls.cfg
You can eventually test with 'openssl s_client ...' to see details of client side certs in kamailio -- iirc, it has the options to specify client side certificate with -cert ... -key ...
Cheers, Daniel
On 03.07.20 09:52, Mark Boyce wrote:
Hi Daniel
I’m testing with a Yealink T57W. It comes with a factory install certificate which will probably fail validation as the common name is the MAC.
I'm not trying validate the client device’s certificate just get it to offer what it has so I can check the details.
Thanks Mark
On 3 Jul 2020, at 08:38, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
what is the SIP client app you used? Is it configured to use its own tls certificate when connecting to the SIP server?
Cheers, Daniel
On 02.07.20 18:51, Mark Boyce wrote:
Hi all
Been trying to grab the TLS cert details from incoming connections, but failing :-(
So with lines just before AUTH is called like this;
if (proto == TLS) { xlog("L_INFO", "TLSDUMP $ci peer_subject : $tls_peer_subject\n");
Gets met with a log line line this;
INFO: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from 1.2.3.4:11797 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 INFO: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: 5.6.7.8:5061 INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate ... INFO: tls [tls_select.c:168]: get_cert(): Unable to retrieve peer TLS certificate from SSL structure
This is with verify_certificate and require_certificate set to no in tls.cfg
If I try and set the following in tls.cfg
[server:default] method = TLSv1.2+ verify_certificate = no require_certificate = yes
I see in the logs;
INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSs<default>: tls_method=22 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/tls-certs/cert.pem' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSs<default>: require_certificate=1 INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/tls-certs/privkey.pem' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSs<default>: verify_certificate=0 INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 NOTICE: tls [tls_domain.c:1095]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... INFO: tls [tls_domain.c:692]: set_verification(): TLSs<default>: Client MUST present valid certificate INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSc<default>: tls_method=20 INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSc<default>: certificate='(null)' INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSc<default>: require_certificate=1 INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSc<default>: verify_certificate=1 INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 INFO: tls [tls_domain.c:692]: set_verification(): TLSc<default>: Server MUST present valid certificate ... ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Which looks like verification is being enabled when I add require?
Would someone be kind enough to point out what I am missing please? (Assuming it’s not a bug :-)
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com/ www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla https://www.paypal.me/dcmierla
Best regards Mark
Hello,
as said, from my experience if it is a preloaded certificate on the device, then it is mainly used for the https management interface.
However, searching the web about snom phones and ssl certificates, it seems that their latest models use the certificate even for sip:
- https://service.snom.com/display/wiki/TLS+Support
I haven't tested it, but I plan to do it when I get a chance. I could not see anything in docs about uploading a new set of certs, so I would be interested to learn what sip hard phones allow that.
Cheers, Daniel
On 03.07.20 14:12, Mark Boyce wrote:
Hi
Looking at the libssl docs it looks like the require/verify setting triggers the client cert request to be sent. When set to ‘verify none' no request is sent.
Either way the Yealink seems to be ignoring the request.
As always, thanks for your assistance
Mark
On 3 Jul 2020, at 11:38, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
On 03.07.20 11:12, Mark Boyce wrote:
Hi Daniel
Ah, that’s the bit I misunderstood. I thought that require_certificate would trigger mutual auth / mTLS rather than enforcing its presence.
well, the server indicates it wants to see client certificate during the handshake, but it has no control in forcing the client to do so. From Kamailio point of view, all this is done by underlying libssl used by tls module. The result after handshake, based on the error message, is that client didn't present any certificate.
Typically the clients do not present their certificate by default, there has to be some configuration for that. From my experience, the hardphones have certificates only for provisioning/management APIs.
For SIP, there has an option of uploading the client side certificate, because it has to match somehow the SIP user and SIP service to be able to do proper mutual TLS authentication.
Cheers, Daniel
No sign of a setting on the Yealink to send it’s certificate. Will go unpack a Cisco and see what that offers.
Thanks Mark,
On 3 Jul 2020, at 09:09, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
the client has to be configured to present a certificate, and it doesn't do it based on kamailio log message:
INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate
Check the phone config to see if you can set such option. Kamailio can just see if a certificate is sent and if not reject the connection, if you have require_certificate = yes in the server profile of tls.cfg
You can eventually test with 'openssl s_client ...' to see details of client side certs in kamailio -- iirc, it has the options to specify client side certificate with -cert ... -key ...
Cheers, Daniel
On 03.07.20 09:52, Mark Boyce wrote:
Hi Daniel
I’m testing with a Yealink T57W. It comes with a factory install certificate which will probably fail validation as the common name is the MAC.
I'm not trying validate the client device’s certificate just get it to offer what it has so I can check the details.
Thanks Mark
On 3 Jul 2020, at 08:38, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
what is the SIP client app you used? Is it configured to use its own tls certificate when connecting to the SIP server?
Cheers, Daniel
On 02.07.20 18:51, Mark Boyce wrote: > Hi all > > Been trying to grab the TLS cert details from incoming > connections, but failing :-( > > So with lines just before AUTH is called like this; > > if (proto == TLS) { > xlog("L_INFO", "TLSDUMP $ci peer_subject : > $tls_peer_subject\n"); > > Gets met with a log line line this; > > INFO: tls [tls_server.c:431]: tls_accept(): tls_accept: new > connection from 1.2.3.4:11797 using TLSv1.2 > ECDHE-RSA-AES256-GCM-SHA384 256 > INFO: tls [tls_server.c:434]: tls_accept(): tls_accept: local > socket: 5.6.7.8:5061 > INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client > did not present a certificate > ... > INFO: tls [tls_select.c:168]: get_cert(): Unable to retrieve > peer TLS certificate from SSL structure > > This is with verify_certificate and require_certificate set to > no in tls.cfg > > If I try and set the following in tls.cfg > > [server:default] > method = TLSv1.2+ > verify_certificate = no > require_certificate = yes > > I see in the logs; > > INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): > TLSs<default>: tls_method=22 > INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): > TLSs<default>: certificate='/etc/kamailio/tls-certs/cert.pem' > INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): > TLSs<default>: ca_list='(null)' > INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): > TLSs<default>: crl='(null)' > INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): > TLSs<default>: *require_certificate=1* > INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): > TLSs<default>: cipher_list='(null)' > INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): > TLSs<default>: private_key='/etc/kamailio/tls-certs/privkey.pem' > INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): > TLSs<default>: *verify_certificate=0* > INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): > TLSs<default>: verify_depth=9 > NOTICE: tls [tls_domain.c:1095]: ksr_tls_fix_domain(): > registered server_name callback handler for socket [:0], > server_name='<default>' ... > INFO: tls [tls_domain.c:692]: set_verification(): > TLSs<default>:* Client MUST present valid certificate* > INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): > TLSc<default>: tls_method=20 > INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): > TLSc<default>: certificate='(null)' > INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): > TLSc<default>: ca_list='(null)' > INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): > TLSc<default>: crl='(null)' > INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): > TLSc<default>: *require_certificate=1* > INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): > TLSc<default>: cipher_list='(null)' > INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): > TLSc<default>: private_key='(null)' > INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): > TLSc<default>: *verify_certificate=1* > INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): > TLSc<default>: verify_depth=9 > INFO: tls [tls_domain.c:692]: set_verification(): > TLSc<default>: *Server MUST present valid certificate* > ... > ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS > accept:error:1417C086:SSL > routines:tls_process_client_certificate:certificate verify failed > > Which looks like verification is being enabled when I add require? > > > > Would someone be kind enough to point out what I am missing > please? (Assuming it’s not a bug :-) > >
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
Best regards Mark -- Mark Boyce Dark Origins Ltd e: mark@darkorigins.com mailto:mark@darkorigins.com t: 0345 0043 043 f: 0345 0043 044
Hi
That sounds hopeful. Where I was vaguely going was being able to capture the certificate details at http provisioning, or first sip interaction. This should then give a secure way to validate that individual device.
From my experience with Yealink devices; The older devices all come with a common device certificate. Current generation also have an individual unique certificate. The cutoff appears to be those devices which were factory shipped with firmware version v72
https://tinyurl.com/ybtfxvnj https://tinyurl.com/ybtfxvnj
"Using Security Certificates on Yealink IP Phones” It’s not completely clear but the Yealink security document says;
"If “Mutual TLS Authentication Required” is enabled on your server, the IP phone should send its certificate to the server as well”
However even though the doc mentions SIPs and HTTPS all examples talk about HTTPS and provisioning.
Mark
On 7 Jul 2020, at 07:28, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
as said, from my experience if it is a preloaded certificate on the device, then it is mainly used for the https management interface.
However, searching the web about snom phones and ssl certificates, it seems that their latest models use the certificate even for sip:
I haven't tested it, but I plan to do it when I get a chance. I could not see anything in docs about uploading a new set of certs, so I would be interested to learn what sip hard phones allow that. Cheers, Daniel On 03.07.20 14:12, Mark Boyce wrote:
Hi
Looking at the libssl docs it looks like the require/verify setting triggers the client cert request to be sent. When set to ‘verify none' no request is sent.
Either way the Yealink seems to be ignoring the request.
As always, thanks for your assistance
Mark
On 3 Jul 2020, at 11:38, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, On 03.07.20 11:12, Mark Boyce wrote:
Hi Daniel
Ah, that’s the bit I misunderstood. I thought that require_certificate would trigger mutual auth / mTLS rather than enforcing its presence.
well, the server indicates it wants to see client certificate during the handshake, but it has no control in forcing the client to do so. From Kamailio point of view, all this is done by underlying libssl used by tls module. The result after handshake, based on the error message, is that client didn't present any certificate.
Typically the clients do not present their certificate by default, there has to be some configuration for that. From my experience, the hardphones have certificates only for provisioning/management APIs.
For SIP, there has an option of uploading the client side certificate, because it has to match somehow the SIP user and SIP service to be able to do proper mutual TLS authentication.
Cheers, Daniel
No sign of a setting on the Yealink to send it’s certificate. Will go unpack a Cisco and see what that offers.
Thanks Mark,
On 3 Jul 2020, at 09:09, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
the client has to be configured to present a certificate, and it doesn't do it based on kamailio log message:
INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate
Check the phone config to see if you can set such option. Kamailio can just see if a certificate is sent and if not reject the connection, if you have require_certificate = yes in the server profile of tls.cfg
You can eventually test with 'openssl s_client ...' to see details of client side certs in kamailio -- iirc, it has the options to specify client side certificate with -cert ... -key ... Cheers, Daniel On 03.07.20 09:52, Mark Boyce wrote:
Hi Daniel
I’m testing with a Yealink T57W. It comes with a factory install certificate which will probably fail validation as the common name is the MAC.
I'm not trying validate the client device’s certificate just get it to offer what it has so I can check the details.
Thanks Mark
> On 3 Jul 2020, at 08:38, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote: > > Hello, > > what is the SIP client app you used? Is it configured to use its own tls certificate when connecting to the SIP server? > > Cheers, > Daniel > On 02.07.20 18:51, Mark Boyce wrote: >> Hi all >> >> Been trying to grab the TLS cert details from incoming connections, but failing :-( >> >> So with lines just before AUTH is called like this; >> >> if (proto == TLS) { >> xlog("L_INFO", "TLSDUMP $ci peer_subject : $tls_peer_subject\n"); >> >> Gets met with a log line line this; >> >> INFO: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from 1.2.3.4:11797 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 >> INFO: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: 5.6.7.8:5061 >> INFO: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate >> ... >> INFO: tls [tls_select.c:168]: get_cert(): Unable to retrieve peer TLS certificate from SSL structure >> >> This is with verify_certificate and require_certificate set to no in tls.cfg >> >> If I try and set the following in tls.cfg >> >> [server:default] >> method = TLSv1.2+ >> verify_certificate = no >> require_certificate = yes >> >> I see in the logs; >> >> INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSs<default>: tls_method=22 >> INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/tls-certs/cert.pem' >> INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' >> INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' >> INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSs<default>: require_certificate=1 >> INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' >> INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/tls-certs/privkey.pem' >> INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSs<default>: verify_certificate=0 >> INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 >> NOTICE: tls [tls_domain.c:1095]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... >> INFO: tls [tls_domain.c:692]: set_verification(): TLSs<default>: Client MUST present valid certificate >> INFO: tls [tls_domain.c:303]: ksr_tls_fill_missing(): TLSc<default>: tls_method=20 >> INFO: tls [tls_domain.c:315]: ksr_tls_fill_missing(): TLSc<default>: certificate='(null)' >> INFO: tls [tls_domain.c:322]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' >> INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' >> INFO: tls [tls_domain.c:333]: ksr_tls_fill_missing(): TLSc<default>: require_certificate=1 >> INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' >> INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' >> INFO: tls [tls_domain.c:351]: ksr_tls_fill_missing(): TLSc<default>: verify_certificate=1 >> INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 >> INFO: tls [tls_domain.c:692]: set_verification(): TLSc<default>: Server MUST present valid certificate >> ... >> ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed >> >> Which looks like verification is being enabled when I add require? >> >> >> >> Would someone be kind enough to point out what I am missing please? (Assuming it’s not a bug :-) >> >>
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com/ www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla https://www.paypal.me/dcmierla
Best regards Mark -- Mark Boyce Dark Origins Ltd e: mark@darkorigins.com mailto:mark@darkorigins.com
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com/ www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla https://www.paypal.me/dcmierla
Mark