CertificateException: No subject alternative names

Question

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.

Answer 1

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.

Answer 2

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.