SSL SNI Support in Workbench

Root and intermediary certificates have already been imported, as indicated above, this works now.

What does not work, however, is SNI. My understanding was that as of Java 7 SNI just works, and looking into jetty’s installation.properties I have the following line:

jetty.ssl.sniHostCheck=true

I would have thought that should be enough to work with the certificate which is signed to CN cms.example.com, but has cms-dev.example.com and cms-uat.example.com in subject alternate names. Connecting to the host which has CN set in the certificate works. Connecting to the host which is only in the subject alternate name, for example cms-dev.example.com works as far as establishing the connection, but consecutive operations fails. For example, clicking on Content Explorer in Workbench and trying to unfold any of the items returns:

Does this mean anything to you?

Note: This conversation was created from a reply on: Rhythmyx Jetty Workbench SSL.

Hi,

I think this is an issue with the SAN certificate and not SNI.  There is a backlogged issue related to SAN certificates and the HttpClient that the Workbench is using, so this will most likely not work correctly until we get that patched.  The common name will work correctly, but the Alternative names will not. 

It looks like this improvement was added on the CM1 line of the Workbench already (CMS-1546), so it may just be a matter of merging that update into the Rhythmyx line to get SAN support added.

https://serverfault.com/questions/807959/what-is-the-difference-between-san-and-sni-ssl-certificates

We will create a support ticket to track this on your behalf and post a fix or workaround here once the problem is resolved. 

-n

The patch including the update for SAN certificate support has been released.  https://community.percussion.com/percussion/topics/new-patch-for-rhythmyx-7-3-2-available