How to disable TLSv1.0 for PCI Compliance in Apache 2.2

Just recently our PCI compliance scanner started complaining about TLSv1.0 being enabled on our web server, so I had to go figure out how to disable it. The following is what I ended up with in our VirtualHost config which did what I wanted it to:
<VirtualHost xx.xx.xx.xx:443>
        SSLEngine on
        SSLProtocol +TLSv1.1 +TLSv1.2
        SSLCompression off
        SSLHonorCipherOrder On
        Header always append X-Frame-Options SAMEORIGIN

PCI Compliance TLSv1.0I simply removed the "all" option I had there previously and just manually enabled the TLSv1.1 and TLSv1.2. I also added the "Header" bit so that common browsers wouln't put our site in frames.

Now, checking our SSL certificate using the SSL Server Test we get an A rating. The downgrade from A+ being due to an upstream older SHA1 hash that we have no way to change and doesn't directly effect the security of our site, so as far as I'm concerned we look good.

The draw back is that older machines, such as those running Windows XP and versions of Android older than 4.2.2 will no longer be able to connect to us. Sorry about that. Since this is required for PCI compliance, there's not much we can do.

No webcam Image on USB webcam for Ubuntu 14.04

I have been doing google hangouts more for work, and most folks who use Google hangouts also have a webcam setup so you can see the person you're speaking with. This is useful because as most communicators know, so much communication is non-verbal. It's helpful to have an image of the person you're talking to.

webcamI have just recently changed out my PC case and motherboard for an older server board. The server board, while being slower on the MGhz and RAM speeds, had a lot more CPU cores and RAM amount. On my previous PC, running an older version of Ubuntu (13.04), my USB webcam worked flawlessly. However, on this "newer" PC, my webcam no longer works. First my USB camera didn't even register. I had to unplug it and replug it in for it to register at all. IE: nothing was showing up when I entered the following:

ls /dev/video*

As soon as I unplugged and replugged in the USB video camera, I would get a device here, but when I started up "cheese" (a cam viewer for Linux), I got nothing but a black screen. What was going on?

Looking up some articles on debugging Ubuntu camera issues, I happened on an article that mentioned I try a camera app called "guvcview". I did, and when I ran it, I got the following error message over and over:

Could not grab image (select timeout): Resource temporarily unavailable

Mkay... why can't you grab an image if you see that I have a camera now?

Turns out, the bottom of the article that I found earlier had the answer:

"Some newer webcams produce high resolution images at 30fps. This is a lot of data. If your USB cable path is too long or convoluted, frames can drop causing flicker or no picture. If you find MJPG format mode produces less flicker than YUYV format mode, then this could be the case. Try plugging the webcam directly into the computer. Then try progressively reconnecting your extension cables or hubs to see how the picture changes. Check you don't have a low speed hub.

You may also see:

Could not grab image (select timeout): Resource temporarily unavailable

This could indicate the frame data not arriving down the long cable fast enough. Check also for cable kinks and tight loops, which like ethernet, cause delayed packets."

BINGO! Apparently my older server board only had the earliest USB ports, which means they are really, really slow. I tweaked with the settings on the "Video" tab in guvcview and was able to get a picture of some kind by dramatically lowering the resolution and camera output type. Unfortunately the camera is still barely usable. Couple that with the relatively low Ghz value of the CPU and slow RAM, I'm not so sure this old server board is worth being a desktop.

Methods to address a slow Tomcat/Railo startup

Recently my technicians and I encountered an issue with a hosting customer who had an interesting situation between two VPS Accounts that he owns. The first VPS had a relatively quick startup time (under a minute), and the second VPS had an extremely slow startup time (above 5 minutes). Both VM's were relatively similar, and both served a great number of sites. The following are the two options that corrected the issue:

Slow Railo/Tomcat Server

Option 1

Set property in TOMCAT_HOME/conf/


This will turn off jar scanning during the Tomcat startup.

Option 2

Configure the number of concurrent threads for Tomcat to use to create new contexts by adding the "startStopThreads" attribute to the <engine> tag in the Tomcat server.xml file. The number of threads should not be higher the number of CPU cores available to your server or the threads might overlap and you probably won't get the speed boost you were hoping for.


Once these options were implemented, both servers started up in just a few seconds.

Fixing "JRun too busy or out of memory" for PCI compliance

One of our servers here at Vivio is routinely scanned for PCI compliance purposes. Until just recently, we've been using FuseGuard (A Web Application Firewal, or "WAF"), to block intrusion attempts to our web application. With new PCI standards that force us to allow PCI scans through our WAF (or IDS or whatever), we had to allow these requests through, but that brought to light another, different, problem.

During the PCI scan, our Apache logs would get a lot of the following error messages:

[notice] jrApache[13857: 62679]  returning error page for JRun too busy or out of memory

Initially we thought that since the message was coming from the JRun connector, that the issue had something to do with the connector. However, after quite a bit more research, we found it had to do with JRun itself, and the specific number of post parameters it's configured to accept. Any more then the default "100" post parameters, and you'll get the error you see above.

To change the number of post parameters, you will need to update your neo-runtime.xml file. For our case, ours was found here:

NEO XML Example

IMPORTANT: Editing this file isn't particularly easy. Opening it in VIM gives you a big wall of text.

By increasing the following parameter from 100 to 300, we were able to succesfully complete our PCI scan:

<var name='postParametersLimit'><number>300.0</number></var>

Hopefully this helps anyone else having this issue.

Railo CGI remote_addr/remote_host says

When installed on to a Linux/Apache machine, the Railo installers will install mod_proxy_http as the default connector for Apache to Tomcat/Railo. The result is the same as you'd get with any other proxy, where the remote host is replaced with the address of the proxy (in this case and the original requester's IP address is placed in the "X-Forward-For" header.

simplicityIf you need to find the original requestors IP address you can accomplish this in one of two easy ways.

Pull the IP from the X-Forward-For Header
This can be done easily using the following single line of code:


Use the Tomcat Remote IP Valve
This can be done simply by opening up your Tomcat server.xml file and adding a single line of code right under your "<Engine>" tag:

Change this:

<Engine name="Catalina" defaultHost="">

To this:

<Engine name="Catalina" defaultHost="">
<Valve className="org.apache.catalina.valves.RemoteIpValve" />

Restart Tomcat and you'll now see the IP address of the original requesting client populate your CGI scopes.