Bug ID: JDK-4450669 handshaking with certain hosts is throwing a NullPointerException

Type: Bug
Component: security-libs
Sub-Component: javax.net.ssl
Affected Version: 1.0.2

Priority: P5
Status: Closed
Resolution: Duplicate
OS: generic
CPU: generic

Submitted: 2001-04-25
Updated: 2001-04-25
Resolved: 2001-04-25

A customer writes on the java-security alias, with JDK 1.3 or
below and JSSE 1.0.2.


While connecting to www.isoco.com

java.io.IOException: java.io.IOException: java.lang.NullPointerException

        at
com.sun.net.ssl.internal.ssl.HandshakeMessage$CertificateMsg.<init>([
DashoPro-V1.2-120198])
        at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage([DashoPr
o-V1.2-120198])
        at
com.sun.net.ssl.internal.ssl.Handshaker.process_record([DashoPro-V1.2
-120198])
        at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
        at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
        at
com.sun.net.ssl.internal.ssl.AppOutputStream.write([DashoPro-V1.2-120
198])
        at java.io.OutputStream.write(Unknown Source)
        at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake([DashoPro-V
1.2-120198])
        at TestSSL.send(TestSSL.java:95)
        at TestSSL.main(TestSSL.java:299)

EVALUATION We've been trying to duplicate this for a while, and we were finally able to get a host whose certificates would do this reliably... This bug is a duplicate of: Fixed 4395895: Cannot import certain X.509 certficates with the Sun JCA implementation. Again Which was fixed in merlin beta by seemam. In the JSSE area, this is the full traceback. main, READ: SSL v3.1 Handshake, length = 1145 java.security.cert.CertificateParsingException: java.io.IOException: java.lang.NullPointerException at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:157) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1044) at sun.security.x509.X509CertImpl.<init>(X509CertImpl.java:149) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:89) at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:286) at com.sun.net.ssl.internal.ssl.HandshakeMessage$CertificateMsg.<init>(HandshakeMessage.java:362) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:124) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:253) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.clearPipeline(SSLSocketImpl.java:762) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.write(SSLSocketImpl.java:559) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:71) at java.io.OutputStream.write(OutputStream.java:61) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1743) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.doConnect(HttpsClient.java:369) at com.sun.net.ssl.internal.www.protocol.https.NetworkClient.openServer(NetworkClient.java:42) at com.sun.net.ssl.internal.www.protocol.https.HttpClient.openServer(HttpClient.java:572) at com.sun.net.ssl.internal.www.protocol.https.HttpClient.<init>(HttpClient.java:314) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.<init>(HttpsClient.java:241) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.New(HttpsClient.java:265) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.New(HttpsClient.java:254) at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.connect(HttpsURLConnection.java:394) at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.getInputStream(HttpsURLConnection.java:492) at java.net.URL.openStream(URL.java:798) at URLReader.main(URLReader.java:37) I'm opening this bug because it has been frequently asked by customers on the java-security list, but we were never able to duplicate it as customers would drop the bug report with a hostname and run. bradford.wetmore@eng 2001-04-25 Jeff Nisewanger added: For the record, certificates like that are broken so this really wasn't a "bug" although we should have generated a better parsing exception. The specifications say that the alternative names extensions must contain at least one name. In 1.4 we will parse these for compatibility purposes with certificates which were incorrectly generated. See http://www.ietf.org/rfc/rfc2459.txt?number=2459 section 4.2.1.7 and 4.2.1.8.

02-09-2004