The "local host" used as the common name in the default WSo2 certificate does not create any alternative subject names

Question

We used wso2 esb (version 4.0.3) to publish our web service. Our web service was added as a proxy service using the admin console in wso2. We want to expose / consume our web service only using https. After creating the stub, we did the following

• Create a jks file using java keytool.
• The wso2 certificate is exported and imported into the jks file.
• When adding the following web service, the following is added in the code.

System.setProperty ("javax.net.ssl.trustStore", "filename"); System.setProperty ("javax.net.ssl.trustStorePassword", "password");

Doing all this when we try to call a web service from java code, it only works when the URL is set using localhost. It does not work with 127.0.0.1 or the IP address of the computer, although we do have the correct mapping in the host file. When using the ip address, we get an error like javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present . This error occurs because the default certificate provided by wso2 has "localhost" as the common name. We can get rid of this problem by adding the following code snippet

  HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() { public boolean verify(String string, SSLSession ssls) { return true; }}); 

But this can lead to security problems. Please suggest us how to solve this problem.

Answer 1

This error occurs when the host name does not match the CN certificate. I can provide you two solutions.

• If you only need access to the service with an IP address, simply create a certificate with the correct IP address as the value for the CN value of the server certificate. You can use Java Keytool.
• If you want to use both the IP address and the host name to access the service, generate a certificate containing alternative object names (SANs). Java Keytool with Java 7 is able to generate certificates with SAN. Otherwise, use any other tool, such as OpenSSL, or use the certificate issued by the CA with the SAN.