[MGNLDIFF-10] Diff throws NullPointerException when using SSL Created: 14/Feb/11 Updated: 04/Nov/15 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia Diff Module |
| Component/s: | None |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | 1.0.x |
| Type: | Bug | Priority: | Major |
| Reporter: | Frank Rittinger | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Ubuntu, Tomcat behind Apache with Apache runnning with SSL Support |
||
| Attachments: |
|
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
Hi Magnolia, when we try to view differences of a page between versions (using the new diff module) we always receive a NullPointerException. It seems that the fromHTML Stream is null. See attached Stacktrace: java.lang.NullPointerException java.io.StringReader.<init>(StringReader.java:33) info.magnolia.module.diff.VersionDiffHtmlGenerator.diff(VersionDiffHtmlGenerator.java:60) info.magnolia.module.diff.VersionDiffHtmlServlet.getVersionDiffHtml(VersionDiffHtmlServlet.java:173) info.magnolia.module.diff.VersionDiffHtmlServlet.doGet(VersionDiffHtmlServlet.java:98) |
| Comments |
| Comment by Frank Rittinger [ 14/Feb/11 ] |
|
I just saw these additional Exceptions in the stack trace, which seem to be related but make no sense to me. Why would the system try to fetch its own content via SSL? 2011-02-14 09:38:45,583 ERROR info.magnolia.module.diff.VersionDiffHtmlServlet : Can't get source from URL '/magnoliaAuthor/en/career/events.html'.
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Certificate chaining error
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1649)
<...>
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at info.magnolia.module.diff.VersionDiffHtmlServlet.getVersionSource(VersionDiffHtmlServlet.java:183)
at info.magnolia.module.diff.VersionDiffHtmlServlet.getVersionDiffHtml(VersionDiffHtmlServlet.java:171)
at info.magnolia.module.diff.VersionDiffHtmlServlet.doGet(VersionDiffHtmlServlet.java:98)
|
| Comment by Frank Rittinger [ 14/Feb/11 ] |
|
Hi Magnolia, using the site without SSL, the diffing works. I just don't understand why? Any insights? Regards, Frank |
| Comment by Federico Grilli [ 14/Feb/11 ] |
|
Hi Frank, this actually looks strange as, under the hood, the diff module uses org.apache.commons.httpclient.HttpClient which should work out-of-the-box with HTTP over Secure Sockets Layer (SSL). The stacktrace might indicate that either your certificate is not valid or that Java Security is not configured correctly. You might want to execute this small program to verify if this is the case. Thanks, Federico import java.io.BufferedReader; import java.io.InputStreamReader; import java.io.OutputStreamWriter; import java.io.Writer; import java.net.Socket; import javax.net.ssl.SSLSocketFactory; public class Test { public static final String TARGET_HTTPS_SERVER = "www.verisign.com"; public static final int TARGET_HTTPS_PORT = 443; public static void main(String[] args) throws Exception { Socket socket = SSLSocketFactory.getDefault(). createSocket(TARGET_HTTPS_SERVER, TARGET_HTTPS_PORT); try { Writer out = new OutputStreamWriter( socket.getOutputStream(), "ISO-8859-1"); out.write("GET / HTTP/1.1\r\n"); out.write("Host: " + TARGET_HTTPS_SERVER + ":" + TARGET_HTTPS_PORT + "\r\n"); out.write("Agent: SSL-TEST\r\n"); out.write("\r\n"); out.flush(); BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream(), "ISO-8859-1")); String line = null; while ((line = in.readLine()) != null) { System.out.println(line); } } finally { socket.close(); } } } |
| Comment by Frank Rittinger [ 14/Feb/11 ] |
|
Hi Federico, your little programm runs fine on the live server. It also works from my development pc when connecting to the live authoring instance. Which URL is used by the diffing module and why does it go through HTTPS? However, running it on the live server with the authoring domain and URL, I get the following Error: Exception in thread "main" 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 sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1665)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:258)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:252)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1165)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:154)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:546)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:913)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1158)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:652)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:78)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:290)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:294)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:140)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
at Test.main(Test.java:27)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:324)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:224)
at sun.security.validator.Validator.validate(Validator.java:235)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:147)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:230)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:270)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1144)
... 13 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:197)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:255)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:319)
... 19 more
Regards, Frank |
| Comment by Federico Grilli [ 14/Feb/11 ] |
|
Hi Frank, the diff module actually uses the complete URL to the content, as if it accessed to it from external. The technical reason behind that I honestly don't know (but I am sure it is a compelling one that accept self-signed certificates. There probably lies the problem. I would say that what you hit is most likely a bug. I am going to create a new jira ticket for that. Best regards, Federico Grilli |
| Comment by Frank Rittinger [ 14/Feb/11 ] |
|
Hi Federico, the certificate we have, is a genuine one, but it looks like one of the intermediate certificates is not present in the standard JDK 6 keystore. I imported that into the keystore. I have to wait for tonight to test that, since I can't restart the server now ... I'll get back to you tomorrow morning. Thanks for your advice. Regards, Frank |
| Comment by Federico Grilli [ 14/Feb/11 ] |
|
Hi Frank, OK, then I will wait for your test results before turning this into a bug report Thank you, Federico |
| Comment by Frank Rittinger [ 16/Feb/11 ] |
|
Hi Federico, adding the intermediate certificate did not help the issue. I still get the same warnings about invalid certification path. A way to bypass the HTTPS would be great, since everything is on the same machine. Any help would be appriciated. regards, Frank |
| Comment by Federico Grilli [ 17/Feb/11 ] |
|
Hi Frank, sorry to hear that. Next step now is to turn this into a bug report. I'm going to do that. Regards, Federico |
| Comment by Jan Haderka [ 21/Feb/11 ] |
|
Hi Frank,
Thanks. |
| Comment by Frank Rittinger [ 23/Feb/11 ] |
|
Hi Jan,
I'm still wondering why we have to go over HTTPS to fetch the versions of a page? Isn't this an overhead since it is no security problem fetching the pages via HTTP on the same machine? Regards, Frank |
| Comment by Magnolia International [ 22/Mar/11 ] |
|
moved irrelevant part of stacktrace to an attachment for readability. |
| Comment by Frank Rittinger [ 11/Apr/11 ] |
|
Hi magnolians, we experimented with every idea we had; added all intermediate certificats to any possible JRE or system location and changed length restrictions on the system. Unfortunaltely without luck. The little program you gave us, runs fine from the command line. We can even access our own site with it. wget is happy now as well. The only system that still has problems is the version differ of magnolia. We set most of the code to debug level and the EasyX509TrustManager prints out the correct certificats but than hands control over to standard SUN classes and they lead to certificate chaining errors as mentioned above ... ;-( Do you have any further ideas? Regards, Frank |
| Comment by Jan Haderka [ 11/Apr/11 ] |
|
Hi Frank, is the exception stacktrace still the same as originally reported or has anything changed after adding all the certificates and changing restrictions? Can you also try to disable GZIP and Cache filters on the remote possibility that they might interfere? Thanks, |
| Comment by Frank Rittinger [ 13/Apr/11 ] |
|
Hi Jan, I disabled the filters but with no success. The stack trace is still the same: CertificatChaining error, although the EasyX509TrustManager logs the correct three certificates that are needed and than hands over control to the standard Sun TrustManager which fails:
Caused by: sun.security.validator.ValidatorException: Certificate chaining error
at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:140)
at sun.security.validator.Validator.validate(Validator.java:218)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209)
at info.magnolia.module.diff.ssl.EasyX509TrustManager.checkServerTrusted(EasyX509TrustManager.java:119)
|
| Comment by Jan Haderka [ 13/Apr/11 ] |
|
Ok, I think i got it now. :~$ java -version java version "1.6.0_11" Java(TM) SE Runtime Environment (build 1.6.0_11-b03) Java HotSpot(TM) Server VM (build 11.0-b16, mixed mode) Look in synaptic for "Sun JDK" (you might have to enable some extra repositories to see it) or download it directly and install manually from Sun/Oracle website. With Sun JDK everything should work fine. |
| Comment by Frank Rittinger [ 13/Apr/11 ] |
|
Hi Jan, we also had that thought and switched to the Sun JDK ... ;-( @static /var/lib/tomcat6/instances # java -version java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) The tomcat runs with same JDK. We double checked that. Regards, Frank |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |