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.
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.
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)
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.
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.
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
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.
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.