HTTPS request using Sendega SMS

Enonic version: 6.7.2
OS: Ubuntu 14.04.5 LTS

Hello everyone,

I’m trying to create a service to send SMS messages using Sendega.
For some reason Enonic is throwing a “Hostname not verified” error.

Here is the full error message:
javax.net.ssl.SSLPeerUnverifiedException: Hostname smsc.sendega.com not verified: certificate: sha1/T6MymE6L3G/HojxbNmshqP8iwOc= DN: CN=smsc1.sendega.com subjectAltNames: [smsc1.sendega.com] (java.lang.RuntimeException)

Any ideas?

BTW: I have other services sending requests to HTTPS working fine.

The SSL certificate seems correct. But it contains “smsc1.sendega.com” in the server name. The browsers don’t complain, so maybe the Java HTTP library we use is a bit more strict.

openssl s_client -connect smsc.sendega.com:443 -showcerts
CONNECTED(00000003)
depth=1 /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
Certificate chain
 0 s:/CN=smsc1.sendega.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=smsc1.sendega.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---

If you try to connect to “smsc1.sendega.com” , instead of “smsc.sendega.com”, it seems to work. And both names point to the same IP address. So maybe that is a workaround.

1 Like

Hi Aro, I am having the same problem, this error shows when I try httpClientLib.

The URL is this " https://app.opoint.com/api/feeds/684509a1-60d3-4e6d-aa17-b325d3411d57/view/ ".

javax.net.ssl.SSLPeerUnverifiedException: Hostname app.opoint.com not verified: certificate: sha1/eLTZPGfe010o1J1Xnns/ch2YRYI= DN: CN=api.opoint.com subjectAltNames: [api.opoint.com] (java.lang.RuntimeException)

The URL is this " https://app.opoint.com/api/feeds/684509a1-60d3-4e6d-aa17-b325d3411d57/view/ ".

It looks like it’s the same case as the one above. The certificate we get back is for api.opoint.com, which has the same IP address than app.opoint.com. When I try making the request from java or from command line, I get a certificate with a host that does not match (api.opoint.com != app.opoint.com)

$ openssl s_client -connect app.opoint.com:443 | openssl x509 -noout -subject -issuer
depth=1 /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
subject= /CN=api.opoint.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

But all the browsers I tried, validate and accept the certificate without warnings.

I tried upgrading to the latest version of the HTTP lib we use (OkHttp), but it did not help.

Which web server are you using? Could you post the SSL config here?

Chiming in with the same problem, and the same cert authority.

I’m trying to consume https://snl.no/api/v1/search?query=xp&limit=5&offset=0

I’m getting this error:
javax.net.ssl.SSLPeerUnverifiedException: Hostname snl.no not verified: certificate: sha1/NroKloeb/Zt5UWXHQcpxGbrnJNc= DN: CN=media.snl.no subjectAltNames: [media.snl.no] (java.lang.RuntimeException)

Examining the certificate gives this error:

Checking with openssl gives this error:

openssl s_client -connect snl.no:443 -showcerts CONNECTED(00000003) 9432:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52.40.1/src/ssl/s23_clnt.c:593:

However, Chrome is having no problems using the endpoint, and shows a green padlock to indicate that all is ok.

1 Like

I showed the errors in this thread to a friend of mine who has done similar troubleshooting in the past (although he is by no means an expert), and his immediate reaction was:
“That’s just an error you get when you don’t have the required certificate locally. If the process that does the request is Java, then the local Java machine needs to get that certificate somehow.”

I tried adding the relevant certificates to $JAVA_HOME/jre/lib/security/cacerts with keytool, but this doesn’t seem to do anything for Enonic XP’s ability to access this connection.

In my specific case, it seems that snl.no has two certificates. One for media.snl.no (which fails), and one for all the other domains they have, including snl.no (which seems to pass). I have added both certificates to cacerts.

I’ll make a proper support request for my specific problem, but the solution is probably interesting for the others in this thread. If there is some other way of getting Enonic XP to do this itself, I would like to know. I’d hate to have to fetch renewed certificates regularly in the future.

The issue is with hosts that have multiple SSL certificates for different domains. The request validates the certificate, but when it checks if the certificate domain matches with the host in the HTTPS request, it fails because it has received the certificate for another domain on the server.

We will look more into this and try to get some kind of fix for the 6.9 release.

Good stuff, please fix :smile:

While we wait for the fix: As a workaround, it is possible and pretty easy to set up a reverse proxy, terminating the ssl connection and exposing a normal http connection to Enonic XP.

1 Like

I think I found the problem, and maybe a quick solution so you don’t need to wait for 6.9.

We need to set the JVM property jsse.enableSNIExtension to true, to enable SNI for SSL connections.

Can you try this command, before starting XP (on Unix/Linux), and confirm if it fixes the issue for you?
export JAVA_OPTS=-Djsse.enableSNIExtension=true

Or else change the value to true, in server.sh

Explanation from Java documentation:
http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html

Server Name Indication (SNI) is a TLS extension, defined in RFC 6066. It enables TLS connections to virtual servers, in which multiple servers for different network names are hosted at a single underlying network address.
Some very old SSL/TLS vendors may not be able handle SSL/TLS extensions. In this case, set this property to false to disable the SNI extension.

5 Likes

Great news everyone! It works! :smiley:

Will this be default setting in XP from 6.9 then? What about the keystore etc - no need to use this at all then?

Djsse.enableSNIExtension=true

Thx Aro, it did work.

Yes, it will be the default setting from 6.9. True is actually the default value in the JVM, our start up scripts were setting it to false.
For those connecting to very old servers not supporting SNI extensions, it will have to be set to false. Hopefully those are not so common nowadays.

Normally there is no need to change the keystore, most root certificates included in browsers are also included in the JVM.