Asterisk PJSIP TLS certificate verification fails

Find which side is the TLS client

When a phone connects to an Asterisk TLS listener, Asterisk presents the server certificate and the phone normally validates the PBX name and chain. When Asterisk initiates an outbound connection to a registrar, proxy or trunk, Asterisk is the TLS client and its verify_server and CA controls govern remote-server verification. If mutual TLS is required, verify_client and require_client_cert address the certificate presented to Asterisk by a connecting client.

Record direction, configured hostname, resolved address, port, transport name and the first Asterisk or endpoint error. A handshake failure occurs before a SIP REGISTER, INVITE, 401 or 407 exchange, so resetting a SIP password cannot repair it.

Inspect the loaded transport, not only the file

Confirm that the running transport uses protocol=tls and the expected bind, certificate, private-key, CA, verification, TLS-method and cipher settings. The Asterisk reference states that cert_file supplies the certificate while priv_key_file supplies the matching key. It also distinguishes verify_server, verify_client and require_client_cert; do not use those names interchangeably.

Transport edits have an activation boundary. Asterisk's current reference says transport changes require a complete restart, while allow_reload is an opt-in control whose default is off because reload can disrupt calls. Follow the transport activation guide before concluding that a corrected file is active. In FreePBX, inspect generated state but make durable changes through supported certificate and transport controls.

Test the certificate identity and chain

From the Asterisk host, query the exact DNS name and port used by the configuration. A bounded check such as openssl s_client -connect sip.example.net:5061 -servername sip.example.net -showcerts -verify_return_error -verify_hostname sip.example.net can expose the presented chain, hostname result and protocol negotiation. Use the intended CA options when the service relies on a private trust anchor. OpenSSL documents that -showcerts displays the certificates sent by the server and that -verify_return_error makes verification failure terminate the check.

This test is independent evidence, not proof that Asterisk selected the same transport, CA set, PJProject build or cipher. Compare certificate validity dates and the PBX clock, the requested DNS name and certificate identities, the issuer chain and any missing intermediate. Connecting by an IP address while expecting a DNS identity can produce a legitimate mismatch.

Keep wildcard and WebSocket boundaries visible

Asterisk added allow_wildcard_certs in 16.28.0, 18.14.0 and 19.6.0. The option only has meaning with verify_server, and the documentation limits matching to a complete left-most label: a certificate for *.example.net can match one level, not a.b.example.net. Do not enable it merely to make an unrelated name pass.

The PJSIP transport reference marks the certificate, CA and verification options discussed here as TLS-only and not WSS. A browser WebSocket deployment has a different HTTP/WebSocket and browser trust boundary; do not apply this diagnostic as though a WSS connection were the same listener.

Correct trust without suppressing it

Replace or renew the wrong or expired certificate, install the required intermediate chain, use the name covered by the certificate, correct the system clock, deploy the intended private CA or align the documented mutual-TLS policy. Keep private keys out of logs and tickets. Do not set verify_server off, accept any certificate or weaken the name merely to make a production trunk register.

After the handshake succeeds, capture a narrowly scoped SIP exchange with pjsip set logger on, then turn the extra logging off and protect the trace because it can expose identities and call metadata. Verify registration and a representative incoming and outgoing call separately; verify SRTP separately from TLS. No PBX, provider, certificate, CA, clock, DNS, cipher, registration, media or live-call behavior was tested for this guide.

Do not confuse HTTPS TLS with PJSIP TLS

The Asterisk HTTP service guide treats the built-in HTTPS listener and its certificate independently from PJSIP signaling transports and SRTP media.