FULL PRODUCT VERSION :
java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b19)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed mode)


FULL OS VERSION :
 customer  Windows 2000 [Version 5.00.2195]


EXTRA RELEVANT SYSTEM CONFIGURATION :
NOT APPLICABLE

A DESCRIPTION OF THE PROBLEM :
The following program throws the following CertificateParsingException.

This wasn't happening in previous versions of the JRE, specifically:
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)


This program contains the CA certificate of a  customer  Certificate Server. The certificate contains two X.509 v3 extensions called  "CRL Distribution Points". One of the CRL Distribution Points contains a uniform resource identifier that is in the following  customer -specific form:

file://\\lea\CertEnroll\Lea%20CA.crl



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Save the following certificate as '.\lea.cer'.

2. Create the directory '.\tools\'.

3. Create the directory '.\tools\crypto\'.

4. Save the following program as '.\tools\crypto\CertTest.java':

5. Compile CertTest.java

6. Run CertTest.java

java -cp . tools.crypto.CertTest lea.cer



ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.security.cert.CertificateParsingException: java.io.IOException: java.io.IOException: Host portion is not a
valid DNS name, IPv4 address, or IPv6 address
        at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:157)
        at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1679)
        at sun.security.x509.X509CertImpl.<init>(X509CertImpl.java:173)
        at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:101)
        at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:389)
        at tools.crypto.CertTest.doTest(CertTest.java:28)
        at tools.crypto.CertTest.main(CertTest.java:42)
Caused by: java.io.IOException: java.io.IOException: Host portion is not a valid DNS name, IPv4 address, or IPv6 address
        at sun.security.x509.CertificateExtensions.parseExtension(CertificateExtensions.java:111)
        at sun.security.x509.CertificateExtensions.init(CertificateExtensions.java:78)
        at sun.security.x509.CertificateExtensions.<init>(CertificateExtensions.java:57)
        at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:731)
        at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:155)
        ... 6 more
Caused by: java.io.IOException: Host portion is not a valid DNS name, IPv4 address, or IPv6 address
        at sun.security.x509.URIName.parseName(URIName.java:205)
        at sun.security.x509.URIName.<init>(URIName.java:85)
        at sun.security.x509.GeneralName.<init>(GeneralName.java:94)
        at sun.security.x509.GeneralNames.<init>(GeneralNames.java:51)
        at sun.security.x509.DistributionPoint.<init>(DistributionPoint.java:193)
        at sun.security.x509.CRLDistributionPointsExtension.<init>(CRLDistributionPointsExtension.java:126)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
        at sun.security.x509.CertificateExtensions.parseExtension(CertificateExtensions.java:105)
        ... 10 more


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Run this program using the certificate shown earlier.



/*
 * CertTest.java
 *
 * Created on May 9, 2003, 11:30 AM
 */
                                                                                                                
package tools.crypto;
                                                                                                                
import java.io.*;
import java.security.cert.*;
                                                                                                                
/**
 *
 */
public class CertTest {
    private File inputFile;
                                                                                                                
    /** Creates a new instance of CertTest */
    public CertTest(String[] args) {
        inputFile = new File(args[0]);
    }
                                                                                                                
    public void doTest() {
        try {
            CertificateFactory factory = CertificateFactory.getInstance("X.509");
            FileInputStream fis = new FileInputStream(inputFile);
            Certificate certificate = factory.generateCertificate(fis);
            if (!(certificate instanceof X509Certificate)) {
                System.out.println("Not an X.509 certificate");
                System.exit(0);
            }
            X509Certificate x509 = (X509Certificate)certificate;
            System.out.println(x509.toString());
        }
        catch (Exception e) {
            e.printStackTrace(System.out);
        }
    }
                                                                                                                
    public static void main(String[] args) {
        new CertTest(args).doTest();
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Reconfigure  customer  Certificate Server to not generate CRL distribution points of the form:

file://\\hostname\path

Release Regression From : 1.4.1_02
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 187022) 
======================================================================

N/A

Parsing seems to fail when encountering the URL "file://\\lea\CertEnroll\Lea%20CA.crl" . I am not totally sure if that is a valid URL, but regardless we should not fail in this way.

It would seem a good idea to ignore such a failure - either using code specifically in the CRLDP extension or generally for all extensions - so that failures parsing (non-critical) extensions are just ignored.

Regardless, it would also seem appropriate to change the URIName class to use java.net.URI instead of doing its own parsing. This has caused problems before, for example see 4834694.

  xxxxx@xxxxx   2003-06-04

The certificate parsing code has been modified to ignore errors parsing non-critical extensions, which avoids this particular failure. However, it also means that we will not utilize the CRLDP extension in these certificates. A separate bug will be filed to track the final resolution of this issue.

  xxxxx@xxxxx   2003-06-18

One company was issuing certs with OID 2.5.29.16, which is the 
Private Key Usage Period, and was a non-critical extension.  Without
this fix, customer couldn't parse the cert file.  Will refer him to 1.4.2_02.

  xxxxx@xxxxx   2003-08-29

For those reading on the JDC, 1.4.2_02 is expected to be released in late October or early November 2003. Thanks for bearing with us.

  xxxxx@xxxxx   2003-09-12

I see some comments have been added on the JDC. If you are seeing this problem or a similar one in 1.4.2_02 or later, please file a new bug and include the cert that is causing the exception.

To make sure that you are using the intended 1.4.2 version, you may want to use "java -showversion MyProgram" and double check the version number.

  xxxxx@xxxxx   2004-06-16

Like I said in my previous comment, if you think you still see this problem post 1.4.2_02, please file a new bug and include the cert. Posting a comment that does not include nearly enough information to reproduce is not helpful at all.

  xxxxx@xxxxx   2004-11-10 01:31:20 GMT

Release fixed in Tiger -- you mean I have to wait until 1.5
to get this fix?  How about in a patch release to 1.4.2? 
This bug is keeping me from moving to all the new exciting
performance enhancements in 1.4.2.

You could use the BouncyCastle 
(http://www.bouncycastle.org) security provider with 1.4.2. 
It parses these certificates OK.

Many people do not have this option.  Our organization has its 
own Microsoft Certificate Server, and issues a large number of 
corporate certificates for various secure sites.  We are about 
to roll out the Sun Java Plug-in to 4000+ machines, and I had 
wanted to deploy 1.4.2_01, since it is not only the latest and 
greatest, but is the JVM that we've done most of our testing 
with.  Now I can't do that.  I've got to roll out 1.4.1_05 
instead, _and_ I have to enforce it's use until such time as 
this heinous bug is fixed.
Anyone have any idea when 1.4.2_02 is expected to be 
released?

The WildID service also issues certificates that use 
this URL format (presumably for compatibility with 
Microsoft).

I am getting this bug using 1.4.2_03. Has this bug been reintroduced in _03 after being fixed in _02?

Same problem in 1.4.2_04?  MS Certificate Server is Win2k3.

still a problem for me in 1.4.2.06