From PHP, you can access the useful cURL Library (libcurl) to make requests to URLs using a variety of protocols such as HTTP, FTP, LDAP and even Gopher. (If you’ve spent time on the *nix command line, most environments also have the curl command available that uses the libcurl library)

In practice, however, the most commonly-used protocol tends to be HTTP, especially when using PHP for server-to-server communication. Typically this involves accessing another web server as part of a web service call, using some method such as XML-RPC or REST to query a resource. For example, Delicious offers a HTTP-based API to manipulate and read a user’s posts. However, when trying to access a HTTPS resource (such as the delicious API), there’s a little more configuration you have to do before you can get cURL working right in PHP.

The problem

If you simply try to access a HTTPS (SSL or TLS-protected resource) in PHP using cURL, you’re likely to run into some difficulty. Say you have the following code: (Error handling omitted for brevity)

// Initialize session and set URL.
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);

// Set so curl_exec returns the result instead of outputting it.
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

// Get the response and close the channel.
$response = curl_exec($ch);
curl_close($ch);

If $url points toward an HTTPS resource, you’re likely to encounter an error like the one below:

Failed: Error Number: 60. Reason: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The problem is that cURL has not been configured to trust the server’s HTTPS certificate. The concepts of certificates and PKI revolves around the trust of Certificate Authorities (CAs), and by default, cURL is setup to not trust any CAs, thus it won’t trust any web server’s certificate. So why don’t you have problems visiting HTTPs sites through your web browser? As it happens, the browser developers were nice enough to include a list of default CAs to trust, covering most situations, so as long as the website operator purchased a certificate from one of these CAs.

The quick fix

There are two ways to solve this problem. Firstly, we can simply configure cURL to accept any server(peer) certificate. This isn’t optimal from a security point of view, but if you’re not passing sensitive information back and forth, this is probably alright. Simply add the following line before calling curl_exec():

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

This basically causes cURL to blindly accept any server certificate, without doing any verification as to which CA signed it, and whether or not that CA is trusted. If you’re at all concerned about the data you’re passing to or receiving from the server, you’ll want to enable this peer verification properly. Doing so is a bit more complicated.

The proper fix

The proper fix involves setting the CURLOPT_CAINFO parameter. This is used to point towards a CA certificate that cURL should trust. Thus, any server/peer certificates issued by this CA will also be trusted. In order to do this, we first need to get the CA certificate. In this example, I’ll be using the https://api.del.icio.us/ server as a reference.

First, you’ll need to visit the URL with your web browser in order to grab the CA certificate. Then, (in Firefox) open up the security details for the site by double-clicking on the padlock icon in the lower right corner:

Then click on “View Certificate”:

Bring up the “Details” tab of the cerficates page, and select the certificate at the top of the hierarchy. This is the CA certificate.

Then click “Export”, and save the CA certificate to your selected location, making sure to select the X.509 Certificate (PEM) as the save type/format.

Now we need to modify the cURL setup to use this CA certificate, with CURLOPT_CAINFO set to point to where we saved the CA certificate file to.

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_CAINFO, getcwd() . "/CAcerts/BuiltinObjectToken-EquifaxSecureCA.crt");

The other option I’ve included, CURLOPT_SSL_VERIFYHOST can be set to the following integer values:

• 0: Don’t check the common name (CN) attribute
• 1: Check that the common name attribute at least exists
• 2: Check that the common name exists and that it matches the host name of the server

If you have CURLOPT_SSL_VERIFYPEER set to false, then from a security perspective, it doesn’t really matter what you’ve set CURLOPT_SSL_VERIFYHOST to, since without peer certificate verification, the server could use any certificate, including a self-signed one that was guaranteed to have a CN that matched the server’s host name. So this setting is really only relevant if you’ve enabled certificate verification.

This ensures that not just any server certificate will be trusted by your cURL session. For example, if an attacker were to somehow redirect traffic from api.delicious.com to their own server, the cURL session here would not properly initialize, since the attacker would not have access to a server certificate (i.e. would not have the private key) trusted by the CA we added. These steps effectively export the trusted CA from the web browser to the cURL configuration.

