Now that I’ve run two successful crowdfunding campaigns through Pozible, I’m starting to set up systems to accept direct payments for my various projects. The first, a page to accept one-off donations was mostly straightforward.
While Stripe is still in beta in Australia, Pozible already uses it to handle recurring subscription payments, and I’d already received an invitation into the beta program. I figured it made sense to keep all my payments in one place.
Plus I’ll eventually be using Memberful to process subscriptions, and that also uses Stripe.
To integrate Stripe into this WordPress site, I used the free plugin WP Stripe from Human Made Limited. This provided me with one payment form per website, which is all I needed for this task. I also installed the WP Stripe Email Receipts plugin by Philip Newcomer.
All that went smoothly. I installed the plugins, activated them, entered my Stripe account keys and a template for the email receipts — and they just worked.
The only difficulties came with configuring Secure Sockets Layer (SSL) on the web server, and that was down to a bug I encountered in the WHM/cPanel hosting management software while I was installing the SSL certificate. That’s nothing to do with Stripe or WordPress or the plugins, of course, just my dodgy web server.
I’ll document that bug over the fold. Meanwhile, why not try out the system and give me a tip? Was that too blatant?
I used the master WHM interface rather than the site’s individual cPanel account for this, version 11.41.1.
Under “SSL/TLS” I used “Generate an SSL Certificate and Signing Request” to do just that, and obtained a Comodo Free SSL certificate.
That’s hardly the best SSL protection in the world, I know, but my main aim here is to make the SSL warnings go away. After all, SSL is unlikely to be the weakest link. One step at a time.
I then used WHM’s “Install an SSL Certificate on a Domain” function to install the certificate, along with the certificate bundle sent by Comodo. That all appeared to work, but…
WordPress’ JetPack plugin now refused to connect back into the site, complaining about an SSL certificate error. Analysis by Qualys SSL Labs’ extremely handy SSL Server Test told me that the intermediate certificates were missing — and indeed, when I checked the Apache web server configuration manually, it turns out that the certificate bundle hadn’t been installed.
To fix that, I needed to put the certificate bundle somewhere, and tell the Apache web server where to find it. It didn’t take long to find the correct locations for all this under CentOS, and I did the following:
- Copied the certificate bundle
/usr/local/apache/conf/userdata/ssl/2_2/accountname/example.com, which is where all the other certificates could be found.
- Created the file
/usr/local/apache/conf/userdata/ssl/2_2/accountname/example.com/example.com-ssl.conf, containing the single line
/etc/httpd/conf/httpd.confto uncomment the line
Include "/usr/local/apache/conf/userdata/ssl/2_2/accountname/example.com/*.conf". This should be the last line within the relevant
- Remember that I was doing it like this so that my extra line of configuration wasn’t lost when
httpd.confwas auto-regenerated by some other process.
- Ran the comment
httpd configtestto confirm that there were no syntax-breaking mistakes in any of that.
- Restarted the web server.
And that made the SSL errors go away. Victory is mine!
The Comodo Free SSL certificate doesn’t include a public audit record, however, so some web browsers will indicate that while there’s a valid SSL connection, they won’t give it the full “green bar” treatment showing that you’re definitely connected to the right site. Given what Edward Snowden’s document trove has revealed, however, we can never really be sure of that anyway.
Now you can give me a tip, right?