TLS Certificate Requirements for HTTP/3 Servers (2026)

HTTP/3’s TLS requirements are fundamentally different from HTTP/1.1 and HTTP/2, and it’s not just about newer cipher suites.

Let’s see it in action. Imagine a server configured for HTTP/3. We’ll use curl to probe it.

curl --http3 -v https://example.com

When you run this, curl will attempt to establish an HTTP/3 connection. The most striking difference you’ll observe is the handshake process. Instead of the familiar TLS 1.2 or 1.3 handshake over TCP, HTTP/3 initiates a QUIC handshake over UDP. This QUIC handshake includes the TLS 1.3 handshake within it.

Here’s the mental model: HTTP/3 is built on QUIC, which is a transport protocol that runs over UDP. QUIC aims to provide the reliability and security of TCP+TLS but with significant improvements in connection establishment latency and resilience to network changes. To achieve security, QUIC mandates TLS 1.3.

The core problem HTTP/3 and QUIC solve is head-of-line blocking. In TCP, if a packet is lost, all subsequent packets in that connection are blocked until the lost packet is retransmitted. In QUIC, streams are multiplexed independently. If a packet for one stream is lost, only that specific stream is affected, not the entire connection. This is achieved through QUIC’s own packet numbering and retransmission mechanisms, all secured by TLS 1.3.

So, what are the TLS certificate requirements?

TLS 1.3 Support: This is non-negotiable. QUIC requires TLS 1.3. Servers must be configured to negotiate and use TLS 1.3. This means your TLS library (OpenSSL, BoringSSL, etc.) must be recent enough to support TLS 1.3, and your server software (Nginx, Caddy, Apache with QUIC module) must be configured to enable it. For example, in Nginx, you’d ensure ssl_protocols includes TLSv1.3.
Server Name Indication (SNI): Just like with TLS 1.2, SNI is crucial for virtual hosting on HTTPS. The client sends the hostname it’s trying to reach during the handshake, allowing the server to present the correct certificate. This works identically within the QUIC/TLS 1.3 handshake.
Certificate Chain and Key: Your certificate chain must be valid and complete. The server must be able to present its certificate along with any intermediate certificates needed to form a trust path back to a root CA trusted by the client. The private key corresponding to the certificate must be accessible to the server.
Cipher Suites: While TLS 1.3 has a much smaller, standardized set of cipher suites compared to TLS 1.2, the server must be configured to support at least one of them. Typically, modern TLS libraries will default to appropriate TLS 1.3 cipher suites. You don’t usually need to explicitly configure these for TLS 1.3 unless you have very specific security policies.
Key Usage and Extended Key Usage: Your certificate should have appropriate Key Usage and Extended Key Usage extensions. For a web server, digitalSignature and keyEncipherment are typically required within Key Usage. For Extended Key Usage, serverAuth is essential.
Valid Not Before/Not After Dates: The certificate must be currently valid. Expired certificates will cause connection failures.
No Certificate Transparency (CT) Logs Requirement (for the server’s perspective): Unlike some HTTP/2 or HTTP/1.1 deployments where CT log compliance might be enforced by browsers or load balancers, QUIC/TLS 1.3 itself does not inherently require a certificate to have been logged in CT logs for the handshake to succeed. However, most public Certificate Authorities will issue certificates that are CT-compliant, and browsers will still perform CT checks. The primary requirement here is that the certificate is trusted by the client’s root store.

The most surprising aspect of HTTP/3’s TLS requirements is how tightly coupled the transport and security handshakes become. In QUIC, the TLS 1.3 handshake is not a separate step after the transport connection is established; it’s an integral part of the QUIC connection establishment itself. This integration is what allows QUIC to achieve its reduced latency goals. The initial QUIC handshake packets carry early TLS 1.3 handshake messages. If the TLS handshake fails, the QUIC connection is aborted immediately, preventing wasted network round trips.

The next hurdle you’ll likely face is optimizing QUIC’s performance, which involves tuning UDP buffer sizes and understanding how congestion control works differently in QUIC compared to TCP.