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(a)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(a)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(a)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(a)darkorigins.com
t: 0345 0043 043
f: 0345 0043 044