4

I am getting following exception while calling https webservice.

com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present.

I am calling a php webservice from Java code. The CN (Common Name) i.e. the IP address on certificate and the IP address I am calling are different. I have added the certificate in keystore of java. Can someone help me out why this is happening? Where I am going wrong? The CN is the server IP address. I am calling that server using its external IP address given too us because of firewall issue.

Bruno
  • 119,590
  • 31
  • 270
  • 376
Swapnil Walivkar
  • 295
  • 3
  • 5
  • 15
  • I solved this exceptio with the help of @noloader's solution, but now I am getting different error.. It seems this error is because of , I have added certificate in java keystore. Do I need to add it in truststore? – Swapnil Walivkar Mar 26 '14 at 05:54

2 Answers2

3

Java clients normally comply strictly with RFC 2818 when it comes to checking the server's identity with an IP address. This means the IP address has to be in a Subject Alternative Name entry, not in the CN. This this question for details.

Fixing the certificate to comply with RFC 2818 (i.e. put the IP address in an IP Address SAN) should fix the java.security.cert.CertificateException: No subject alternative names present. exception.

However, since you're not calling the server with the IP address in the certificate, you'll still have a problem. You get two options:

  • If you can get someone to fix the certificate, put two SAN entries, for internal and external IP addresses. This is by far the best option (only second best to setting up a name on that machine, which could prevent this sort of problems a bit better).

  • Import only that certificate in the truststore used by that connection and disable hostname verification. Do not disable hostname verification in general. The problem with disabling hostname verification is that any valid certificate can impersonate any other, which could be used for a MITM attack. If the only certificate you trust is that of the only server you want to connect to (which you can do by having a separate trust store just for this purpose) you limit this risk. As often, coding for these exceptional cases leads to bad legacy code that someone may pick up and use insecurely later. For this reason, fixing the certificate is by far the better option.

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
3

The CN (Common name) i.e. IP on certificate is different and the IP i am calling is different.

...

HTTP transport error: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present.

When a name is present in the Common Name (CN), it must also be present in the Subject Alternate Name (SAN). You have a malformed certificate (and it might have other problems). See Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Section 9 (pages 9 & 10):

9.2.2 Subject Common Name Field

Certificate Field: subject:commonName (OID 2.5.4.3)

Required/Optional: Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 9.2.1).

Bruno can probably cite the relevant section from RFC 6125.

jww
  • 97,681
  • 90
  • 411
  • 885
  • Ha... Actually, RFC 6125 doesn't specify anything for IP addresses, it's in the ["out of scope" section](http://tools.ietf.org/html/rfc6125#section-1.7.2). The section you quote from the CA Browser baseline spec is more about what to put in the CN when there's a SAN, not about the fact there needs to be a SAN when using an IP address. In addition, that spec is not used by Java, and oddly enough, browsers tend not to follow RFC 2818 (by accepting IP addresses in CN without them being in a SAN). – Bruno Mar 21 '14 at 11:00
  • It's just my opinion, but I'm not sure I'd refer too much to the CA Browser forum documents in general (they seem more related to a push for EV certs in general, quite possibly with some vested interested by CAs). After all, the Baseline req. you link to doesn't refer once to RFC 2818, and barely seems to know the difference between "the Internet" and "the Web" (see introduction: "*[... only ...] authenticating servers accessible through the Internet. Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions.*")! – Bruno Mar 21 '14 at 11:12
  • @noloader: Thanks, That worked for me. But now I am getting new exception. javax.xml.ws.soap.SOAPFaultException: SOAP-ERROR: Parsing WSDL: Couldn't find in '/var/www-ssl/ingram/wsdls/deviceprofileInfoAnother.wsdl'. I have added certificate in java keystore, I think I need to add it in truststore. Please help me out with this... – Swapnil Walivkar Mar 26 '14 at 05:48