Asterisk SIP TLS and SRTP: Secure Signaling and Media Guide

TLS and SRTP protect different paths

TLS encrypts and authenticates the signaling transport hop by hop; it does not encrypt RTP. SRTP protects media packets, but its keys must be negotiated through an appropriate signaling mechanism such as SDES or DTLS-SRTP. A TLS listener with plain RTP is signaling-only encryption. A mixed design can be valid only when its trust boundaries and peer requirements are explicit.

Certificate and key prerequisites

Use a certificate whose identity matches the peer’s connection target and whose chain is trusted under the agreed policy. The private key must be readable by Asterisk but not by unprivileged users. Track expiry, renewal, file ownership and whether Asterisk reloads renewed material. The fake paths below do not identify any production certificate.

sudo install -d -o asterisk -g asterisk -m 750 /etc/asterisk/keys/example
sudo install -o asterisk -g asterisk -m 640 fullchain.pem /etc/asterisk/keys/example/fullchain.pem
sudo install -o asterisk -g asterisk -m 640 private.key /etc/asterisk/keys/example/private.key
openssl x509 -in /etc/asterisk/keys/example/fullchain.pem -noout -subject -issuer -dates

Configure a TLS transport

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/example/fullchain.pem
priv_key_file=/etc/asterisk/keys/example/private.key
method=tlsv1_2
verify_server=yes
verify_client=no
require_client_cert=no
external_signaling_address=198.51.100.20
external_media_address=198.51.100.20

verify_server=yes is relevant when Asterisk acts as TLS client and must validate the remote certificate. Client-certificate requirements are a separate inbound policy agreed with the peer. Do not default to disabling verification to silence a chain or hostname error; repair the trust chain, DNS name, clock or peer configuration.

Configure media encryption deliberately

[carrier-endpoint-sdes]
type=endpoint
transport=transport-tls
aors=carrier-aor
disallow=all
allow=ulaw
media_encryption=sdes
media_encryption_optimistic=no
direct_media=no

media_encryption=sdes requests SRTP using crypto attributes carried in SDP. Those keying attributes are protected only if the signaling path is adequately protected; logging SDP can disclose key material. DTLS-SRTP uses a different negotiation model and must match the endpoint capability. Do not enable an encryption mode that the peer has not agreed to support.

m=audio 16422 RTP/SAVP 0 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:REDACTED_EXAMPLE_KEY_MATERIAL
a=rtpmap:0 PCMU/8000

Verify listener and handshake

sudo ss -lntp | grep ':5061'
sudo asterisk -rx "pjsip show transports"
openssl s_client -connect sip.example.net:5061 -servername sip.example.net -showcerts </dev/null

CONNECTED(00000003)
Protocol  : TLSv1.3
Verify return code: 0 (ok)
# Illustrative output; protocol depends on both endpoints.

A successful OpenSSL verification tests the target presented to that client; it is not proof that Asterisk selected the same transport or that SIP authentication and calls work. Confirm the PJSIP transport on the actual INVITE. A bound listener proves only local socket state.

Validate call negotiation

sudo asterisk -rx "module show like res_pjsip"
sudo asterisk -rx "pjsip show transport transport-tls"
sudo asterisk -rx "pjsip show endpoint carrier-endpoint-sdes"
# During one authorized call:
pjsip set logger on
pjsip set logger off

Inspect whether the endpoint resolves to the TLS transport and whether SDP uses an encrypted RTP profile and expected keying attribute. Confirm actual SRTP packets in both directions and audio quality. Avoid retaining full SDES traces; redact key material before incident sharing.

Common certificate and encryption failures

Rollback and recovery

If the peer cannot negotiate the approved secure profile, stop the test rather than silently weakening verification. Restore the previous transport and endpoint from backup, apply the narrow supported reload or controlled restart, and verify baseline signaling and media. Remove temporary certificate copies and trace files. A temporary plaintext fallback requires an explicit security decision, defined duration and monitored compensating controls.

Related engineering resources

Renewal, reload and staged validation

Certificate renewal is an operational change even when automated. Test the new chain and key pairing before activation, retain the prior certificate for a bounded rollback period, and determine whether the installed Asterisk transport can consume renewed files through reload or requires a restart. Coordinate with the peer when mutual TLS pins a certificate or issuing chain. A file renewed on disk is not evidence that an existing process loaded it.

Stage validation in layers: first verify file ownership and dates, then a local listener, then an outbound TLS handshake with hostname validation, then an authenticated SIP transaction, and finally SRTP in both directions. Monitor expiry and handshake failures. Never log SDES key material as routine telemetry, and never put private keys or certificate enrollment credentials in the public repository.

Inputs you need from your peer