Filling in the Certificate Fields
As I mentioned earlier, issuing a command to generate a CSR or a self-signed certificate will cause OpenSSL to ask a series of questions about the information to be placed in the certificate. The importance of how accurate the information is will vary depending on the type of the certificate and its purpose. If it’s just a test certificate, the information is of little importance, but if it’s for a CSR that you intend to have signed by a CA then the accuracy of the information is extremely important.
The following is a list of the fields which OpenSSL is likely to ask about. If you’re using the standard command-line interface to do this then you will see that OpenSSL will name the fields that need filling in by their full textual name; however, I’ll also give you the common abbreviations by which the fields are also known in case you’re doing this via a Web host control panel and the fields are marked by their abbreviations only.
|A capitalized two-letter country code for you or your organization. For example, UK, RO, DE, etc.|
|State or Province Name
|The name of the state or province for you or your organization in full textual form. For example, Quebec, Gaza, Alaska, etc.|
|The name of the city or town for you or your organization in full textual form. For example Edinburgh, Stockholm, Ulooloo, etc.|
|The name of your organization/company/domain in full textual form.|
|Organizational Unit Name
|The name of the organization’s department in full textual form.|
|Regardless of the type of certificate you intend to obtain or the purpose for which you intend to use it, this field is of critical importance. This field must contain the exact domain name for which it will be used including the subdomain part. If the subdomain does not match then it will still be possible to use the certificate, but another one of those large warning messages will be presented to the user. So if you have www.domainname.com as the CN in the certificate and a user connects to domainname.com (without the www). then the domain names will be considered as non-matching and the warning will be issued; however, if the main domain part of the domain name does not match then it is unlikely that Apache will even start at all. So make certain that you specify the correct subdomain and that the domain name is completely free of typos.|
|Even in its abbreviated form it’s pretty obvious what this field is for. Assuming that they exist, good choices would be email@example.com or firstname.lastname@example.org.|
Once you have your certificate you need to configure Apache to make use of it. The standard configuration process is simple, but it’s one of those areas where control panels often add unnecessary complexity, which can create confusion.
To configure Apache the normal way you need to make a few small edits to two configuration files. The edits will differ very slightly depending on whether you’re using version 2.x or 1.x of Apache. For both versions of Apache, you make the same changes to the SSL configuration file, but users of Apache 2 will also need to make a single change to the main httpd.conf configuration file: simply uncommenting a line in the file. Users of Apache 1.x won’t have to make any changes to the main config file, but they will need to use a slightly different command to start Apache.
The main SSL configuration file, ssl.conf or httpd-ssl.conf, needs only two lines to be changed. The first line to change begins with SSLCertificateFile. The line may already have an example file path set, but be commented out with a #. Just remove the comment marker and replace the example file path with the file path to your certificate that you’ve just obtained. You treat the second line in the same way: removing the comment and replacing the example file path with your actual one. The second line that you’ll want to change is the SSLCertificateKeyFile line. You must use this line to specify the file path to the key that you used to create the certificate or CSR.
The next step depends on which version of Apache you use. Users of Apache 1.x won’t need to make any more configuration changes and should stop Apache from running and then start it again using the apachectl startssl command instead of apachectl start. It’s most likely that your installation of Apache will be started by an init script. If this is the case, I strongly recommend that you edit your init script to use the startssl variant. If you don’t know what an init script is, it would be a good idea to ask your hosting provider to do it for you. Just tell them that you want it to use the startssl startup command.
If you’re using Apache 2.x, then you shouldn’t need to bother with init scripts and using different commands. Just go into your main httpd.conf file and find the line that says something like: #Include conf/extra/httpd-ssl.conf (most likely right at the very bottom of the file) and remove the comment character at the beginning of the line. Save the changes, restart Apache and you should be good to go.
If you’re using a control panel to manage your host then there isn’t a great deal of advice I can give. I’ve noticed that Apache configuration tends to be one of the most unreliably supported aspects of Web host control. It’s not uncommon for it to be missing. In other cases it might be there, but presented in a disorganized manner with an awkward UI (user interface). If you’re lucky, you might have the actual Apache config file available in a large text area which can be used to edit the file and be able to save it there. If that’s the case then you can simply follow the steps outlined above. If not, then you’re going to have to ask your hosting provider to make the changes for you.
Once you’ve made the changes to the config files and restarted Apache, you should be able to connect via https to whichever domain you specified in the certificate without any issues. If you have a self-signed certificate, your browser will bring up a large warning about the certificate, but if you tell your browser to accept/install/import/add an exception for the certificate you should then be able to connect as normal. If you have a CA-signed certificate, your browser will trust the certificate automatically. In either case, you’re good to go.
Do It Yourself SSL Guide
Article courtesy of Webreference
|Key Terms To Understanding SSL:||Related Articles on Webopedia:|
This article was originally published on October 08, 2008