The key and certificate files we've defined above don't exist yet. Ultimately we will want to use a private key with an officially signed certificate, so we can verify ourselves as being bona fide on the Internet, but for now we can create a temporary certificate and test that SSL works with it.
OpenSSL provides a utility called, simply enough, openssl. If OpenSSL was fully installed this will be located under whatever directory was given to the OpenSSL configuration script (/usr/local/ssl by default). Otherwise, it is still in the apps directory of the OpenSSL source code. In this case we can copy it to Apache's sbin directory. For our example server we'd use:
We can use this to create a des3-encrypted private key for Apache to use with either:
We can actually call this key file anything we like, but we choose the domain name of the server because we can then create other keys for different virtual hosts and give each a name that identifies the host it is for. The .key suffix is also not obligatory, but it is the usual one for key files. In the process of setting up SSL, we'll also create .csr and .crt files, so sticking to the common extensions makes life simpler. Executing the command will generate some diagnostic information about the key being generated and then ask for a pass phrase:
Since mod_ssl will ask us for this pass phrase every time we start up Apache, we can also create an unencrypted private key by leaving out the -des3 option:
Apache will accept this key quite happily, but we must make absolutely sure that the directory for keys and certificates - /usr/local/apache/conf/ssl in this example - and the files in it are all only readable by root:
If we fail to do this and a third-party gets hold of the private key, they could use it to impersonate the server, and security would be fundamentally broken.
Creating a Certificate Request and Temporary Certificate
To validate the private key we need a certificate. In order to get an officially signed certificate, we need to generate a certificate request file. To create our own temporary certificate we can simply sign our own request while we wait for an official one to be created for us. This certificate won't pass muster if a client checks it and finds it is not signed by a recognized certificate authority, but they may (depending on their configuration settings) choose to accept it anyway, either for just this session, or until it expires.
The openssl utility can both create and sign certificate requests. To create the request, or CSR, we use something like:
Note that for this, and some other variants of the openssl command, we need a configuration file located in the directory specified when OpenSSL was built. If OpenSSL was not fully installed install the configuration file by hand from apps/openssl.cnf.
The CSR generation process will ask us a whole bunch of questions about our identity, which will be built into the request and used by the signing authority as part of the certificate we are issued in return. This information is collectively known as a Distinguished Name or DN. Since we'll use this CSR for both testing and the official certificate it is important to get this information right:
Fill these in with the correct values for the server and server operator, leaving blank any fields that do not apply. The Common Name is the server's main domain name, www.alpha-complex.com in this case, regardless of the exhortation YOUR name. This is important, since browsers will generate a security warning if the certificate's CN (common name) does not match the URL that the client asked for.
The challenge password and optional company name are usually left blank; these are used with Certificate Revocation which is discussed later. For most applications no challenge password is required.
Once the CSR has been generated, we can sign it ourselves to create a temporary certificate for the private key we generated earlier:
Now we can install these two keys, if we didn't create them there, into the conf/ssl directory so Apache can see them. Now when we start Apache it should ask us for a pass phrase (if we encrypted the private key file), and start up with SSL. We can check the configuration by using mod_info's information page and test that SSL works by asking for the URL https://www.alpha-complex.com/.
In fact the server will respond to a secure http connection on either port 80 or 443, however clients default to port 443.
Note that we cannot use telnet to test an SSL connection, since telnet has no idea about public key cryptography, and quite rightly too. We can use another variant of the openssl utility to test the connection instead:
This will produce a longish printout of negotiations between openssl and Apache, which can be used for analyzing problems or debugging. For really extended output add the -debug option as well. Assuming the connection is established, we can get a page from the server with something like:
Followed by two linefeeds. This should have the expected results, with a few additional SSL related message tagged on to the end.
Getting a Signed Certificate
Chances are, if we use a modern web browser to test the above URL, we'll get a warning message about the site using a certificate that hasn't been signed by a recognized authority and asking us if we want to accept it. That's fine for testing but a little unfriendly for visitors. To make this message go away we have to spend some money and get the CSR signed by a recognized certificate authority.
The two largest certificate authorities are Verisign and Thawte. Verisign certificates can applied for online at http://www.verisign.com/server/. Information and forms for requesting a certificate from Thawte can be found at the URL http://www.thawte.com/certs/server/. Thawte also have help pages for setting up SSL keys and certificates, including Apache-SSL and Apache+mod_ssl, at: http://www.thawte.com/certs/server/keygen/.
Of the two, Thawte is significantly cheaper and recently gained the right to issue strong encryption certificates which previously had been a right exclusive to Verisign. Thawte also get brownie points for supporting Apache early on (at one point they were the only source of certificates, since at that time Verisign was refusing to grant certificates for Apache servers) as well as having support pages dedicated to it.
The key part of the online application process is sending the CSR to the authority; in this case www.alpha-complex.com.csr. It is important to send the right file - do not send the temporary certificate (extension .crt) and especially not the private key file. In general, the CSR is pasted into an HTML form as a complete file. Note that all parts of the file are required and it must be sent as-is with no additions or missing characters.
With either service, or indeed any other, the following are usually required:
For more information about the use of SSL and Apache, see Professional Apache by Peter Wainwright
Using Apache’s suEXEC Mechanism
Normally CGI and PHP scripts run under the same user as the web server (usually www or nobody). One of the consequences of this is that a user can read and modify files (such as scripts or password files) created by the CGI programs or PHP scripts of another user. It may also allow users to connect to the database of another user, but that depends on the configuration of the database server. For instance, the default MySQL will allow this. This can be fixed by forcing the database to do password verification. The documentation for the particular database you use should have more information.
While PHP’s safe_mode alleviates some of these problems, all scripts still run under the same user id.
Fortunately, Apache gives us the software to solve this problem. suEXEC (Switch User before Executing) is a small utility that makes it possible to run CGI programs (and therefor PHP scripts) under any user id we want (with exception of the root user) and it works with both the UserDir and VirtualHost directives.
suEXEC is a so called CGI wrapper. This means that before a script is executed it has to pass a series of carefully constructed security checks. The version of suEXEC that comes with Apache version 1.3.9 has 21 of these checkpoints. Below is a list of some of the things suEXEC checks before executing a script.
suEXEC solves several security problems and makes allowing users to develop and run their own scripts much safer. It does come at a cost though. suEXEC can slow things down considerably, since suEXEC only works with the CGI version of the PHP parser, which is considerably slower than using the module version. Another problem with suEXEC is the complexity it that adds to developing and using PHP scripts. You have to make sure that your script doesn’t fail even one of suEXEC’s tests. If it does, your script will not be executed. I recommend you only use suEXEC if you really have to.
©1998 Wrox Press Limited, US and UK.
blog comments powered by Disqus