Develop Reference

Robolectric test that uses OkHttp for real HTTP requests throws java.lang.NullPointerException: No password supplied for PKCS#12 KeyStore

I'm using Robolectric 4.3.1 (testImplementation "org.robolectric:robolectric:4.3.1") to create an Android sqlite environment for my integration tests. My system uses OkHttp (implementation 'com.squareup.okhttp3:okhttp:3.14.7') for real HTTP requests. I'm not using MockWebServer.
After I upgraded to the Android 10 SDK, I had to update my unit test JVM to JDK 9, per the Robolectric instructions:
Running tests on Android API 29 now strictly requires a Java9 runtime or newer. If you are seeing errors about unsupported Java version when running tests on API 29 via Android Studio; you can use the 'JRE' field in the Run Configuration dialog to configure a newer Java runtime. See https://developer.android.com/studio/run/rundebugconfig for more background.
However, now my integration tests fail with:
java.lang.NullPointerException: No password supplied for PKCS#12 KeyStore.
at org.bouncycastle.jcajce.provider.keystore.pkcs12.PKCS12KeyStoreSpi.engineLoad(Unknown Source)
at java.base/java.security.KeyStore.load(KeyStore.java:1479)
at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:367)
at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:315)
at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:59)
at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:51)
at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:278)
at okhttp3.internal.Util.platformTrustManager(Util.java:640)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:228)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:202)
How can I make real HTTP calls again?

TLDR
to workaround this problem, set the javax.net.ssl.trustStoreType system property to JKS:
-Djavax.net.ssl.trustStoreType=JKS
Details
I found this workaround:
After trying many things I finally found one workaround:
System.setProperty("javax.net.ssl.trustStore", "NONE")
MockWebServer()
The tests are passing with this additional configuration.
However, when I tried that workaround, all of my HTTP calls failed with the following ConnectException instead:
java.net.ConnectException: Failed to connect to myhost.com:443
at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:265)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:183)
at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.java:224)
at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.java:108)
at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.java:88)
at okhttp3.internal.connection.Transmitter.newExchange(Transmitter.java:169)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:41)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:94)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:88)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:229)
at okhttp3.RealCall.execute(RealCall.java:81)
I suspect that OkHttp rightly denies all TLS connections because it doesn't trust them since the workaround suggests setting the javax.net.ssl.trustStore to NONE.
I also tried specifying the default password for java truststores, changeit via this workaround:
Workaround: -Djavax.net.ssl.trustStorePassword=changeit
But then I got the following exception when trying to instantiate an OkHttpClient:
java.lang.AssertionError: No System TLS
at okhttp3.internal.Util.platformTrustManager(Util.java:648)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:228)
at okhttp3.OkHttpClient.<init>(OkHttpClient.java:202)
which was caused by:
Caused by: java.security.KeyStoreException: problem accessing trust store
at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:75)
at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:278)
at okhttp3.internal.Util.platformTrustManager(Util.java:640)
... 22 more
Caused by: java.io.IOException: stream does not represent a PKCS12 key store
at org.bouncycastle.jcajce.provider.keystore.pkcs12.PKCS12KeyStoreSpi.engineLoad(Unknown Source)
at java.base/java.security.KeyStore.load(KeyStore.java:1479)
at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:367)
at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:315)
at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:59)
at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:51)
... 24 more
This was a great clue. I started debugging the JDK 9 source with Android Studio, and I noticed that when I ran with org.junit.runners.BlockJUnit4ClassRunner, my KeyStore.keystoreSpi was a sun.security.pkcs12.PKCS12KeyStore$DualFormatPKCS12, but when I ran with org.robolectric.RobolectricTestRunner my KeyStore.keystoreSpi was a org.bouncycastle.jcajce.provider.keystore.pkcs12.PKCS12KeyStoreSpi$BCPKCS12KeyStore.
According to JEP-229:
This feature changes the default keystore type from JKS to PKCS12. By default, new keystores will be created in the PKCS12 keystore format. Existing keystores will not change and keystore applications can continue to explicitly specify the keystore type they require.
Existing applications must not be disrupted. Keystores tend to be long-lived, so we need to support access across several JDK releases. Applications that access keystores created by earlier JDK releases must run unaltered on JDK 9. Similarly, applications that access keystores created by JDK 9 should run unaltered on earlier JDK releases.
This requirement is achieved by introducing a keystore detection mechanism that understands both the JKS and PKCS12 formats. A keystore's format is examined before it is loaded to determine its type and then the appropriate keystore implementation is used to access it. The mechanism is enabled by default but can be disabled if required.
Support for this keystore-detection mechanism may be backported to earlier JDK releases.
Thus, the classic $JAVA_HOME/lib/security/cacerts is still a Java Key Store, which I could verify:
$ file /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home/lib/security/cacerts
/Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home/lib/security/cacerts: Java KeyStore
However, since the JDK wants to default to PKCS12 keystores, the JDK's DualFormatPKCS12 will fall back to a JKS if reading a file as PKCS12 fails. Bouncycastle assumes that when the javax.net.ssl.trustStoreType is pkcs12 that is really what we mean.
Thus, to workaround this problem, set the javax.net.ssl.trustStoreType system property to JKS:
-Djavax.net.ssl.trustStoreType=JKS
I filed issues with bouncycastle and robolectric about this.

