TLS Certificates
Upload PEM certificates for encrypted SIP signaling over TLS, configure mutual TLS authentication, and use custom certificate authorities for internal testing.
SIP over TLS encrypts the signaling channel between your test endpoints and the SIP registrar. This protects SIP credentials, call setup metadata, and SDP bodies from network inspection. TLS is configured per registrar and applies to all endpoints using that registrar.
Prerequisites
- The registrar must have its transport protocol set to TLS (see Transport Protocols)
- The SIP server must be listening on the TLS port (default 5061) with a valid certificate
Certificate Upload
CallMeter supports PEM-encoded certificates for three use cases:
| Certificate Type | When Required | Purpose |
|---|---|---|
| CA Certificate | Self-signed or internal CA | Tells the endpoint to trust this CA when verifying the server's certificate |
| Client Certificate | Mutual TLS (mTLS) | Proves the endpoint's identity to the server |
| Client Private Key | Mutual TLS (mTLS) | Paired with the client certificate for TLS handshake |
Uploading Certificates
In the registrar configuration:
- Set the transport protocol to TLS
- Expand the TLS Configuration section
- Upload certificates in PEM format (
.pem,.crt, or.keyfiles)
The platform validates each uploaded certificate immediately:
- Format check — must be valid PEM-encoded X.509
- Expiration check — warns if the certificate expires within 30 days, rejects if already expired
- Key match — if both client cert and key are provided, verifies they form a matching pair
- Chain validation — if a CA cert is provided, verifies the client cert chains to it
Certificate content storage
Certificates are stored as content, not as file references. You can safely delete the original PEM files from your machine after uploading. The certificate content is associated with the registrar and persists across test runs.
TLS Verification Modes
| Mode | Behavior |
|---|---|
| System | Verify the server's certificate against the operating system's trusted CA store. Use this when the SIP server has a certificate signed by a public CA (DigiCert, Let's Encrypt, etc.). |
| Custom | Verify the server's certificate against your uploaded CA certificate. Use this for self-signed certificates or internal PKI. |
| Skip | Accept any server certificate without verification. Use this only for testing environments where certificate validation is not relevant to the test objective. |
Mutual TLS (mTLS)
Mutual TLS adds client authentication to the TLS handshake. The SIP server verifies the endpoint's identity using the client certificate, in addition to the endpoint verifying the server's identity.
To configure mTLS:
- Upload a Client Certificate (PEM)
- Upload the matching Client Private Key (PEM)
- Optionally upload a CA Certificate if the server uses an internal CA
Both sides then verify each other during the TLS handshake. If the server rejects the client certificate, the connection fails before any SIP message is sent.
sips: URI Scheme
When TLS transport is selected, CallMeter automatically uses the sips: URI scheme in SIP messages instead of sip:. This applies to:
- The Contact header in REGISTER requests
- The From and To headers in INVITE requests
- The Request-URI of outbound requests
The sips: scheme signals to SIP proxies and registrars that the signaling path is encrypted. Some SIP servers require sips: URIs for TLS connections and reject sip: URIs received over TLS.
TLS Handshake Events
When a TLS connection is established, CallMeter logs a TLS Handshake Verified event on the endpoint timeline. This event confirms:
- The TLS version negotiated (TLS 1.2 or 1.3)
- Server certificate validation passed
- Client certificate was accepted (if mTLS)
If the handshake fails, the endpoint transitions to a failed status with an error message indicating the cause (certificate expired, untrusted CA, hostname mismatch, etc.).
Troubleshooting
| Symptom | Likely Cause | Solution |
|---|---|---|
| Connection refused on port 5061 | Server not listening for TLS | Verify the SIP server's TLS listener configuration |
| Handshake failure: certificate expired | Server or client cert past its validity period | Renew the certificate and re-upload |
| Handshake failure: unknown CA | Server cert signed by an untrusted CA | Upload the CA certificate or switch verification mode to Custom |
| Handshake failure: hostname mismatch | Server cert CN/SAN does not match the registrar domain | Verify the cert's Common Name or Subject Alternative Names |
| mTLS rejected | Server does not trust the client's CA | Ensure the server's trust store includes the CA that signed the client cert |
For more detailed troubleshooting, see Media Encryption Issues.
Next Steps
- Transport Protocols — Protocol selection and DNS discovery
- SDES-SRTP — Add media encryption alongside TLS signaling encryption
- DTLS-SRTP — Handshake-based media encryption
SDES-SRTP Encryption
Configure SRTP media encryption using SDP Security Descriptions (RFC 4568) with policy enforcement, cipher suite selection, and SDP profile changes.
DTLS-SRTP Encryption
Configure DTLS-SRTP media encryption with auto-generated certificates, fingerprint verification, and dual-offer mode for maximum compatibility.