Using the ephox editor over SSL

I’m in the process of upgrading a client’s development environment to 6.5.2 (previously 6.1). I’ve just performed the based upgrade and am testing at the moment.

The service works when using port 9991 (their default) and the ephox editor loads OK.

When using https and 9443 although the CX loads correctly, when loading any content editor that has an ephox control on the page the control doesn’t load correct and the error I get in the java console “Failed to load XML file.”

Now I know that it’s nothing to do with paths as the XML loads OK on the default port.

Is there anything else I need to do to get ephox working? The ephox version is 6.3.1.51.

The two files attached are the java console on HTTP and HTTPS when loading the a content editor.

Cheers
James

Hi

I’ve also applied the latest patch RX-13485 and get the same results.

Cheers
James

Same with me. The entire Ephox menu appears when I use port 9992 but when I use SSL port 9443, I get only the Ephox logo, menus for “div Paragraph content”, and the Design/Code tabs. See attached screenshot.

When I choose the Code view, I see:

<html>
<head>
<meta content="EditLive! 6.3.1.51" name="generator">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style type="text/css">
<!--
div.rx_ephox_inlinevariant {
  border: solid #c0c0c0 1px;
}
-->
</style>
</head>
<body onload="setCursor()">
<div class="rxbodyfield">

Hi

Ephox is now working after I recreated the key pairs and restarted the server.

For those interested here are the commands I used to recreate the keys, this is just for self certifiy keys:

Create the Key:

go to C:\Rhythmyx\JRE\bin

keytool -genkey -alias <YOUR_HOST_NAME> -keyalg RSA -dname "CN=<YOUR_HOST_NAME>,OU=<YOUR_OU>,O=<YOUR_O>,L=<YOUR_HOST_LOCATION>,S=<YOUR_STATE>,C=<YOUR_COUNTRY>" -keypass changeit -storepass changeit -keystore <YOUR_HOST_NAME>.keystore

Self certify the key:

keytool -selfcert -alias <YOUR_HOST_NAME> -keypass changeit -storepass changeit -keystore <YOUR_HOST_NAME>.keystore

Export the cert file:

keytool -export -alias <YOUR_HOST_NAME> -keypass changeit -storepass changeit -keystore <YOUR_HOST_NAME>.keystore -file <YOUR_HOST_NAME>.csr

Import the cert file:

keytool -import -noprompt -trustcacerts -alias <YOUR_HOST_NAME> -storepass changeit -file <YOUR_HOST_NAME>.csr -keystore c:\Rhythmyx\JRE\lib\security\cacerts

keytool -import -noprompt -trustcacerts -alias <YOUR_HOST_NAME> -storepass changeit -file <YOUR_HOST_NAME>.csr -keystore c:\Rhythmyx\AppServer\JRE\lib\security\cacerts

move the C:\Rhythmyx\JRE\bin\<YOUR_HOST_NAME>.keystore to the rhythmyx root
open the RhythmyxServerpropertiesEditor and enter in the SSL keystore filename and password

to delete the key (if applicable):

keytool -delete -alias <YOUR_HOST_NAME> -keystore c:\Rhythmyx\JRE\lib\security\cacerts -storepass changeit

keytool -delete -alias <YOUR_HOST_NAME> -keystore c:\Rhythmyx\AppServer\JRE\lib\security\cacerts -storepass changeit

I like it when commands are spelled out, but I’m not looking forward to running them all again! Especially since our cert is root-certified, not self-certified.

Unfortunately, even after I recreated the key pairs and restarted the server, I still have no Ephox menu over SSL (6.5.2, Patch RX-13277). I thought my custom Ephox configuration was causing the problem, but it happened even when I returned to the default configuration.

By the way, I like the way the custom configuration works. I’ve disabled font size, family and color, so that content contributions will fit into the site design more closely.

It’s finally working for me, and I can’t say I did anything that Jimbo didn’t. I’ve posted my quick SSL checklist on another thread. I’d be interested to know how most customers use SSL: using Rhythmyx ports natively or fronting with Apache. That discussion is also on another thread.

For 6.5.2 I don’t think there is an alternative.

The licensing scheme used by Ephox seems to only work (reliabily) with ajp but not with native Tomcat connectors. Though it did seem to work “occasionally” on native Tomcat connectors it was unreliable and often slipped into Trial mode.

I think the Tomcat connectors approach is only documented for using with the remote Filesystem publishing plugin. Since that only supports a simple list its much less complicated.