Forcing https instead of http

I succeeded in forcing a redirect for the Content Explorer from http to https, but it had some unintended consequences…

I added the following security constraint code to /Rhythmyx/AppServer/server/rx/deploy/jbossweb-tomcat55.sar/conf/web.xml:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Tomcat</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

This config file affects all the Tomcat applications on the installation, which may be part of my problem.

Then I changed the redirect in the Connector from the Tomcat default port of 8443 to the Rhythymx SSL default port of 9443 in /Rhythmyx/AppServer/server/rx/deploy/jbossweb-tomcat55.sar/server.xml. This is what the beginning of that file looks like for me (and that also might be part of my problem):

<?xml version="1.0" encoding="utf-8"?>
<Server>
   <Service className="org.jboss.web.tomcat.tc5.StandardService" name="jboss.web">
      <Connector URIEncoding="UTF-8" acceptCount="100" address="${jboss.bind.address}" connectionTimeout="20000" disableUploadTimeout="true" emptySessionPath="true" enableLookups="false" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="250" minSpareThreads="25" port="9992" redirectPort="9443" scheme="http" strategy="ms"/>
      <Connector URIEncoding="UTF-8" acceptCount="100" address="${jboss.bind.address}" clientAuth="false" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" keystoreFile="/Rhythmyx/AppServer/server/rx/conf/my-server.keystore" keystorePass="mypass" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="9443" scheme="https" secure="true" sslProtocol="TLS"/>
      <Connector address="${jboss.bind.address}" emptySessionPath="true" enableLookups="false" port="10010" protocol="AJP/1.3" redirectPort="9443"/>
      <Engine defaultHost="localhost" name="jboss.web">

etc.

I got wonderful fast redirects to https in the Content Explorer, but I lost my Publishing and Workflow tabs, as well as the User, Roles, and Community, and Logout options in the upper right corner of the browser. I decided that was too much to give up.

Is there a better way to do this?

Another possibility is to front Tomcat with Apache, which could send http:cms.univ.edu/ to https:cms.univ.edu:9443. Has anyone tried either approach? This would prevent user names and passwords from being sent insecurely.

Actually, the last line of my current config is port 8443 not 9443:

<Connector address="${jboss.bind.address}" emptySessionPath="true" enableLookups="false" port="10010" protocol="AJP/1.3" redirectPort="8443"/>

I’m getting

14:25:43,095 FATAL [PSTransformErrorListener] javax.xml.transform.TransformerException: Error reported by XML parser
14:25:43,095 WARN  [PSTransformErrorListener] javax.xml.transform.TransformerException: org.xml.sax.SAXParseException: Premature end of file.

When I try to view the banner frame only, I get

 	An error occurred generating HTML from XML using the "" style sheet for the request submitted by session id 85d9ba83a9339acdcf2d00313c1057071d170547.
1 	An exception occurred while processing the bannerpage XML document through the file:sys_cx/bannerpage.xsl style sheet: com.percussion.data.PSConversionException: An exception occurred while processing the bannerpage XML document through the file:sys_cx/bannerpage.xsl style sheet: Error transforming the xml document with stylesheet Error reported by XML parser; Line#: -1; Column#: -1 Error reported by XML parser; Line#: -1; Column#: -1 

Try adding proxyName and proxyPort attributes.

Here’s one that worked for another customer:

<Connector URIEncoding="UTF-8" acceptCount="100" address="${jboss.bind.address}" 
connectionTimeout="20000" disableUploadTimeout="true" emptySessionPath="true" 
enableLookups="false" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="250" 
minSpareThreads="25" port="9992" redirectPort="8443" scheme="https" strategy="ms" 
proxyName="testcms.local" proxyPort="443" secure="true"/>

I don’t think you need to modify the <security-constraint> tag.

If your only concern is to force users to login over https to avoid clear text uid/pwd transmission, but are not concerned about encrypting the rest of the communications, the product has built in support for this.

Edit the user-security-conf.xml file found in the rxapp.war\WEB-INF\config\user\security directory. Set forceSecureLogin=“yes” on the root securityConfiguration element. This will automatically redirect any http requests to the login form over https, and then after that form is posted, the user is redirected to the originally requested url (usually just the Content Explorer) over the originally requested protocol.

So if a user requests http://myserver:9992/Rhythmyx, they will be reditected to the login form over https, and then back to the http://myserver:9992/Rhythmyx after authentication so that the login credentials are exchanged encrytped.

Hope this helps,
Jay

Jay, that’s great. I do get the redirect now that I’ve made your change, but after logging in at https://myschool.edu:9443/Rhythmyx/, it returns me to the login page as if I hgadn’t entered my uid/pwd. Yet I am logged in after that - I can reach Content Explorer if I refuse to login again and simply enter the appropriate URL.

