PHP + cURL + CA bundle + Plesk = SSL issue?

I corrected an issue with the above products on my friend’s server today. Supposedly, the payment processor changed the SSL certificate used by their payment server and broke cURL payment processing for clients. The server in question was running Plesk 8.1.1 and CentOS.

Since the fix isn’t published online, I’ll post my fix here.

I noticed quite a few posts mentioned the cURL ‘-k’ or ‘–insecure’ flag, which does not verify the SSL certificate (eg. if a self-signed certificate is being used). If you can’t verify a SSL certificate, then its authenticity is questionable. The ‘-k’ flag does NOT send communications in clear-text, as I previously noted (sorry!). That’s not something I approve of, nor something I would recommend to a friend or client.

So, what to do? First of all, I determined the path to the cURL CA bundle on the system.

grep -ir “curl” /etc

From the output above, we determine that Plesk is looking for the cURL CA bundle in /usr/share/curl/ and that the filename should be curl-ca-bundle.crt.

Next, we need to download cacert.pem from I recommend using wget to download it to your server directly. You will need to rename the file to curl-ca-bundle.crt once it’s downloaded.

Copy curl-ca-bundle.crt to /usr/share/curl. If you get an error stating the path doesn’t exist, then you will need to create it using mkdir -p /usr/share/curl. Once the path exists, copy the file to the new path: cp curl-ca-bundle.crt /usr/share/curl.

This is where it gets tricky. Open curl-ca-bundle.crt in vim or your favorite editor and search for “Equifax Secure Global eBusiness CA”. Copy everything in the block, including that text and including END CERTIFICATE. We need to copy that block to one more file (search for ca-bundle.crt on your system): /usr/share/ssl/certs/ca-bundle.crt. Append the block to the bottom of the file. Remember to press ENTER after the last line. Of course, remember to ask your payment processor who their SSL vendor is and use the correct block.

Next, simply restart the Apache process: service httpd restart

That’s it. You should now be able to process transactions using cURL and SSL.

Upgrading Red Hat 9 to CentOS 4.5

It’s been a few months since I last posted an entry to my blog. Life has been busy. This blog has been busy, in terms of web traffic to my Anonymous Letters and Starbucks posts below.

Time for a tech post. I had the privilege of upgrading an ancient Red Hat 9 Linux box to CentOS 4.5. Red Hat Linux has been EOL for a very long time, and was superceded by Fedora, which has had seven major releases. That’s the equivalent of running Windows 3.1 😉 Well, not quite :) Anyhow, the box at hand appeared to be a custom web server. I will outline the steps I used to successfully upgrade it to CentOS 4.5.

1. Download the CentOS 4.5 CD set or DVD image from
2. Put in CD 1 or the DVD image.
3. Reboot the old Red Hat 9 box and ensure that the BIOS allows booting from the CD/DVD drive.
4. Enter the following at the linux boot prompt and press Enter: linux upgradeany
5. The system will happily hum along while Red Hat 9 is upgraded to CentOS 4.5.
6. If ‘yum’ wasn’t installed, you will need to install it:
rpm -ivh
rpm -ivh
rpm -ivh
rpm -ivh
rpm -ivh

7. Now, run the following command and press Enter: yum update
8. Allow yum to run and update the required packages. Reboot if yum downloads and installs a new kernel.
9. Since the box in question had a custom Apache and PHP configuration, I reinstalled them manually:
yum install httpd
yum install php
yum install mysql
yum install mysql-server
yum install php-mysql

10. I had to update the MySQL configuration to point to the correct socket:
Update my.cnf:
instead of
and add the following to use your existing database passwords
11. Copy any required PHP extensions to new system path:
cp -R /usr/local/lib/php/extensions/* /usr/lib/php4
12. Edit /etc/php.ini:
error_reporting = E_ALL & ~E_NOTICE

13. Finally, set services to start up automatically:
chkconfig –level 345 httpd on
chkconfig –level 345 mysqld on
chkconfig –level 345 sendmail on

14. There you have it. The server should be happily running CentOS 4.5 now. Remember to keep it up-to-date by running yum update regularly.

Now Running Ubuntu Server 7.10

I got a little ahead of myself today and decided to upgrade to the latest release of Ubuntu. On the release date, no less.

I shelled into my server remotely and executed the required upgrade command (one-liner: sudo apt-get install update-manager-core && sudo do-release-upgrade). The new installer detects if you are running it via a SSH session and automatically spawns a “backup” SSH session on port 9004. The reason for this is if the main SSH connection disconnects, you can continue by using the backup session on port 9004. A very good move, in my opinion. Someone must have been reading my blog 😉

The download process took a little over 2.5 hours, at a pathetic 22 KB/s. An overloaded US Ubuntu server was to blame, but was expected. I normally receive updates from the Ubuntu server at over 600 KB/s. That tells you how overloaded their server was.

The installation itself went smoothly, but for some odd reason ntp was removed upon installation. A quick Google search proved that there were problems with the ntp daemon and client. Again, a recompile of eAccelerator was necessary due to the new PHP version included with Ubuntu 7.10: PHP 5.3.2.

I’ll update this blog post once the ntp issue has been resolved.


Running sudo apt-get install ntp installs the ntp daemon again.

Now Running Ubuntu Server 7.04

I finally decided to upgrade my Ubuntu Server 6.10 install to the latest version, 7.04 (Feisty Fawn). Out of habit, I now wait a few weeks before upgrading to the latest version of anything to ensure any last minute bugs get worked out.

Best of all, I upgraded the entire OS remotely using SSH. Upgrading your OS remotely is usually not a good idea, but if you know what you’re doing, go for it! Ensure you backup any custom/modified configuration files just in case you press a wrong key during the upgrade! :) The upgrade worked well, with the exception of recompiling eAccelerator (to work with PHP 5.2.2) and updating a line (see below) of code in WordPress to make everything work smoothly.

Immediately following the upgrade, I noticed that my WordPress blog was loading very slowly and I also noticed random strings of hexadecimal characters at the top of the main blog page.

If you upgrade your server to Ubuntu Server 7.04 and run WordPress 2.1.x, ensure that you change line 832 in wp-includes/functions.php to the following (all on one line):

@header($_SERVER[“SERVER_PROTOCOL”].” “.$header.” “.$text, true, $header);

Once you make the above change, your blog should load normally.

Update (5.15.2007):

With WordPress 2.2 (released today), the aforementioned WordPress fix is now irrelevant.

Configuring Ubuntu – Part 2

Opps. I just checked a few of my older blog posts and quickly realized I neglected to post part 2 of my ‘Configuring Ubuntu – Part 1’ guide.

Well, here it is!

By default, Ubuntu Server installs MySQL and PHP. However, it doesn’t tweak the system for performance. If you run a WordPress blog on your server, you may not realize that your blog could run more efficiently. WordPress relies on both PHP and MySQL. PHP scripts need to be read from a server’s hard drive, parsed by the web server software and then executed. Wouldn’t it be nice if the server could just skip the first two steps and just execute PHP scripts as quickly as plain HTML?

That’s where eAccelerator comes in. eAccelerator is a free, open-source PHP accelerator and cache. I’ve been using it for nearly seven years on personal and commercial servers. In other words, it’s very stable for a free product.

Let’s get started.
Continue reading “Configuring Ubuntu – Part 2”