More information

If you have the CA certificate, but it is not in the PEM format (i.e. it is in a binary or DER format that isn’t Base64-encoded), you’ll need to use something like OpenSSL to convert it to the PEM format. The exact command differs depending on whether you’re converting from PKCS12 or DER format.

There is a CURLOPT_CAPATH option that allows you to specify a directory that holds multiple CA certificates to trust. But it’s not as simple as dumping every single CA certificate in this directory. Instead, they CA certificates must be named properly, and the OpenSSL c_rehash utility can be used to properly setup this directory for use by cURL.

Since the major use of Internet is for accessing websites, the “www” prefix shouldn’t be needed anymore. It is an archaic holdover from a previous era, one where browser wars meant IE vs. Netscape and where Geocities was the place to be. Thankfully, the folks over at no-www have been aiming to improve this for some time.

So what’s the big deal?

Well, it’s not such a big deal, more just a pet peeve of mine. Most sites out there are thankfully configured well enough so that navigating to “domain.com” just redirects you to “www.domain.com” with no damage done. However, some servers are setup so that navigating to “domain.com” doesn’t work, and this forces you to type in the “www” subdomain before. This really doesn’t make sense in today’s world.

In my opinion, all websites should be set up with the no-www version as the default. Using the “www” subdomain should redirect you to the no-www version, with no harm done. This is known as Class-B compliance, according to the no-www folks, and it’s probably going to be the best way to go for some time, since many people still use the “www”, after having the phrase drilled into their heads during the late 90′s.

So, how to fix it?

If you’ve signed up for hosting from a provider, chances are they’ve already implemented some sort of compliance, but not the optimal type. For example, most hosting providers will automatically redirect the no-www request to the www one. So, under this configuration, someone entering “domain.com” would be redirected to “www.domain.com”. No big deal, but things could be better. After all, the no-www version is shorter and thus requires less typing and less space. Good if you want to save a few cents on your business cards.

Fixing it is a simple effort that takes a minute or so. All you have to do is edit the .htaccess file in the root of your website, if you’re using Apache. Here’s the following directive I’m using.

# BEGIN no-www
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.unitstep\.net$ [NC]
RewriteRule ^(.*)$ http://unitstep.net/$1 [R=301,L]
</IfModule>
# END no-www

The RewriteRule uses a 301 – this is a special HTTP code used to tell of a permanent redirection. Browsers and search engines crawling your site will interpret this as an instruction that your website has permanently moved to the non-www address. This is most important for search engines, so that they know that the no-www version is not just a duplicate or different website than the previous www version. The 301 instruction tells them that the old www version doesn’t exist anymore, and it has been moved to the no-www address.

Taking it a step further, you could also redirect any subdomain to just the root. For example, I also own the domain “peterchng.com”, and wanted to redirect any request to that address, subdomains included, to my main site. Here’s the directives I used.

# BEGIN peterchng.com FORWARD
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(([a-zA-Z0-9]+)\.)*peterchng\.com$ [NC]
RewriteRule ^(.*)$ http://unitstep.net/$1 [R=301,L]
</IfModule>
# END peterchng.com FORWARD

Go ahead, try typing in “who.the.heck.is.peterchng.com” into your browser, and you’ll see it redirects right back to this site.

You’ll want to be careful when using these directives – if you actually do have separate websites on different subdomains, they’ll be inaccessible if you do this! I’ve been using it until I find a use for peterchng.com – or a different use for unitstep.net.

Why all the trouble then?

With all the trouble of going of removing the “www” you may wonder why it was ever used in the first place. Well, IIRC, in the early years of the Internet, websites or HTTP wasn’t the main use. Other services/protocols such as gopher, FTP and telnet were probably a lot more dominant. So, it made sense to set up a separate subdomain that would be used to accept HTTP connections. This would make it easier for users to distinguish between the services offered from a particular domain. However, since HTTP has grown to eclipse those traditional services, the use of www is almost superfluous nowadays.