Self-certify Apache
From Software By Jeff
Here’s how to create the files and update the configuration to create a self-certified Apache SSL/HTTPS server.
A major assumption is the availability of the OpenSSL tools. As such, this is easier to do on a Linux distro and then copy the resulting files over. This shows and assumes such. Also, the steps are being performed as if root. Security and file access is out of the scope of this document.
Important bits, either user input or parts to remember for later use, are highlighted. Of course, use common sense when the example doesn't match your configuration, adjusting appropriately for your intent and environment.
| Table of contents |
Certificate Authority
This only needs to be done once, and you can either create more keys on the same server (mind the file names or paths), or copy the CA key and cert files around for use on other servers.
The following will create a 4096-bit strength DES3 encrypted key and put it in the file ca.key. The name is unimportant, but must be remembered as it’s used later. The key strength is also up to you; 4096 is plenty strong; I'm not sure if it can make a stronger key, in fact. Running this command will prompt you for a password and confirmation; they can’t be blank, unfortunately. Depending on the OpenSSL used, some input (mouse, bang the keys, copy files, whatever) will help speed the randomness.
The names ca.key & ca.crt can be whatever you want them to be. Remember them for later use.
openssl genrsa -des3 -out ca.key 4096
Then use the key to create a certificate. Again, the names don’t matter, but they need to be remembered and used. Note this one expires in about a year (given allowance for leap-years). You’ll be prompted for the CA key password. You’ll also have to give a little bit of text that will allow users to determine the validity of the certificate (example follows). The key is that the Common Name should match the FQDN of the cert system. Since we’re not publishing the cert, it’s kind if moot, but good practice to follow.
You'll have to type the first line completely (names and such are up to you), but then the program will prompt you for the rest; use your data, not my examples.
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Minnesota
Locality Name (eg, city) []:Minneapolis
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Company
Organizational Unit Name (eg, section) []:Department
Common Name (eg, YOUR name) []:server.local
Email Address []:admin@server.local
Certificate Signing Request
The CSR contains info about the server that the CA will use to generate a certificate. A key is used to encode the data. If you were going to use a proper third-party CA, they may have a tool to help you generate this, or you’d generate one yourself and then send them the CSR (probably in ASCII form).
Like the CA, this makes a DES3 encrypted key. You’ll also be prompted for a password, and it can’t be blank. Remember the name for later use.
openssl genrsa -des3 -out server.key 4096
Use the key to generate the CSR. Again, like the CA, you’ll be prompted for the key password and some input for the details about the certified system; in a real third-party situation this file would be sent to them, and the information within would be validated and authenticated by various means, depending on the quality of the certificate desired—for our needs, this is just the text displayed when viewing the certificate.
Common Name
There is one special value here! When generating the CSR, the Common Name needs to match the server being certified as this will be compared when the clients reach the server.
You'll have to type the first line completely (names and such are up to you), but then the program will prompt you for the rest; use your data, not my examples.
openssl req -new -key server.key -out server.csr
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Minnesota
Locality Name (eg, city) []:Minneapolis
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Company
Organizational Unit Name (eg, section) []:Department
Common Name (eg, YOUR name) []:fully.qualified.domain.name
Email Address []:admin@domain.name
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Remember, that fully.qualified.domain.name needs to match the name of the server that will finally use the certificate. If you try to make this generic or if it's wrong, the browsers will receive an error indicating the server name mismatch.
Certificate
Finally, we can create the certificate. This file and the key file will be given to Apache for serving the SSL. Using a third-party CA, this is the file they’d send you. You’d use that certificate file and the key file you used to generate the CSR to work on the server.
Here we’re asking for a year-ish (again, allowing for leap years) long file. You’ll be prompted for the CA key password created before.
Serial Number
A quick word about the serial number. Unless we’ve got our openssl set up to keep track of the serial numbers for us (beyond this scope), we need to specify one—the *XX* in the command line example. Specifically, it’s got to be a new generation (incrementing numeric) for each FQDN certified; generally, just use an increment so that you don’t have to maintain the number per certificate. If in doubt, look at the old certificate.
Start with 1, and every time you make a cert, use the next number. Or start huge and use the epoch timestamp. As long as the newer is larger than the previous, all will be well.
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial *XX* -out server.crt
Finally, we’ll take the password out of the equation. There are tricks to share the password with Apache, but really more secure than that is to make a password-less copy of the key file and make the Apache process owner (httpd) the owner of the file, and restrict the access to just that user.
openssl rsa -in server.key -out server.key.insecure
cp server.key server.key.secure
cp server.key.insecure server.key
chmod 600 server.key
chown httpd:httpd server.key
Apache Configuration
Now copy the server.crt and password-free server.key files to the Apache conf folder (or remember to replace the sample with the complete and accurate path). As repeatedly mentioned, the names of the file are irrelevant (with regard to their content), so feel free to locate and name them in ways that make sense.
Add a few bits to the Apache configuration to use the files. If you review the extras/httpd-ssl.conf that comes with the Apache distribution, there’s a lot in there. Here’s the meat of what is needed. Note, just use the key and cert file names and paths that match.
LoadModule ssl_module modules/mod_ssl.so
Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine On
SSLCertificateFile conf/server.crt
SSLCertificateKeyFile conf/server.key
</VirtualHost>
Virtual Host
A word about the VirtualHost. SSL is a socket-layer wrapper, and therefore occurs before the HTTP request. The VirtualHost handling mechanism for Apache happens by evaluating the HTTP request and headers. If intending to use SSL on a true virtual hosting system, each host needs its own IP or port (443 is the HTTPS default) on the server, and the VirtualHost notation needs to be affected to match accordingly. It's also worth noting that the server certificate should be unique for each (or SSL errors will occur), but the key file can be shared among the different certificates; simply, the key file needs to match with the one used to create the certificate request.