I’ve done some testing and I can only reproduce your problem if I login to Rhythymx, logout, and then try to log back in using the same browser. Have you completely removed the previous configurations you attempted (as described in this thread)?

However, this feature does not seem to be working correctly in another way - if I test this with a new browser instance, I get redirected to https for the login form, then I get redirected back to http for the community login page which in my case automatically redirects to the applet, and at that point the Content Explorer applet page is loaded over https again, not http as it should.

If you start from a fresh browser instance, do you see the same behavior?

Yes, I see the same behavior. I removed the security-constraint from /Rhythmyx/AppServer/server/rx/deploy/jbossweb-tomcat55.sar/conf/web.xml and I changed all references from 8443 to 9443 in /Rhythmyx/AppServer/server/rx/deploy/jbossweb-tomcat55.sar/server.xml. I hope that was correct. I didn’t yet add proxyName and proxyPort to the config.

I’ve logged a bug for these issues, the bug ID is RX-13693.

Hi,

We raised the same issue with technical support in the UK a couple of weeks ago.

Also, has anyone else noticed that IE6 and IE7 complain about there being a mixture of secure and non-secure elements in the 6.5.2 Content Explorer?

Andrew.

Ah yes… if it’s possible to configure IE not to display those warnings, that would be nice. I tried telling it not to “display the nonsecure items” and I couldn’t tell any difference, so I don’t know what they are. All the image URLs on the page begin with https except for a javascript(void).

We have used apache to front end the cms with https.

Here are some pointers that might help:
http://rimuhosting.com/mod_jk2_and_mod_proxy_ajp.jsp
http://wheelersoftware.com/articles/apache-tomcat-integration.html
http://www.yolinux.com/TUTORIALS/LinuxTutorialTomcat.html
http://wiki.jboss.org/wiki/UsingMod_jk1.2WithJBoss

compiling apache with ssl:
http://www.securityfocus.com/infocus/1818

Ultimately we did not use apache with the ssl module, instead we have an ssl accelerator that serves as proxy going from https to http.

So our configuration is something like this:
Https(443) -> SSL proxy accelerator -> http(80) -> apache with mod_jk -> tomcat @9992

[QUOTE=barre57e;3364]We have used apache to front end the cms with https.
[/QUOTE]

Is that what most customers do? Would IE complain if I did it that way? Or is using these ports natively the standard solution?

I’ve gotten both Jay’s and Dave’s suggestion to work together now. For some reason, Dave’s suggestion didn’t redirect for me by itself. I removed proxyName, which might have done something, and changed proxyPort=“9443”.

Also, we’d recently changed our development server name, and Jay’s suggestion is currently redirecting me to the old server name from the new server, even when I’m already using an SSL port in the URL. The production server worked fine without Dave’s additional configuration. Otherwise, things are working much better now.

I get the same complaint in IE 8 beta. Some of my recent cross-browser testing makes me think the problem is related to Java, but it might be caused by source code like this (from the Workflow tab), in which the “http:” is hard-coded:

<table border="0" cellpadding="0" cellspacing="0" class="outerboxcell" width="100%" id="http://127.0.0.1:9992/Rhythmyx/ui/userstatus.jsp?http://127.0.0.1:9992/Rhythmyx/sys_ComponentSupport/componentcontext.xml?componentid=http://127.0.0.1:9992/Rhythmyx/sys_ComponentSupport/componentsupport.xml?sys_componentname=wf_nav&sys_pagename=wf_allhttps://cms-test.tamu.edu:9443/Rhythmyx/sys_wfPreviewWorkflow/previewworkflow.htm?sys_componentname=wf_all&workflowid=">

IE users can disable that message by changing their settings in Tools > Internet Options > Security > Custom Level > Miscellaneous > Display mixed content. By default, it’s set to Prompt, so reset it to Enable. Disable would probably work for Rhythmyx, though - I don’t see any loss in functionality. But expecting users to reconfigure their browsers is probably not a long term solution.

In doing further testing…this configuration does not work for us ( It has about 98% functionality).

We have found with this configuration some of the menu options do not work.This is what we have identified so far:
-Admins can’t purge publication logs under the publishing tab.
-End users can’t workflow items

