images

VMware Horizon View – Connection Server Services dont load with Public SSL Cert

So my colleague rang me the other week with a bit of weird issue. After installing the VMware Horizon View Connection Server, the services do not start after installing Public SSL, and replacing the self-signed SSL.

The environment
  • Server 2012 R2 fully patched
  • Installing Connection Server, services fine
  • Install Public Cert (Following VMware guidelines for creation)
    • Used Cert Req tool
    • Connection Server Service fails to start.

2014-11-24_23-35-41

The Logs

We found in the Connection Server logs;

2014-10-23_08-31-512014-10-23_08-40-21

2014-10-23T09:36:43.054+01:00 ERROR (0AE8-1130)  [cd] IOException executing request http://127.0.0.1:8123/reset : Connection to http://127.0.0.1:8123 refused com.vmware.vdi.ob.tunnelservice.cd.b(SourceFile:784)
org.apache.http.conn.HttpHostConnectException: Connection to http://127.0.0.1:8123 refused
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:159)
    at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
    at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
    at com.vmware.vdi.ob.tunnelservice.cd.b(SourceFile:780)
    at com.vmware.vdi.ob.tunnelservice.cd.f(SourceFile:647)
    at com.vmware.vdi.ob.tunnelservice.cd.run(SourceFile:234)
Caused by: java.net.ConnectException: Connection refused: connect
    at java.net.DualStackPlainSocketImpl.connect0(Native Method)
    at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
    at java.net.Socket.connect(Socket.java:579)
    at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:123)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:133)
    ... 9 more
2014-10-23T09:36:43.055+01:00 ERROR (0AE8-1130)  [cd] Error executing requess

After going through all the steps slowly one by one, we kept hitting the same issue, so rang VMware support.

The above logs basically mean the Service cannot find the private key for the certificate. However VMware Support confirmed that the certificate was created correctly and the key was exportable (for what its worth we also used the same SSL for the view composer service, which worked).

In the end, VMware couldn’t pinpoint the issue, so went back to the drawing board. In the mean time, I tried a few different things, and I found this article online about Certreq tool from Microsoft when using Subject Alternative Names in the request. (Can’t find the link for the life of me at the moment).

The article states that there is a known issue with using the certreq tool to create a CSR with SAN information, and to ensure it is created properly use Server 2008 R2 machine to create the CSR.

The Fix

Basically the issue surrounds creating a CSR for a SSL with Subject Alternative Names in it, on Server 2012 R2 using the certreq tool.

We reproduced this error on different Server 2012 R2 servers, but when we decided to use a Server 2008 R2 machine, the SSL worked fine on the Server.

Not entirely sure why this is, but when using the online service http://certlogik.com/decoder/ we found that the CSR did not show the SAN information.

Regards

 

Dean


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.