[QUOTE=allana;10531]If anyone reads this and can provide advice, please do!
I installed the certificate I received, importing it to cacerts under JRE\lib\security, and Rhythmyx starts up successfully and says it’s listening on port 9443 for https requests. I had to create a new .keystore file for the certificate I was supplied because whenever I tried to use the one which was used to generate the CA certificate request there was an error saying the keystore file was corrupt or the password was wrong.
But when I browse to Rhythmyx over https I get the message "No available certificate or key corresponds to the SSL cipher suites which are enabled.”
I’m therefore not sure we have a key in the correct format or using an algorithm we have available in Rhythmyx. If I do a keytool -printcert I see the supplied certificate uses SHA1withRSA encryption algorithm - does this not work with Rhythmyx?[/QUOTE]
I’d recommend not using the keystore file if this is for serving the Content Editor. Front end it with something like IIS or Apache and connect it to the backend Tomcat server with ajp://
If this is for enabling Publishing via SSL from the webserver then be sure to use the JRE environment that comes with Rhythmyx otherwise the keytools probably won’t work, the symptom is the keystore it creates is unreadable or declared corrupt by the JRE used by Rhythmyx. (i.e. if you already have a JRE on a Windows box better to uninstall it and use the one that came with Rhythmyx from the command line than waste time trying to reset your classpath)
(Note: I found a much better demonstration in the Publishing [tab] Online Help document targeted specifically for windows, setting up SSL for Publishing between Server and Publisher. It continues to appear SSL support was specifically intended for Publishing not serving the Ephox Content Editor component.)
If you go this route and get a signed certificate using the keystore method it will be difficult to recover your private key for use with something like an Apache front-end server. (Not impossible, just difficult)
The Ephox EditLiveJava Applet has a bug that is fixed (after version 6.3.8.111) regarding the order in which the certs are stored in the keystore. I did not bother to figure out if or how to work around since we’re still at 6.5.2 and do not have access to the newer version that fixes the problem.
In any event, straight, plain Tomcat connectors seem to have an intermitent or race condition in that sometimes Ephox will be served licensed and sometimes it will be served unlicensed in Trail Mode with no custom menus when using native Tomcat connectors with SSL. I have not seen this problem since switching to using ajp:// with Apache.
We use RHEL5 as a server platform and there is a canned script called genkey which pretty much automates creating a private key and cert request.
Setting up SSL on Apache and connecting it to a backend consists of editing two files in the conf.d directory, ssl.conf and proxy_ajp.conf and restarting the httpd daemon.