VoIP.info Troubleshooting

SIP TLS registration fails

Separate DNS, TCP, TLS, SIP transport selection and digest authentication before changing credentials.

Reviewed 2026-10-14Asterisk 22 LTS · FreePBX 17 / Debian 12 evidence workflow; first-party documentation reviewed September 30, 2026; no endpoint, PBX, certificate or registration testIntermediateDocumentation based · not lab tested

Name the first failed layer

Record the endpoint, configured hostname, resolved address, port, time and exact error before changing anything. Then classify the earliest missing state: DNS answer, TCP connection, TLS handshake, certificate validation, transmitted REGISTER, returned SIP response, digest retry or accepted registration. A password cannot repair a connection that never reached SIP, while a completed TLS handshake does not prove that REGISTER was sent or accepted.

Capture both ends when possible. On Asterisk, enable pjsip set logger on only for a bounded diagnostic window and preserve the timestamped SIP evidence without exposing credentials. Asterisk's troubleshooting guide also recommends sufficient core verbose and debug output; return temporary logging to the approved operating level after collection.

TLS and SRTP protect different traffic
TLS protects SIP signaling on the configured transport hop. SRTP protects the audio media stream on its configured path. Each requires separate negotiation and validation.

Encryption on one leg is not proof of end-to-end encryption. Review the provider boundary, certificates and media keying method.

Prove URI and transport selection

Asterisk PJSIP selects transport from the URI and configured objects. Its documentation states that a missing transport parameter is treated as UDP, while a sips: URI switches to TLS; TCP or TLS DNS service discovery also depends on the transport expressed in the URI. Confirm the intended hostname, port, address family, sips: or transport parameter, and loaded TLS transport instead of assuming that port 5061 alone selected TLS.

For an outbound registration, inspect the type=registration object separately from the endpoint. Confirm its server_uri, client_uri, selected transport or URI transport parameter, and outbound-auth reference. Asterisk treats outbound registration and endpoint objects as independent configuration.

Validate trust and certificate roles

Compare the configured DNS name with the certificate's valid identities, validity window and issuing chain. Confirm accurate endpoint and server time. A certificate issued for a DNS name is not automatically valid when the client is configured with a numeric address. Review any proxy or session border controller that terminates and re-originates TLS as a separate certificate boundary.

Asterisk's TLS transport options keep the local cert_file and matching priv_key_file, trusted CA file or path, verify_server, verify_client and require_client_cert as separate controls. Record which side is client and which is server before changing them. Do not make disabled certificate verification the permanent repair; establish the correct name, chain and trust policy.

Inspect loaded transport and registration state

Confirm that the TLS transport loaded with the intended protocol, bind address, port, certificate, key and trust settings. Asterisk documents that transport sections are not normally reloadable unless allow_reload is enabled, and even then reloading can disrupt active calls. Use the approved maintenance path and verify the running state rather than assuming a GUI save changed the live listener.

Use pjsip show registrations and pjsip show registration <name> for outbound registration status and effective values. Preserve whether the state is Unregistered, Registered, Rejected or Stopped and the first returned response. A normal 401 or 407 challenge followed by an authenticated retry is not itself a failure; repeated rejection must be diagnosed only after TLS and object selection are proved.

Retest the complete path without collapsing outcomes

After correcting the smallest demonstrated cause, retest DNS resolution, TCP connection, TLS handshake, peer identity validation, REGISTER transmission, challenge handling, accepted registration and renewal as separate outcomes. Then place an authorized call and verify the intended SIP dialog, negotiated media and bidirectional audio. TLS protects the signaling connection under test; it does not prove SRTP, downstream encryption or end-to-end confidentiality.

When Asterisk PJSIP is one side of the failed connection, use the Asterisk certificate-failure investigation to separate client and server roles, loaded transport state, certificate presentation and post-handshake SIP evidence. Preserve the prior configuration and a rollback path.

Do not force a no-REGISTER trunk into a registration diagnosis

LoopUp documents IP-to-IP trunking without REGISTER. Use the provider-specific TLS diagnostic for its regional target, dedicated endpoint, mutual certificate trust and protected media path.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.