Hi,
after upgrading from OkHttp 3.0.1 to 3.1.0 I get the following stack trace and crash after calling build() to create a OkHttpClient.
java.lang.IllegalStateException: Unable to extract the trust manager on okhttp3.internal.Platform$Android@1d8cf999, sslSocketFactory is class com.google.android.gms.org.conscrypt.KitKatPlatformOpenSSLSocketAdapterFactory
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:187)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:60)
at okhttp3.OkHttpClient$Builder.build(OkHttpClient.java:719)
This issue was not present in 3.0.1.
Here's where the crash happens:
OkHttpClient.Builder builder = new OkHttpClient.Builder()
.connectTimeout(10, TimeUnit.SECONDS)
.writeTimeout(10, TimeUnit.SECONDS)
.readTimeout(30, TimeUnit.SECONDS);
OkHttpClient client = builder.build();
Ahh, yeah I gotta fix this for the GMS TLS stack. Will fix.
Released as 3.1.1 and 2.7.4.
Just re-checked with 3.1.1, unfortunately, still doesn't work under Robolectric but works on actual Android (API 23).
Caused by: java.lang.IllegalStateException: Unable to extract the trust manager on okhttp3.internal.Platform$Android@20bcec4c, sslSocketFactory is class sun.security.ssl.SSLSocketFactoryImpl
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:186)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:60)
at okhttp3.OkHttpClient$Builder.build(OkHttpClient.java:718)
Same thing here, robolectric tests are now crashing after upgrade from 3.0.0-RC1
Same here on robolectric tests:
java.lang.IllegalStateException: Unable to extract the trust manager on okhttp3.internal.Platform$Android@19f0acf3, sslSocketFactory is class sun.security.ssl.SSLSocketFactoryImpl
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:187)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:151)
@swankjesse please see above: should this be reopened, or would you prefer a new issue opened for the sun.security.ssl.SSLSocketFactoryImpl issue?
Fixes for Robolectric released in OkHttp 3.1.2.
Yupp, Robolectric tests are now back to normal, thanks!
Hi,
same here
Unable to extract the trust manager on okhttp3.internal.Platform$Android@53244b48, sslSocketFactory is class crittercism.android.q at okhttp3.OkHttpClient.
at okhttp3.OkHttpClient.
This issue should be re-opened, I still have the same issue using Retrofit 2.0.0-beta4 (/OkHttp 3.1.2) in combination with Crittercism (5.5.5-rc-1 to be exact).
Error:
Caused by: java.lang.IllegalStateException: Unable to extract the trust manager on okhttp3.internal.Platform$Android@2e3d9cee, sslSocketFactory is class crittercism.android.q
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:187)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:60)
at okhttp3.OkHttpClient$Builder.build(OkHttpClient.java:718)
at [mypackage].modules.AppModule.provideOkHttpClient(AppModule.java:385)
@kacamak , @PieterAelse ugh! You guys interested in trying to help out with the fix? I need to be able to extract the X509TrustManager instance from the SSLSocketFactory, but I don’t know anything about the SSLSocketFactory that gets configured when you use Crittercism. (Also, _why_ is Crittercism customizing the system’s SSL? That seems sketchy.)
@swankjesse, some folks are seeing this in the PayPal Sdk too. PayPal uses custom SSLSocketFactory for pinning purposes and to enable TLSv1.2 on API 16-19 devices.
Have this problem with DAVdroid's SSLSocketFactoryCompat.
Has anything changed in how SSLSocketFactories should be set?
If you rename that factory’s private defaultFactory field to delegate, the hacky detector we use will do the right thing.
Can you please elaborate on your above comment a little bit more @swankjesse !! That would be very helpful.
private SSLSocketFactory defaultFactory;
to
private SSLSocketFactory delegate;
Thanks @iNoles ! I had a complete different thing in mind :) This was easy.
Can confirm that it works with private SSLSocketFactory delegate. And I won't question it ;)
@swankjesse I also don't know whyyy Crittercism is doing anything with SSL. So I'm also not sure how I'll be able to help you out with getting the SSLSocketFactory.
Hi, same issue Here wirh the Crittercism API.
Hey there, also seeing the same issue. Specifically with the combination of Crittercism and Optimizely...
Still same issue with Crittercism.
Caused by: java.lang.IllegalStateException: Unable to extract the trust manager on okhttp3.internal.Platform$Android@256897c7, sslSocketFactory is class crittercism.android.q
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:187)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:151)
@aryarohit07 that’s a strange class name, crittercism.android.q. Does it say the same thing if you disable ProGuard?
The critterism sdk comes pre-obfuscated using proguard.
Attached is a simple decompilation of that class - it's a custom SSLSocketFactory.
There's a public SSLSocketFactory a; in there.
I am seeing this crash in my app when I have Crittercism 5.5.1 and OkHttp 3.2, however it only occurs when I have proguard enabled for my app. When I build with it disabled the app works. It makes me think this might be resolvable by an additional keep command.
Out of curiosity: is it possible to use/create interface to get trust manager from and allow users write custom implementations instead of relying on field name and trying to get it via reflection?
@swankjesse I am getting this error even with proguard disabled. And as @ikoz says, I think critterism sdk is already minified using proguard.
The issue is only with OkHttp version >= 3.1.0
@artem-zinnatullin neat idea. Wanna send a PR to explore further? Not sure it’ll work out because then the delegate will still need to get the trust manager, but it’s worth writing some code.
Hey @swankjesse !
Looking to figure out the issue, I saw that you are extracting SSLContext as below:
public X509TrustManager trustManager(SSLSocketFactory sslSocketFactory) {
// Attempt to get the trust manager from an OpenJDK socket factory. We attempt this on all
// platforms in order to support Robolectric, which mixes classes from both Android and the
// Oracle JDK. Note that we don't support HTTP/2 or other nice features on Robolectric.
try {
Class<?> sslContextClass = Class.forName("sun.security.ssl.SSLContextImpl");
Object context = readFieldOrNull(sslSocketFactory, sslContextClass, "context");
if (context == null) return null;
return readFieldOrNull(context, X509TrustManager.class, "trustManager");
} catch (ClassNotFoundException e) {
return null;
}
}
Our code tries to use javax.net.ssl.SSLContext instead of sun.security.... Could we either add some code here to look for that too, if nothing.
That should solve a lot of issues. I am trying to setup dev machine to test this out, but running into sun.security.* class not found issues.
Hi All -- I'm with Crittercism (renamed recently to Apteligent). We are also investigating this issue. If you're still having issues please contact [email protected] and we'll keep you updated.
I'm one of the developers responsible for the Crittercism Android SDK.
crittercism.android.q is a custom socket factory that we use to wrap the default socket factories. We delegate socket generation to the original socket factories and wrap newly generated sockets with our own socket which is used to monitor network performance (url, bytes sent, bytes received, latency, status code, and exceptions thrown when talking to that socket).
Two solutions I can imagine:
1) Create an interface for retrieving the TrustManager. We'd have to implement it on our end.
2) We make our factory subclass OpenSSLSocketFactory (using some compilation tricks).
We're finishing a large change to our network monitoring code at the moment, which needs to be wrapped up before starting on these changes. That'll be about 2-3 weeks.
Hey @dshirley! So we meet again! One option is to name the delegate socket factory delegate. OkHttp has a hack that looks for this field, and if its present the right thing happens automatically.
Hey @swankjesse. I figured it would be a matter of time :-)
It turns out we actually _do_ give our delegate factory the variable name "delegate"... but ProGuard changes it. It should be an easy fix. I believe we'll just need to update our OkHttp regression tests to use the latest version.
For others that are watching, we're still wrapping up some large changes to our networking monitoring code. We should be able to get to this in about 2-3 weeks.
I have the same issue as the OP with Retrofit 2.0.0 and okhttp 3.2.0.
Wildfly 10, java8, and any version > 3.0.1:
Unable to extract the trust manager on okhttp3.internal.Platform@10c89bdf, sslSocketFactory is class sun.security.ssl.SSLSocketFactoryImpl
@dshirley Confirming the same crash with Crittercism and Retrofit 2.0.1. Leaving Crittercism out of production builds temporarily solves the problem.
Hi, i have the same issue with Crittercism. Look's like SSLParametersImpl package name can differ on differnt android versions.

Platform class is searching for com.google.android.gms.org.conscrypt.SSLParametersImpl and actual package name is com.android.org.conscrypt.SSLParametersImpl
@swankjesse updating Parse Android SDK and ran into this same issue. Even using the SSLCertficateFactory() call seems to break. See https://github.com/ParsePlatform/Parse-SDK-Android/pull/435/files#r58793351. Do you think this call is redundant given we already set socket timeouts earlier?
We are still experiencing this issue when using Crittercism and OkHttp 3.2.0
Event with latest Crittercism 5.6.1RC and OkHttp3.2.0 - result the same - crash while application start.
The latest snapshot has a new API that lets you specify the SSLSocketFactory and TrustManager independently. Using that should resolve your problems.
@swankjesse thanks for the suggestion! I was already using reflection to set certain fields so the internal reflection would not run (kind of ironic if you think about it)
Edit: tested, and it works, thanks! Current solution looks like this:
@Provides
public X509TrustManager provideX509TrustManager() {
try {
TrustManagerFactory factory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
factory.init((KeyStore) null);
TrustManager[] trustManagers = factory.getTrustManagers();
return (X509TrustManager) trustManagers[0];
} catch (NoSuchAlgorithmException | KeyStoreException exception) {
Log.e(getClass().getSimpleName(), "not trust manager available", exception);
}
return null;
}
@Provides
public SSLSocketFactory provideSSLSocketFactory(X509TrustManager trustManager) {
try {
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(null, new TrustManager[]{trustManager}, null);
return sslContext.getSocketFactory();
} catch (NoSuchAlgorithmException | KeyManagementException exception) {
Log.e(getClass().getSimpleName(), "not tls ssl socket factory available", exception);
}
return (SSLSocketFactory) SSLSocketFactory.getDefault();
}
@Provides
public OkHttpClient provideHttpClient(SSLSocketFactory sslSocketFactory, X509TrustManager trustManager) {
return new OkHttpClient.Builder()
.sslSocketFactory(sslSocketFactory, trustManager)
.build();
}
@swankjesse Any idea on when 3.3.0 will be released?
No estimates. Historically we release every 2–4 months.
For the Apteligent Android SDK, we've made some changes in version 5.6.2 that should address the issue. You can find the downloadable file for the version here:
https://app.crittercism.com/downloads/download/crittercism_v5_6_2_sdkonly.jar
The 2nd problem is currently if you want to pass an SSL session cache, you have to pass in a SSL Socket factory:
OkHttpClient.Builder builder = new OkHttpClient.Builder();
builder.sslSocketFactory(SSLCertificateSocketFactory.getDefault(socketOperationTimeout, sslSessionCache));
But even for stock Android SSLCertificateSocketFactory relies on com.android.org.conscrypt.OpenSSLContextImpl so the trust manager code fails looking for sun.security.ssl.SSLContextImpl.
It turns out the Parse Android SDK, which includes OkHttp2, can't be upgraded until we get to 3.3.0.
I attempted to do so just now and ran into the issue here. https://github.com/ParsePlatform/Parse-SDK-Android/pull/435/files#r58793351
I can get around the issue by using the snapshot version and implementing the code to get the default trust manager:
private X509TrustManager systemDefaultTrustManager() {
try {
TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(
TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init((KeyStore) null);
TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
if (trustManagers.length != 1 || !(trustManagers[0] instanceof X509TrustManager)) {
throw new IllegalStateException("Unexpected default trust managers:"
+ Arrays.toString(trustManagers));
}
return (X509TrustManager) trustManagers[0];
} catch (GeneralSecurityException e) {
throw new AssertionError(); // The system has no TLS. Just give up.
}
}
And then later:
builder.sslSocketFactory(SSLCertificateSocketFactory.getDefault(socketOperationTimeout, sslSessionCache), systemDefaultTrustManager());
So waiting for the 3.3.0 release before Parse's Android SDK implementation can be bumped to use OkHttp3. :)
One request though if it's possible to make systemDefaultTrustManager() publicly exposed somehow (or at least yanked out of OkHttpClient.java)...otherwise we're going to just reimplement the code. :)
Confirmed that the Crittercism 5.6.2 update fixes the issue, thanks for the heads up @jkang-critter
@jkang-critter when Crittercism 5.6.2 update fix will be integrated in cordova-plugin-apteligent ?
I was able to make it work with Retrofit 2.0.2 and Crittercism 5.5.5, but I had to disable service monitoring via CrittercismConfig.
EDIT: see response below
@codebaum You shouldn't have to disable service monitoring anymore. The bug was fixed in Crittercism 5.6.1. An even later version (5.6.3( is now available.
@dshirley Never mind, I thought it wasn't working with 5.6.3-rc-1 but I re-tested and I'm not seeing a crash anymore.
Just a friendly ping to see if we can get a fix/release for this issue. Trying to get things updated for the Parse SDK so would want to have a way to make a call to systemDefaultTrustManager()
I have read the discussion on this issue, however I am totally confused by all the discussion on 3rd party libraries that just use OkHttp. My major problem is that I neither do see a clear description why this error is occurring nor how to fix it (or better how to get around it).
I am using plain OkHttp 3.2.0 and Android with my custom SSLSocketFactor and TrustManager implementation.
I'm personally getting this error with Retrofit2 v2.0.2:
Unhandled exception: java.lang.IllegalStateException: Unable to extract the trust manager on okhttp3.internal.Platform@29eaf7d1, sslSocketFactory is class sun.security.ssl.SSLSocketFactoryImpl
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:187) [okhttp-3.2.0.jar:]
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:60) [okhttp-3.2.0.jar:]
at okhttp3.OkHttpClient$Builder.build(OkHttpClient.java:718) [okhttp-3.2.0.jar:]
Using OkHttp 3.3.0-SNAPSHOT fixed the issue for me.
Was fixed here by using Crittercism v5.6.3
When Crittercism v5.6.3 will be integrated in cordova-plugin-apteligent ?
Right now it's using release 5.5.2 and I still have the issue in my hybrid app.
Hey so i'm running both Crittercsim 5.6.4 and OkHttp V3.3.0 and still facing the crash. Any update on how to fix it ?
We're also having this crash. Only on Androids 4.0 and 4.1.
+1 Having this same issue on retrofit:2.1.0, I'm simply trying to build an instance of retrofit on the setUp method of a test.
I'm not event using roboelectric, I am using Mockito and PowerMock though
testCompile 'org.mockito:mockito-core:1.10.19'
testCompile 'org.powermock:powermock:1.6.5'
testCompile 'org.powermock:powermock-module-junit4:1.6.5'
testCompile 'org.powermock:powermock-api-mockito:1.6.5'
@Before public void setUp() throws Exception {
MockitoAnnotations.initMocks(this);
Retrofit retrofit = new Retrofit.Builder()
.baseUrl(BuildConfig.BASE_URL)
.build(); //Crash here -> java.lang.AssertionError at okhttp3.OkHttpClient.systemDefaultTrustManager(OkHttpClient.java:260)
}
Full stacktrace:
java.lang.AssertionError
at okhttp3.OkHttpClient.systemDefaultTrustManager(OkHttpClient.java:260)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:228)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:203)
at retrofit2.Retrofit$Builder.build(Retrofit.java:551)
at com.productify.urge.usecase.GetCategoriesUseCaseTest.setUp(GetCategoriesUseCaseTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.internal.runners.MethodRoadie.runBefores(MethodRoadie.java:133)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:96)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:300)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:131)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.access$100(PowerMockJUnit47RunnerDelegateImpl.java:59)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner$TestExecutorStatement.evaluate(PowerMockJUnit47RunnerDelegateImpl.java:147)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.evaluateStatement(PowerMockJUnit47RunnerDelegateImpl.java:107)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:82)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:288)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:50)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:208)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:147)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:121)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:123)
at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:121)
at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:59)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Can you put a breakpoint on OkHttpClient.java:260 and see what the cause is?
Sure, the following line on OkHttpClient.java
private X509TrustManager systemDefaultTrustManager() {
try {
TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(
TrustManagerFactory.getDefaultAlgorithm());
Throws this exception:
java.security.NoSuchAlgorithmException: class configured for TrustManagerFactory:
sun.security.ssl.TrustManagerFactoryImpl$PKIXFactory not a TrustManagerFactory
TrustManagerFactory.getDefaultAlgorithm() returns the string: "PKIX"
Hope that helps
@feresr looks like PowerMock is causing you harm here.
http://stackoverflow.com/questions/14654639/when-a-trustmanagerfactory-is-not-a-trustmanagerfactory-java
@swankjesse Yes, thank you! that was exactly it. that solved my issue.
Why Class.forName("sun.security.ssl.SSLContextImpl") has not found here?
Class<?> sslContextClass = Class.forName("sun.security.ssl.SSLContextImpl");
Result message:
ERROR org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/].[ProxyServlet] Servlet.service() for servlet ProxyServlet threw exception: java.lang.IllegalStateException: Unable to extract the trust manager on okhttp3.internal.Platform@67ec7968, sslSocketFactory is class sun.security.ssl.SSLSocketFactoryImpl
at okhttp3.OkHttpClient.
at okhttp3.OkHttpClient.
at okhttp3.OkHttpClient$Builder.build(OkHttpClient.java:718) [okhttp-3.2.0.jar:]
at com.graphhopper.api.GraphHopperWeb.
at com.graphhopper.api.GraphHopperWeb.
From the code:
final GraphHopperWeb gh = new GraphHopperWeb();
Server: JBoss AS 7.1.1.Final "Brontes"
pom.xml:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>routeplanner2</groupId>
<artifactId>routeplanner2</artifactId>
<packaging>war</packaging>
<version>2.0</version>
<name>routeplanner2</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.6</maven.compiler.source>
<maven.compiler.target>1.6</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-6.0</artifactId>
<version>1.0.0.Final</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.googlecode.objectify</groupId>
<artifactId>objectify</artifactId>
<version>5.1.10</version>
</dependency>
<dependency>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-api-1.0-sdk</artifactId>
<version>1.8.9</version>
</dependency>
<!-- GraphHopper -->
<dependency>
<groupId>com.graphhopper</groupId>
<!-- artifactId>graphhopper-core</artifactId>
<version>0.8-SNAPSHOT</version -->
<artifactId>graphhopper</artifactId>
<version>0.7.0</version>
<exclusions>
<exclusion>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>xmlgraphics-commons</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.graphhopper</groupId>
<artifactId>directions-api-java-client</artifactId>
<version>0.7.0.1</version>
</dependency>
</dependencies>
<profiles>
<profile>
<id>openshift</id>
<build>
<finalName>routeplanner2</finalName>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<outputDirectory>deployments</outputDirectory>
<warName>ROOT</warName>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
okhttp:3.1.2 and retrofit 2.0.2 but still getting the issue
java.lang.IllegalStateException: Unable to extract the trust manager on okhttp3.internal.Platform
I experienced this error while using a custom SocketFactory. I realized I didn't add all the necessary ProGuard rules. I added the following to fix the issue:
-keepclassmembers class * implements javax.net.ssl.SSLSocketFactory {
private final javax.net.ssl.SSLSocketFactory delegate;
}
In my SocketFactory class, I had the following field:
private final SSLSocketFactory delegate;
So adjust the ProGuard rule accordingly. E.g, the access modifiers like private, final, etc. as well as the field name (delegate) should match exactly as written in the class file.
@swankjesse iam not getting why wont it work without the delegate hack
@JeffreyCA ooooooof you saved my life :))
private SSLSocketFactory delegate; works :+1:
Most helpful comment
I experienced this error while using a custom
SocketFactory. I realized I didn't add all the necessary ProGuard rules. I added the following to fix the issue:In my SocketFactory class, I had the following field:
So adjust the ProGuard rule accordingly. E.g, the access modifiers like
private,final, etc. as well as the field name (delegate) should match exactly as written in the class file.