If you're facing this issue with Robolectric, upgrade the version to 4.4 as these has been resolved in version 4.4
testImplementation ('org.robolectric:robolectric:4.4')

Dealing with TLS on gRPC

I am connecting to a server which has TLS support with SSL certs. I am getting a SSL Handshake error on Android app client. I also use useTransportSecurity() to deal with TLS negotiation type. Is there any workaround to get away with this error without certificate pinning?
Error encountered:
Caused by: java.lang.RuntimeException: protocol negotiation failed
at io.grpc.okhttp.OkHttpProtocolNegotiator.negotiate(OkHttpProtocolNegotiator.java:96)
at io.grpc.okhttp.OkHttpProtocolNegotiator$AndroidNegotiator.negotiate(OkHttpProtocolNegotiator.java:147)
at io.grpc.okhttp.OkHttpTlsUpgrader.upgrade(OkHttpTlsUpgrader.java:63)
at io.grpc.okhttp.OkHttpClientTransport$2.run(OkHttpClientTransport.java:474)
at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
And this is how I generate my channel :
ManagedChannel mChannel = OkHttpChannelBuilder.forAddress(host, port)
.useTransportSecurity()
.build();
Appreciate your time and help.

ALPN is failing during the TLS handshake, which prevents gRPC from negotiating HTTP/2. Either you aren't connecting to a gRPC / HTTP/2 server or your client's TLS library is too old.
Please review the SECURITY.md documentation. Namely, you probably want to "install" the Play Services Dynamic Security Provider into the runtime when your app starts.

it might be rather a matter how you create the server; see SECURITY.md for Mutual TLS ...
Server server = NettyServerBuilder.forPort(8443)
.sslContext(GrpcSslContexts.forServer(certChainFile, privateKeyFile)
.trustManager(clientCAsFile)
.clientAuth(ClientAuth.REQUIRE)
.build());

Answering my own question.
This error comes from the ALPN TLS extension, which I needed my SSL endpoint to support. I was using NPN, and that is why I was unable to connect.
Posted by Carl Mastrangelo in grpc.io google groups

Intermittent and continuous SSLHandshakeException while connecting to android.googleapis.com/gcm/

We are facing some issues in connecting to Google’s GCM API (https://android.googleapis.com/gcm/send ) for Android push notifications from our server (SSLHandshakeException).
From 28th February to 8th March 2018 the issue was intermittent(push sent sometimes, SSL handshake error otherwise). From 9th March 2018 the issue is continuous.
Please see the logs below. Would like to know if there was any changes to the issued certificates.
com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:151)

