Web Hosting How-Tos

  Home arrow Web Hosting How-Tos arrow Page 4 - Apache Configuration -- Advanced
Web Hosting Articles  
Web Hosting FAQs  
Web Hosting How-Tos  
Web Hosting News  
Web Hosting Reviews  
Web Hosting Security  
Weekly Newsletter 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Contact Us 
Site Map 
Privacy Policy 
  >>> SIGN UP!  
  Lost Password? 

Apache Configuration -- Advanced
By: Michael Swanson
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 11

    Table of Contents:
  • Apache Configuration -- Advanced
  • Other Protocols on Apache
  • SSL on Apache
  • Certificates

  • Rate this Article: Poor Best 
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article




    Apache Configuration -- Advanced - Certificates

    (Page 4 of 4 )


    Certificates are what make SSL work; they are the public keys that enable the encryption to succeed. There are two basic types of keys. The first type is signed by a  trusted Certificate Authority (CA), and is generally used for processing of private information from the general public. By signing these certificates, the CA has placed its name on these digital signatures and maintains that the company using them is not phony. An example of a CA is a company like VeriSign, which will allow you to send in your certificate to them and will sign it so it can be trusted by Internet users at large.


    The second type of certificate is called a self-signed certificate. These are generally used within a company or when the user is in some way known to and knows of the company, so as to be convinced to trust the signer, which is the company itself. These are usually not suitable for use in processing credit card data; most customers won’t trust them, because they are not signed by a trusted CA. These are the certificates that cause warning windows to pop up in browsers, which would tell the user, if they actually read them, that the certificate being used by that server is not signed by a well known CA. However, the security protection provided by either of these types of certificates is the same, and data sent using either is unreadable by a third party, regardless of how the server certificate is signed (assuming a self-signed certificate isn’t used maliciously).


    I will describe here how to use the OpenSSL library (which can be found at: http://www.openssl.org) to generate a key file and certificate signing request that can be sent to a CA for signing. The first step in this process is to create an encrypted key file that will be used by the server as its private key, which is never sent to anyone on the Internet; it remains on the local disk. This key is then used to generate the public certificate that is sent to clients.  In OpenSSL, the command to do this looks something like this:


    openssl genrsa –des3 –out myServer.key 1024


    The above command generates a 1024-bit key encrypted using the DES3 algorithm and places it in the myServer.key file. This process will ask for a pass phrase used to generate the key.  It is very important to remember this phrase, as you will need to enter it every time you start the server up to decrypt the key file for the server’s use. It is also possible to create an un-encrypted key, but this stores the key data on your hard drive in plaintext, which means that if someone were to gain access to your physical computer either over the network or otherwise, they would have all the information necessary to impersonate your server. For this reason, it is suggested that an encrypted key provides better security.


    The next step in the certificate process is to create a Certificate Signing Request that gets sent to the CA for signing and return as a full fledged certificate. The following command creates this file:


    openssl req –new –key myServer.key –out myServer.crt


    This takes the key file generated above and uses it to create the myServer.crt file, which contains the certificate request that can be given to the CA through whatever means they wish (a Web form, over email, etc.). This command will prompt you for much information used to define your organization as a unique unit, including the domain name that is used when connecting to your site. Once you have created this file, you can give it to a trusted CA for them to digitally sign. You can then use the signed certificate to securely process transactions across the Web.


    Now that you have your certificate file, you can begin configuring the server to use SSL. The first step is to make sure that you have downloaded and installed the necessary files for mod_ssl and OpenSSL.  Instructions for both of these tasks can be found at www.modssl.org and www.openssl.org. Once you have these files downloaded, installed and compiled in to your Apache server, you will need to configure the appropriate lines in the httpd.conf file, again.


    One thing to note in this process is that generally you will want SSL to be enabled for certain virtual hosts only, as you generally will not want the entire server using this protocol. This is the process I will use when showing examples, but all of these configuration lines may be applied to the server as a whole. Also note that you cannot use SSL on Name-based virtual hosts; this is basically due to a protocol restriction, and as such has no immediate solution. This means that when you set up your SSL virtual hosts, they will all need to be for IP addresses and port combination, not a server domain name. A simple SSL set-up would look something like this:


                <VirtualHost 123.234.345.111:443>

                            SSLEngine On

                            SSLCertificateFile /web/cert/myServer.crt

                            SSLCertificateKeyFile /web/cert/myServer.key

                            SSLPassPhraseDialog builtin



    Let’s go through and see what each of these lines do.  First, the SSLEngine line simply tells Apache that this virtual host will be making use of SSL. The two File lines point Apache to the Certificate and Key files that are associated with this VirtualHost. Finally, the SSLPassPhraseDialog tells Apache how to obtain the pass phrase used to decrypt the key file. The “builtin” argument, given here, tells Apache to simply ask at the console for the pass phrase, however, this requires that someone be present at the console every time Apache starts up.


     There are other options to this directive called “exec:<path>” and “pipe:<path>”, each of which would normally have <path> replaced with the path to an executable that would run to return the correct pass phrase to the server. The main tasks of this program are to check to make sure that it is actually talking to the correct server and that that server has not been compromised. This is important because it preserves the security of the pass phrase while still automating the start-up process.


    These are the basic directives necessary to configure SSL on Apache.  However, there are several others that allow the administrator the power to control which types of ciphers are used by the server as well as tweak other options for SSl.  The full list and descriptions of these directives is too long for this article, but their descriptions can be found on the mod_ssl website here: http://www.modssl.org/docs/2.8/ssl_reference.html.




    This brings to a close the Apache configuration articles. Throughout these articles, I have tried to show how to configure an Apache server in the most secure, simple, and effective way. There are, of course, many more options, modules, and configuration directives not directly addressed in these articles, some of which may be necessary or useful for readers. The best place to find descriptions of and information on these directives is the Apache Software Foundation website, which can be found at simply www.apahce.org. 


    Specifically, the documentation for Apache 2.0 is at: http://httpd.apache.org/docs-2.0/ .  This contains more exhaustive information on all possibilities for configuring Apache, and probably has some sort of answer for most tasks you could wish to perform with a Web server, and probably many more. Apache is the most popular and probably the most powerful Web server available, so configuring it can seem like a daunting task at times. However, once you have a server up and running successfully, the rewards can be tremendous, so go download and install Apache today!

    DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.


    - Phishing Scams: An Overview and How to Detec...
    - Tips for Safe Downloading Online
    - How To Avoid Spam
    - How to Get Into Ethical Hacking
    - How to Prevent Drive-by Downloads
    - Facebook Timeline Tips and Tricks
    - How to Keep Up with Facebook`s Changes
    - Wi-Fi Network Security Tips
    - Tips for Safe Online Holiday Shopping
    - Facebook Privacy: Keeping Up with the Const...
    - Tips for Facebook Privacy
    - How to Cover Your Tracks on the Web
    - SSH Keys for FileZilla and Putty in Cpanel
    - How to Create a Filezilla FTP User
    - How to Install FileZilla Server

    Developer Shed Affiliates


    © 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap