SIP Registration using TLS Accept All Client Certificates

Asterisk Asterisk SIP
1

Using this configuraiton:
[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0
cert_file=/etc/asterisk/cert/STAR_gpsne_org.crt
priv_key_file=/etc/asterisk/cert/STAR_gpsne_org.key
ca_list_file=/etc/asterisk/cert/My_CA_Bundle.ca-bundle
cipher=TLS_AES_256_GCM_SHA384, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, DHE-DSS-AES256-GCM-SHA384, DHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-CCM8, ECDHE-ECDSA-AES256-CCM, DHE-RSA-AES256-CCM8, DHE-RSA-AES256-CCM, ADH-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-SHA384, ECDHE-RSA-AES256-SHA384, DHE-RSA-AES256-SHA256, DHE-DSS-AES256-SHA256, DHE-DSS-CAMELLIA256-SHA256, ADH-AES256-SHA256, ECDHE-ECDSA-AES256-SHA, ECDHE-RSA-AES256-SHA, DHE-RSA-AES256-SHA, DHE-DSS-AES256-SHA, DHE-RSA-CAMELLIA256-SHA, DHE-DSS-CAMELLIA256-SHA, AECDH-AES256-SHA, ADH-AES256-SHA, ADH-CAMELLIA256-SHA, ECDHE-ECDSA-AES128-SHA, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-SHA, DHE-RSA-SEED-SHA, AECDH-AES128-SHA, ADH-AES128-SHA, ADH-SEED-SHA, RSA-PSK-AES256-GCM-SHA384, DHE-PSK-AES256-GCM-SHA384, DHE-PSK-CHACHA20-POLY1305, DHE-PSK-AES256-CCM8, DHE-PSK-AES256-CCM, AES256-GCM-SHA384, AES256-CCM8, AES256-CCM
method=tlsv1_2
require_client_cert=no
verify_client=no
verify_server=no

I have issues with some clients connecting when they present a client certificate. Wireshark shows a decrypt error response from server to client and the Asterisk console shows tls/ssl bad signature.

Since “verify_client” is set to “no”, shouldn’t the server just accept the client cert? Is there a way to get Asterisk (pjsip) to accept whatever the client presents? Or… does that not work since I don’t have a way to decrypt that communication due to the phones have those preloaded (I didn’t create those certs)?

2

Hard to say without more (obfuscated) logs…

This is a wildcard cert? The phones (make? models?) might be rejecting it, as they are supposed to do per RFC 5922 section 7.2 prohibitions:

For example, "*.example.com" matches only "*.example.com" but not "foo.example.com".

SIPS != HTTPS in that regard :cowboy_hat_face: Slightly aside, Asterisk/PJSIP by default will reject this, if you specify “verify_server” and the remote presents a wildcard (unless you go all non-RFC and change the default setting of allow_wildcard_certs on the transport.)

If not wildcard issue, then could you pare down the cipher list a little? Maybe try on a separate transport on an alternate port, for just these particular phones?

What does that look like?

What’s the exact message? Output with any line number? Asterisk version? Could be error propagated up from SSL libraries.

Yes, reading in PJSIP source sip_transport_tls.c per verify_peer checks seems to suggest Asterisk will keep the socket open during verification errors.

Well, you might want to look into updating them, at least on a test phone, and see how it goes.

3

I have tried a self-signed cert and a * cert. Phones are workforce and welcome consoles… but the issue only occurs with the welcome consoles. Workforce phones register just fine.
When using the welcome consoles, if you add and then remove the web server certificate, while the certificate change is “processing”, the phone will register due to changing to key exchange rather than certificate exchange.
It seems to be some sort of signature error. My guess is that WildIx did something wrong deploying TLS 1.2.

4

Maybe try an FQDN cert as well?

Workforce are the newest model phone they offer?

Not sure where to go to ask… or how they implement SIP, TLS, etc… that Wildix project forked off of Asterisk many moons ago.

5

Thank you for the responses… based on what I’ve seen, it’s probably a bug or intended to prevent what I am attempting to do.