I do not fully understand the details, but when I update our push provider/server "External Services Certs" and add the cert below.. my push started working again. So even though the Equifax cert that I originally installed 2 years ago was working until a few weeks ago, something changed on the GCM server and that cert was no longer valid. It has an expiration date of Aug 2018, which is near, but should not expire till that date.
I did notice that the new cert is SHA256 and the original is SHA1, so maybe this is a required security upgrade. It kind of screws me since my push content providers are distributed, not in a single location where it is easy to update the cert :(
The cert that fixed my issue is:
-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMFQxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxJTAjBgNVBAMTHEdvb2dsZSBJbnRlcm5ldCBBdXRob3JpdHkgRzMw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKUkvqHv/OJGuo2nIYaNVW
XQ5IWi01CXZaz6TIHLGp/lOJ+600/4hbn7vn6AAB3DVzdQOts7G5pH0rJnnOFUAK
71G4nzKMfHCGUksW/mona+Y2emJQ2N+aicwJKetPKRSIgAuPOB6Aahh8Hb2XO3h9
RUk2T0HNouB2VzxoMXlkyW7XUR5mw6JkLHnA52XDVoRTWkNty5oCINLvGmnRsJ1z
ouAqYGVQMc/7sy+/EYhALrVJEA8KbtyX+r8snwU5C1hUrwaW6MWOARa8qBpNQcWT
kaIeoYvy/sGIJEmjR0vFEwHdp1cSaWIr6/4g72n7OqXwfinu7ZYW97EfoOSQJeAz
AgMBAAGjggEzMIIBLzAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHfCuFCa
Z3Z2sS3ChtCDoH6mfrpLMB8GA1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYu
MDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdv
b2cvZ3NyMjAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dz
cjIvZ3NyMi5jcmwwPwYDVR0gBDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYc
aHR0cHM6Ly9wa2kuZ29vZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEA
HLeJluRT7bvs26gyAZ8so81trUISd7O45skDUmAge1cnxhG1P2cNmSxbWsoiCt2e
ux9LSD+PAj2LIYRFHW31/6xoic1k4tbWXkDCjir37xTTNqRAMPUyFRWSdvt+nlPq
wnb8Oa2I/maSJukcxDjNSfpDh/Bd1lZNgdd/8cLdsE3+wypufJ9uXO1iQpnh9zbu
FIwsIONGl1p3A8CgxkqI/UAih3JaGOqcpcdaCIzkBaR9uYQ1X4k2Vg5APRLouzVy
7a8IVk6wuy6pm+T7HT4LY8ibS5FEZlfAFLSW8NwsVz9SBK2Vqn1N0PIMn5xA6NZV
c7o835DLAFshEWfC7TIe3g==
-----END CERTIFICATE-----
I obtained it by running this openssl cmd and it is the second one in the chain. That CAfile parm is robably not needed, since I did not have that file and there was a complaint, but the required cert chain was still displayed.
openssl s_client -connect gcm-http.googleapis.com:443/gcm/send -debug -showcerts -CAfile entrust_2048_ca.cer

The issue was due to GeoTrust to GoogleTrust migration of the SSL certificates for googleapis.com. Issue got fixed when we imported new certificate from the URL: https://android.googleapis.com and added to our server's trust store.

Kari - that is what I figured. Thanks for replying.. but the URL you list gives 404.. can you double check and update if you have the correct URL.

I am seeing the same issue and the same SSL error. Any more discussion on this?

Suddenly getting "Error: TrustFailure (The authentication or decryption has failed.)" on my Xamarin Android app

Just out of the blue, my app started getting this error when making calls to a REST API via https. I was working on a mod that added an Intent to handle opening files of a certain file extension but I doubt that that was the cause.
Instead, the problem is similar to this one:
Invalid certificate received from server
My cert is also by Comodo and has been installed since April of this year. The solution of disabling the COMODO RSA Certification Authority did not work.
The server is a VPS that the host underwent a hardware upgrade during the time that this error started to appear but I'm also not sure that that would be the reason since the browser shows SSL as fine and the iOS version of the app is also working fine.
The code in the app that makes the call to the server is in a utility class and I did not change that code at all. The minor change that I did was to add an intent which I then removed and the error is still there.
Here are the error messages including the inner exceptions and the stack trace:
System.Net.WebExceptionStatus.TrustFailure
ex.InnerException.Message - The authentication or decryption has failed.
ex.InnerException.InnerException.InnerException.Message - Invalid certificate received from server. Error code: 0xffffffff800b010b
ex.InnerException.InnerException.StackTrace
at Mono.Security.Protocol.Tls.RecordProtocol.EndReceiveRecord (System.IAsyncResult asyncResult) [0x0003a] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/RecordProtocol.cs:430
at Mono.Security.Protocol.Tls.SslClientStream.SafeEndReceiveRecord (System.IAsyncResult ar, System.Boolean ignoreEmpty) [0x00000] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs:256
at Mono.Security.Protocol.Tls.SslClientStream.NegotiateAsyncWorker (System.IAsyncResult result) [0x00071] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs:418
ex.InnerException.StackTrace
at Mono.Security.Protocol.Tls.SslStreamBase.EndRead (System.IAsyncResult asyncResult) [0x00051] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslStreamBase.cs:883
at Mono.Net.Security.Private.LegacySslStream.EndAuthenticateAsClient (System.IAsyncResult asyncResult) [0x00011] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/System/Mono.Net.Security/LegacySslStream.cs:475
at Mono.Net.Security.Private.LegacySslStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, System.Security.Authentication.SslProtocols enabledSslProtocols, System.Boolean checkCertificateRevocation) [0x00000] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/System/Mono.Net.Security/LegacySslStream.cs:445
at Mono.Net.Security.MonoTlsStream.CreateStream (System.Byte[] buffer) [0x0004e] in /Users/builder/data/lanes/3511/501e63ce/source/mono/mcs/class/System/Mono.Net.Security/MonoTlsStream.cs:106
I'm using the standard port 443. I checked the bindings and there are no issues, it says that the cert is 'ok' when I view the certification path status.
I am getting the error when using an actual device, not an emulator.
Any help is appreciated.
***** update
I called Comodo's support and found out the issue is with Android's certificate store not being up to date and using the old legacy SHA. So the certification path 2 was coming back to the client with a 'Extra Download' status. There supposedly is a cert named 'COMODO RSA Certification Authority' in my server expiring in 2036 that interferes with 'COMODO RSA Certification Authority' intermediate certificate expiring in 2020. Here are the details of that cert:
[Root] Comodo RSA Certification Authority (SHA-2)
Serial Number: 4c:aa:f9:ca:db:63:6f:e0:1f:f7:4e:d8:5b:03:86:9d
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
Validity (Expires) : Jan 18 23:59:59 2038 GMT
However, I couldn't find out in both local computer and current user. Since this is a VPS/virtual machine, the problem may be that the host machine may be adding this in the virtual network communication/response back to the client. The problem now is that the hosting company doesn't want to disable the cert in the host machine.

