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/
