10-01-2018 08:21 AM
I succesfully installed Hexagon App Launcher.
When starting a desktop app, the launcher fails to load descrptor with following message:
Error while loading descriptor from https://127.0.0.1/api/v1/desktopclient/73cfec84-c356-4939-9e18-fe5b6da9e48b.hnlp?tenant=Rutka&refreshToken=50736988-a704-438f-b784-f9b539669225. java.io.IOException: No subject alternative names matching IP address 127.0.0.1 found at java.net.http/jdk.internal.net.http.HttpClientImpl.send(Unknown Source) at java.net.http/jdk.internal.net.http.HttpClientFacade.send(Unknown Source) at com.hexagon.applauncher.core/com.hexagon.applauncher.core.AppLauncher.loadDescriptor(Unknown Source) at com.hexagon.applauncher.core/com.hexagon.applauncher.core.AppLauncher.init(Unknown Source) at com.hexagon.applauncher.core/com.hexagon.applauncher.core.AppLauncher.lambda$start$0(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) Caused by: javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP address 127.0.0.1 found at java.base/sun.security.ssl.Alert.createSSLException(Unknown Source) at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source) at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source) at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(Unknown Source) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(Unknown Source) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(Unknown Source) at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source) at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown Source) at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown Source) at java.base/java.util.ArrayList.forEach(Unknown Source) at java.net.http/jdk.internal.net.http.common.SSLFlowDelegate.lambda$executeTasks$3(Unknown Source) at java.net.http/jdk.internal.net.http.HttpClientImpl$DelegatingExecutor.execute(Unknown Source) at java.net.http/jdk.internal.net.http.common.SSLFlowDelegate.executeTasks(Unknown Source) at java.net.http/jdk.internal.net.http.common.SSLFlowDelegate.doHandshake(Unknown Source) at java.net.http/jdk.internal.net.http.common.SSLFlowDelegate$Reader.processData(Unknown Source) at java.net.http/jdk.internal.net.http.common.SSLFlowDelegate$Reader$ReaderDownstreamPusher.run(Unknown Source) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(Unknown Source) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(Unknown Source) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(Unknown Source) ... 3 more Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address 127.0.0.1 found at java.base/sun.security.util.HostnameChecker.matchIP(Unknown Source) at java.base/sun.security.util.HostnameChecker.match(Unknown Source) at java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(Unknown Source) at java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(Unknown Source) at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(Unknown Source) at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(Unknown Source) ... 22 more
Solved! Go to Solution.
10-01-2018 08:34 AM
Are you using a self-signed certificate? I had a similar error with my self-signed certificate. My workaround was to access the Apps page over HTTP instead of HTTPS. That launched the client successfully.
10-01-2018 08:40 AM
yes, I am using the delivered certficate for demo-purposes here.
Your workaround with HTTP instead of HTTPS worked fine! Thanks!
10-01-2018 12:17 PM
http is a way to go arround, but not a solution and dont know if the services within the client will all run under http.
10-01-2018 12:41 PM
the solution is indeed to load a proper SSL certificate. For testing purposes you can use http without issues.
10-02-2018 04:01 AM
I've just launched the desktop client successfully over HTTPS. I created a new self-signed certificate in IIS Manager and selected the new certificate for the HTTPS binding on the MApp web site. Ensure you access the apps page using the correct URL that is shown as "Issued to". If this is a machine connected to a domain the issued to URL will be a fully qualified domain name.
The certificate generated by the M.App Enterprise installer has a strange issued to address that doesn't match a URL you would enter in a web browser hence why I tried with my own self-signed certificate.
Hope this works for others as a solution instead of reverting to HTTP. Of course for production/customer environmentd do not use self-signed certificates. Obtain a certificate from a certificate authority.
10-02-2018 04:42 AM
instead suing self-signed certifcates switch to Let's encrypt. It is even simpler to get a vaild cert compared to generate a slef-sgined cert.
Just follow the instrucions on this site: https://github.com/PKISharp/win-acme
To sum it up:
download and unzip the package, run letsencrypt.exe and follow the menu on the screen. As simple as such.
10-02-2018 06:55 AM
Interesting suggestion. I've not come across Let's encrypt before.
I've tried to run the executable but it fails to create the certificate due to a "DNS problem: NXDOMAIN looking up A for <FQDN of server>
This is for an internal server (Windows Server 2016 with IIS installed) that is not accessible from the internet.
10-02-2018 07:11 AM
unfortunately your server must be accessible via its public DNS name from the Internet.
Let's Encrypt will proof that this name is vaild be connecting to your server. But this is only possible if it avialable via http from the outside world. Here you should find more information: https://letsencrypt.org/how-it-works/
It works well if this requirement is fullfilled. All modern browsers do accept the certificates and it is free.