I got it working. As I mentioned in my update above, the issue is with Android's certificate store not being up to date and using the old legacy SHA. So the certification path 2 was coming back to the client with a 'Extra Download' status. There is a cert named 'COMODO RSA Certification Authority' in expiring in 2036 that interferes with 'COMODO RSA Certification Authority' intermediate certificate expiring in 2020. I had already deleted it that's why I couldn't find it anymore.
The fix is to find & disable or delete this cert, replace it with new certs downloaded from Comodo's website, and rebooting the machine.
Here are the details of the cert to disable/delete:
[Root] Comodo RSA Certification Authority (SHA-2)
Serial Number: 4c:aa:f9:ca:db:63:6f:e0:1f:f7:4e:d8:5b:03:86:9d
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
Validity (Expires) : Jan 18 23:59:59 2038 GMT
The new certs are:
comodorsadomainvalidationsecureserverca.crt
comodorsaaddtrustca.crt
addtrustexternalcaroot.crt
I can't find the page where I downloaded all three from, the Comodo tech support rep helped me navigate to this page.
To disable the cert, go into Certification Manager from the MMC, right click to open, click on the Details tab, click on the Edit Properties button and in the Certificate Purposes area, choose the 'Disable for all purposes' radio option.
Import the new certs and reboot.
And instead of using SSLChecker, I recommend SSL Server Test by Qualys SSL Labs (https://www.ssllabs.com/ssltest/index.html) as it's more accurate & detailed.

MobileFirst Adapter - FWLSE0152E: Unable to find certificate chain with alias: 'mydomain.com' for HTTPS protocol

I have followed the steps as mentioned in below url :
Configuring SSL between MobileFirst adapters & back-end servers by using self-signed certificates.
After performing above steps, I am able to see the certificate in key store with correct alias name 'mydomain.com'. However, when I try to invoke the procedure which has defined in HTTP adapter to make a call to back end server using HTTPS, below exception has thrown in worklight server console.
FWLSE0152E: Unable to find certificate chain with alias: 'mydomain.com'
Could you please provide any suggestions which would help us to resolve this issue.

Looks like the CN of your backend server is not equals to backend domain name that you defined in the adapter xml file.
If the CN=mydomain.com try to export public certificate from backend keystore and import it into adapter's keystore using open ssl library.