I just learned that some private keys leaked for a widely-trusted certificate authority. This is bad: it makes it possible for attackers to impersonate HTTPS services.
If you’re shipping a mobile app or service that uses OkHttp, you’re exposed to this problem until the host platform’s trusted roots list is patched. For Android and Java environments, that might take a very long time.
As an immediate workaround I’ve posted a gist for ForbiddenCertificatesHostnameVerifier, which blocks the problematic certificates in the application layer. Install it in your OkHttpClient.
val safeClient = client.newBuilder()
.hostnameVerifier(ForbiddenCertificatesHostnameVerifier())
.build()You can use this with all supported versions of OkHttp.
In the next day or two we’ll ship updates to OkHttp that require no additional intervention.
Update: 2026-10-21T02:30Z: I’ve replaced the Interceptor with a HostnameVerifier in the Gist and in the sample above. Suresh pointed out that an interceptor gets the TLS certificates too late in the process, after secrets have been transmitted to an attacker. The updated HostnameVerifier does not suffer this vulnerability!
Update: 2026-10-22T05:30Z: We’ve published OkHttp 4.12.1 and 5.5.1, that blocklist the above certificates. With these OkHttp releases (or newer) the above interventions are not necessary.