ASVS 5.0 V17.2.1 requires that the key for the DTLS (Datagram Transport Layer Security) certificate is managed and protected according to a documented policy for cryptographic key management. It is a Level 2 requirement.
In WebRTC, DTLS runs the handshake that produces the keys for encrypted media. The certificate key identifies your media endpoint. If it leaks, someone else can impersonate that endpoint.
Why it matters
The DTLS certificate is usually self signed, and trust comes from the fingerprint exchanged in signaling (see V17.2.8). That makes the private key the whole identity. A key committed to a repository, baked into an image, or reused across every server means one leak compromises every call.
How to implement it
Write the policy first, even if it is one page: who generates keys, where they live, how long they last, who can read them, how they are rotated and destroyed.
Practical defaults:
- Generate the key on the host that uses it, or in a hardware module or cloud key service where the media server supports it. Use ECDSA P-256 or RSA 2048 or larger.
- Create a fresh certificate per instance or per process start. Short lifetimes limit exposure, and browsers do not require long lived DTLS certificates.
- Store keys with mode 0600, owned by the media server account only. Never in source control or a container image layer.
- Keep keys out of logs and crash dumps.
- Rotate on a schedule and immediately after staff changes or suspected exposure.
openssl ecparam -name prime256v1 -genkey -noout -out dtls-key.pem
chmod 600 dtls-key.pem
openssl req -new -x509 -key dtls-key.pem -out dtls-cert.pem -days 30 -subj "/CN=media-1"
openssl x509 -in dtls-cert.pem -noout -fingerprint -sha256
Secret scanning in CI stops key files from reaching a repository in the first place.
Try it yourself
Click through it at your own pace, or open it full screen.
How to test it
- Search the repository history, images and config management for PEM private key headers.
- On the host, list key file permissions and owners. Anything beyond the service account is a fail.
- Compare the key age with the policy lifetime.
- Restart one media instance and verify its fingerprint changes if policy says per start certificates.
- Ask for the policy and check the actual practice against it.
Rotation without dropping calls
Rotation works smoothly when the fingerprint is signaled fresh for every session. Because each new session reads the current certificate, you can replace the key between sessions with no coordination. Calls in progress keep their existing keys, since DTLS has finished. Plan for the restart of a media server by draining it: stop accepting new rooms, wait for the existing ones to end, then replace the certificate.
Hardware and cloud key stores
If your policy demands that keys never exist on disk, check whether your media server supports a PKCS#11 provider or an engine that keeps the key in a hardware module. Many do not, which is a legitimate reason to document a compensating control, such as encrypted volumes, a locked down host and short certificate life, instead of leaving the gap unexplained. The requirement says the key must be managed per documented policy, so a clear and honest policy that you follow satisfies it better than an ambitious one you cannot meet.
Common mistakes
- One key shared by every media server.
- Key files in an image so every container carries them.
- A policy document that nobody follows, or no written policy at all.
- Rotation that breaks calls because signaling still advertises the old fingerprint.
Quick check
Why is the private key so important when the certificate is self signed?
Trust rests on the fingerprint, so the key is the identity. Whoever holds it can pass the fingerprint check.
