[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: Text File MGNLDIFF-10.SSL.stacktrace.txt     Text File MGNLDIFF-10.stacktrace.txt    
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 ), as I am not the person who developed the module. What I have also seen by digging in in the source code is that instead of relying on plain HttpClient support for http over ssl, a custom class EasySSLProtocolSocketFactory is used, the reason being that it can create SSL

{@link Socket}

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,

  • could you please provide output of java -version command?
  • If running older JVM, please consider upgrade to the latest one. There were recently delivered some fixes related to the issue (e.g. http://bugs.sun.com/view_bug.do?bug_id=6958869 )
  • please turn on certpath debugging by adding the following option to the java command line: -Djava.security.debug=certpath This will generate a lot of output, but it should give you more info as to why the certificate chain is invalid.
  • try to access tomcat over https directly rather then going via apache to see if it has any effect.

Thanks.

Comment by Frank Rittinger [ 23/Feb/11 ]

Hi Jan,

  • output of java -version
    java version "1.6.0_20"
    OpenJDK Runtime Environment (IcedTea6 1.9.2) (6b20-1.9.2-0ubuntu1~10.04.1)
    OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
    
  • our tomcat is not configured for HTTPS since this is handled by the apache in front of it. Tomcat and apache communicate via AJP.
  • Although no browser has a problem with the certificates, wget on the same server also has a problem with them and claims that they are self signed. It looks like these certificates (not generated by us, so we can't change them) are not 100% genuine for our server infrastructure.

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,
Jan

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.
Looking at your java version you have installed OpenJDK/IcedTea, but not the Sun JDK.
The correct string should look like:

:~$ 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.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 05:20:29 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.