ALPN (Application-Layer Protocol Negotiation)

Application-Layer Protocol Negotiation is defined in RFC 7301. The client lists the protocols it supports by registered identifier, for example h2 and http/1.1, in its ClientHello; the server picks one and returns it. In TLS 1.3 the server's choice travels in the encrypted EncryptedExtensions message, while the client's list stays visible in the plaintext ClientHello.

Why it matters

Browsers speak HTTP/2 over TLS only when it is negotiated through ALPN, so a server or proxy that does not offer h2 silently gets HTTP/1.1. HTTP/3 over QUIC uses the identifier h3. ALPN is also the basis of the ACME TLS-ALPN-01 challenge: the CA connects offering the acme-tls/1 protocol, and the server answers with a special validation certificate instead of its normal one. Because the protocol is fixed during the handshake, RFC 7301 expects a server that supports none of the offered protocols to abort with a no_application_protocol alert rather than fail later at the HTTP layer.

Example

openssl s_client -connect example.com:443 -servername example.com -alpn h2,http/1.1 </dev/null 2>/dev/null | grep -i alpn
# ALPN protocol: h2

In nginx, HTTP/2 (and with it the h2 ALPN value) is enabled with http2 on; in newer versions or listen 443 ssl http2; in older ones.

Common misconceptions

• ALPN negotiates the TLS version. No. TLS version and cipher suite are negotiated separately; ALPN only picks the protocol that runs on top of TLS.
• ALPN is the same as NPN. NPN was an earlier, Google-designed extension in which the client chose the protocol. It has been replaced by ALPN, in which the server chooses.
• Enabling HTTP/2 in the application is enough. If the proxy doing TLS termination in front of it does not advertise h2, clients still use HTTP/1.1.