I believe our next step is to try Client HTTPS(443) -> VIP -> server HTTP(9992) as recommended:
( http://forum.percussion.com/showthread.php?t=989 )

However, if you’re trying to use SSL that terminates at a load balancer (such as BigIP), this is not the solution to your problem.

What you have to do is modify the server.xml file for the internal Tomcat instance. This file is located at:

/Rhythmyx/AppServer/server/rx/deploy/jbossweb-tomcat55.sar/server.xml

The connector node will look like this:
Connector URIEncoding=“UTF-8” acceptCount=“100” address="${jboss.bind.address}" connectionTimeout=“20000” disableUploadTimeout=“true” emptySessionPath=“true” enableLookups=“false” maxHttpHeaderSize=“8192” maxSpareThreads=“75” maxThreads=“250” minSpareThreads=“25” port=“9992” redirectPort=“8443” scheme=“https” strategy=“ms” proxyName=“BigIP.somedomain” proxyPort=“443” secure=“true”

You’ll need to set the proxyName to match the actual server address of your BigIP device, and restart Rhythmyx.

Once you’ve changed this, you will only be able to access Rhythmyx via the BigIP device, you cannot access it directly.

[QUOTE=barre57e;3364]We have used apache to front end the cms with https.

Here are some pointers that might help:
http://rimuhosting.com/mod_jk2_and_mod_proxy_ajp.jsp
http://wheelersoftware.com/articles/apache-tomcat-integration.html
http://www.yolinux.com/TUTORIALS/LinuxTutorialTomcat.html
http://wiki.jboss.org/wiki/UsingMod_jk1.2WithJBoss

compiling apache with ssl:
http://www.securityfocus.com/infocus/1818

Ultimately we did not use apache with the ssl module, instead we have an ssl accelerator that serves as proxy going from https to http.

So our configuration is something like this:
Https(443) -> SSL proxy accelerator -> http(80) -> apache with mod_jk -> tomcat @9992[/QUOTE]

After looking at the code in the rxlogin.jsp I was able to add some custom processing so we can single-sign-on end users into the CMS directly from our schools portal.

This means we will no longer go the ssl route.

[QUOTE=barre57e;3973]In doing further testing…this configuration does not work for us ( It has about 98% functionality).

We have found with this configuration some of the menu options do not work.This is what we have identified so far:
-Admins can’t purge publication logs under the publishing tab.
-End users can’t workflow items

I believe our next step is to try Client HTTPS(443) -> VIP -> server HTTP(9992) as recommended:
( http://forum.percussion.com/showthread.php?t=989 )

However, if you’re trying to use SSL that terminates at a load balancer (such as BigIP), this is not the solution to your problem.

What you have to do is modify the server.xml file for the internal Tomcat instance. This file is located at:

/Rhythmyx/AppServer/server/rx/deploy/jbossweb-tomcat55.sar/server.xml

The connector node will look like this:
Connector URIEncoding=“UTF-8” acceptCount=“100” address="${jboss.bind.address}" connectionTimeout=“20000” disableUploadTimeout=“true” emptySessionPath=“true” enableLookups=“false” maxHttpHeaderSize=“8192” maxSpareThreads=“75” maxThreads=“250” minSpareThreads=“25” port=“9992” redirectPort=“8443” scheme=“https” strategy=“ms” proxyName=“BigIP.somedomain” proxyPort=“443” secure=“true”

You’ll need to set the proxyName to match the actual server address of your BigIP device, and restart Rhythmyx.

Once you’ve changed this, you will only be able to access Rhythmyx via the BigIP device, you cannot access it directly.[/QUOTE]

[QUOTE=Andrew Morrison;3356]Hi,

We raised the same issue with technical support in the UK a couple of weeks ago.

Also, has anyone else noticed that IE6 and IE7 complain about there being a mixture of secure and non-secure elements in the 6.5.2 Content Explorer?

Andrew.[/QUOTE]

The problem is in …/sys_cx/cxpage.html a reference to the JRE to download if you don’t have one.

It’s set here: RhythmyxRoot/rxconfig/Server/config.xml

Change the http://sun.microsystems… to https://sun.microsystems… the file is served from sun on either protocol.

It shows up in a frameset which IE won’t ignore checking, Firefox doesn’t bother.

[QUOTE=jwillis;10532]The problem is in …/sys_cx/cxpage.html a reference to the JRE to download if you don’t have one.

It’s set here: RhythmyxRoot/rxconfig/Server/config.xml

Change the http://sun.microsystems… to https://sun.microsystems… the file is served from sun on either protocol.

It shows up in a frameset which IE won’t ignore checking, Firefox doesn’t bother.[/QUOTE]

I noticed that the Rhythmyx Server Administrator provides access to this variable; start->programs->percussion rhythmyx->Rhythmyx Server Administrator

Then Content Explorer tab -> Plug-in Location

double click on the field and add a single letter “s” after http and [Apply]

Good tip, thanks. We’ve since moved on to just the log in being done via HTTPS, so this isn’t a problem anymore, but good to know it wasn’t just a random error.

Something I’ve never come across in 15 years of HTML, is that apparently you can use something like…

src="//hostname/mypage.html"

…and it will use http if the page it is on has been served over http, https if the page has been served over https, and possibly ftp if the page has been served over ftp.

I don’t know what this technique is called to be able to search for it in, I guess, the IETF RFCs. I’m not sure if it would work in this context, but might be worth a try if you say want the entire session to be done of HTTPS, but also allow people to log in without encryption.