TLS
The testbed's TLS coverage runs against a real server with a real certificate chain, trusted the way an application would trust one — never by disabling verification. That constraint is what makes the result mean something.
Current results
Recorded policy and handshake observations
These values come directly from the latest network result. “Accepted” and “refused” describe platform behaviour; they are not editorial verdicts.
Probed endpoints
How the results are produced
The suite list above is the authority for what runs today. For the container evidence,
BasicMockServerTest starts a MockServer container and makes the same request over
both http and https. The interesting half is the trust setup:
trustMockServer() builds a real X509TrustManager from MockServer's own
keystore rather than accepting anything. Where a test needs something the public API does not
offer, the testbed solves it with the container rather than reaching into
okhttp3.internal — an all-trusting client would pass whether or not verification
works, which is the opposite of a test.
The same TLS endpoint is what the virtual-thread suite drives, because the pinning it looks for happens in the HTTP/2 write path over TLS.
Specifications
| Document | Title | Why it matters here |
|---|---|---|
| RFC 8446 | TLS 1.3 | The version everything current negotiates, and the one ECH requires. |
| RFC 5246 | TLS 1.2 | Still what a container image or an older endpoint may offer; the fallback path has to stay correct. |
| RFC 5280 | X.509 Certificate and CRL Profile | Chain building and validation — what okhttp-tls parses and what the trust manager enforces. |
| RFC 6125 | Service Identity in TLS | Hostname verification, superseding the practice described in RFC 2818. |
| RFC 7301 | ALPN | How HTTP/2 is negotiated, and one of the fields ECH hides. |
| RFC 7468 | Textual Encodings of PKIX Structures | The PEM handling in okhttp-tls. |
| RFC 6962 | Certificate Transparency | Relevant to any real-world chain a network suite will encounter. |
Test sites
| Endpoint | Operator | What it offers |
|---|---|---|
| mockserver/mockserver (container) | MockServer | A local TLS endpoint with a keystore the test trusts explicitly. Its current coverage is reported under BasicMockServerTest above. |
| badssl.com | badssl.com | The standard set of chains that must be rejected: expired, wrong host, self-signed, revoked, and weak-crypto endpoints. |
| tls13.akamai.io | Akamai | A TLS 1.3 endpoint on an independent stack. |
| SSL Labs | Qualys | Not a test target — the reference for what a given endpoint actually offers when a result needs explaining. |
Reading a result
A TLS failure against a container is almost always this repository's problem: the image moved, or the client and server versions drifted. A TLS failure against a public endpoint is more often the endpoint's — certificates get renewed, and a chain that changes can fail a test that was too specific about it. The rule of thumb is that a test asserting a connection succeeds is fragile against the internet; one asserting it is refused, as with the badssl endpoints, is much less so.
A site listed here is documentation, not evidence that it ran. Only endpoints and suites present in the live result blocks above count as current coverage.