Trusting ceritificates where CN does not match website hostname

[js]

JDK 1.4.2_08

I am getting the following exception:

javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: No trusted certificate found
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA12275)
at
org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:224)


I have imported the certificate into the cacerts file via keytool -import.

However, my problem is that, the operator has setup a development and
production website, where the hostname naturally differs ... but both
development and production URLs have the same certificate.

That is, the production, Verisign-signed server certificate is the same
certificate on the development website. This ceritificate, therefore, has
the common-name ( CN ) set to the hostname of the production website.

Thus, even if I import the certificate into the cacerts file, because the
server certificate' CN does not match hostname of the website, I get the
exception above when connecting to their development website.

Apart from implementing DummyTrustManager as per this article:

http://www.javaworld.com/javatips/jw-javatip115.html

.... which I'd rather not, is there any other workaround ??

 

[Roedy Green]

I have imported the certificate into the cacerts file via keytool -import.

If you check your machine, there may be dozens of cacerts files. Make
sure you have the right one. See
http://mindprod.com/jgloss/cacerts.html

 

[js]

If you check your machine, there may be dozens of cacerts files. Make
sure you have the right one. See
http://mindprod.com/jgloss/cacerts.html

I am sure I have the right imported into correct cacerts file.

The problem is that, normally, even for a development server with a
self-signed server certificate, the CN on the server certificate matches
the hostname the development server URL. But in this case, the CN does not
match, and hence, importing it into the server certificate into cacerts
file will not work.

I have worked around this for now by using overriding a TrustManager to
trust the server no matter what.

 

[Roedy Green]

The problem is that, normally, even for a development server with a
self-signed server certificate, the CN on the server certificate matches
the hostname the development server URL. But in this case, the CN does not
match, and hence, importing it into the server certificate into cacerts
file will not work.

I have worked around this for now by using overriding a TrustManager to
trust the server no matter what.

This is as it should be. Otherwise you could buy a cert for company A
then use it all over the place where it was not certified.

 

[Chris Smith]

This is as it should be. Otherwise you could buy a cert for company A
then use it all over the place where it was not certified.

I hope you don't expect us to cry over potential lost revenue for
Verisign...

In any case, the point behind verifying the CN on a server certificate
is that you protect against man-in-the-middle attacks, in which a router
or DNS server is compromised so that when the user tries to visit
www.paypal.com, they are actually redirected over to a different site
instead. Since Verisign (or Thawte, or whoever) supposedly won't issue
a certificate with a CN of "www.paypal.com" except to the owner of that
site, the attacker would be unable to obtain a certificate with the
correct CN.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation