0

I have a Tomcat Java app that is trying to make the following request:

https://www.googleapis.com/oauth2/v4/token?scope=profile+email

I see when it attempts to write to the connection that it fails.

conn.getOutputStream().write(content);

where the content being written to the body was the data shown above. It throws the following error:

java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)

When I hook up Fiddler to Tomcat, I can see the request just prior to that was successfull sent: https://accounts.google.com/o/oauth2/v2/auth But I never actually see in Fiddler the next request being sent that fails to the URL: https://www.googleapis.com/oauth2/v4/token

based on this and the message that it prints, it seems like it fails when preparing the data to send.

The problem sounds like something with SSL and certificates. I downloaded the two certificates for the URL https://www.googleapis.com/oauth2/v4/token and installed them into first Tomcat's keystore and then the truststore. (First added it to the keystore and when that didn't work, I added to the trustsstore. That didn't fix the problem.

Since I log the data that's being written to the output stream, I tried to manually copying the request body data from the log file including the code returned from Google and pasting it into a the Chrome extension "Rest Console". When I do that it works. But I see that Chrome already has a certificate installed for https://www.googleapis.com, so maybe that is the reason why the request from the browser worked.

In the oAuth1 version of this code, I don't think that we needed to install certificates. Also, when I run the Java example from the Google oAuth2, unless the certificates are somehow packaged with Jetty, I don't see that they are installed. So, I am not positive that certificates are the problem.

In Tomcat, I tried to turn on debugging for SSL by adding the following to the Tomcat JVM startup:

-Djavax.net.debug=ssl,session,defaultctx,trustmanager,keymanager

That writes lots of information, but there was nothing being written just prior to the error occurring.

How can I determine what is wrong?

=================================

Here is the stack trace:

  2018-03-19 08:32:11,324  DEBUG [scribe.model.Request] [http-bio-8080-exec-11] 
  java.security.NoSuchAlgorithmException: Error constructing implementation 
  (algorithm: Default, provider: SunJSSE, class: 
  sun.security.ssl.SSLContextImpl$DefaultSSLContext)
   2018-03-19 08:32:11,324  DEBUG [scribe.model.Request] [http-bio-8080-exec-11] 
  java.lang.Throwable:
        at org.scribe.model.Request.addBody(Request.java:153)
        at org.scribe.model.Request.doSend(Request.java:113)
        at org.scribe.model.Request.send(Request.java:69)
        at org.scribe.model.OAuthRequest.send(OAuthRequest.java:12)
        at org.scribe.oauth.OAuth20ServiceImpl.getAccessToken(OAuth20ServiceImpl.java:38)
        at ch.gadp.alfresco.OAuthSSOAuthenticationFilter.getUserProfile(OAuthSSOAuthenticationFilter.java:192)
        at ch.gadp.alfresco.OAuthSSOAuthenticationFilter.processRequestToken(OAuthSSOAuthenticationFilter.java:331)
        at ch.gadp.alfresco.OAuthSSOAuthenticationFilter.doOAuthAuthentication(OAuthSSOAuthenticationFilter.java:375)
        at ch.gadp.alfresco.OAuthSSOAuthenticationFilter.doFilter(OAuthSSOAuthenticationFilter.java:428)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Unknown Source)
George Hernando
  • 2,550
  • 7
  • 41
  • 61
  • maybe duplicate, see : https://stackoverflow.com/questions/6365209/java-and-ssl-java-security-nosuchalgorithmexception – Eugène Adell Mar 19 '18 at 19:52
  • The other article suggests turning on ssl debug and double checking the stack trace. I will the stacktrace, but don't see any clues there. – George Hernando Mar 19 '18 at 20:09
  • it says there was a typo (keystorepassword / keypassword) – Eugène Adell Mar 19 '18 at 20:22
  • I don't see anything that looks like a (server) cert problem, but the only throws for that exception in java.security.Provider always set a cause that should be displayed in the stacktrace as a section beginning 'Caused by:' -- don't you have that? – dave_thompson_085 Mar 19 '18 at 23:17
  • No. There is no "caused by". The error was being ignored and nothing was showing up in the log, so there is a try/catch around the conn.getOutputStream().write(content) that writes the stacktrace when the error occurs. – George Hernando Mar 19 '18 at 23:55

0 Answers0