Bug#941011: asterisk: Silently failing on weak certificates with no debug messages

[Anton Ivanov]

On 04/10/2019 21:43, Bernhard Schmidt wrote:
> Am 23.09.19 um 14:19 schrieb Anton Ivanov:
>
> Dear Anton,
>
>> Package: asterisk
>> Version: 1:16.2.1~dfsg-1+deb10u1
>> Severity: minor
>>
>> Dear Maintainer,
>>
>> After an upgrade from stretch to buster, my asterisk installation lost tls support.
>>
>> Debug provided minimal information - it was failing to load the certificate in tcptls.c
>>
>> Root cause was openssl deciding that the old certificates were too weak.
>>
>> There is no debug info. There is no easy fix because the openssl error api can print the error queue only to a file/bio. It is not possible to feed into another logging framework (f.e. asterisk) and dump it at that level. I was able to stick a couple of statements dumping openssl errors to stderr, but this approach is not fit for a proper fix.
>>
>> IMHO the only thing that can be done here is to add a note to the changes file and relevant warnings apt-changes.
> Are you using chan_sip or chan_pjsip?

chan_sip

>
> Since these affect everything in Buster using SSL certificates (with
> both OpenSSL and GnuTLS) I don't think this is Asterisk specific and
> should not be handled as such. I had to replace quite a lot of
> internal/self signed certificates because they refused to load,
> including unbound's local control certificate.
>
> However, I feel your pain. I had an issue with a remote certificate, and
> it drove me nuts to identify the failing peer, because it is not logged.
> That has been fixed fortunately.
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26006
> https://issues.asterisk.org/jira/browse/ASTERISK-28444
>
> I'd suggest filing an issue upstream.

Good idea. Though the way openssl handles this particular error 
reporting makes capturing it quite difficult.

In any case, let's let upstream figure it out :)

Brgds,

>
> Bernhard
>

-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/