GNU.WIKI: The GNU/Linux Knowledge Base

  [HOME] [HowTo] [ABS] [MAN1] [MAN2] [MAN3] [MAN4] [MAN5] [MAN6] [MAN7] [MAN8] [MAN9]


  Building a Secure RedHat Apache Server HOWTO
  Richard Sigle,
  0.1, 2001-02-06

  The guide is designed to explain how PKI and SSL work together.  It is
  essential to understand how the SSL protocol works to successfully
  deploy a secure server.

  Table of Contents

  1. Purpose/Scope of this Guide

     1.1 About Secure Sockets Layer (SSL)
     1.2 FeedBack
     1.3 Copyrights and Trademarks
     1.4 Acknowledgements and Thanks

  2. Introduction to Secure Sockets Layer/Private Key Infrastructure

     2.1 Responsibilities of SSL/PKI
     2.2 How SSL Works
        2.2.1 SSL Handshake Protocol
        2.2.2 Session Key(Symmetric Code)
        2.2.3 Public/Private Key Pair(Asymmetric Code)
     2.3 How PKI Works
     2.4 Certificates(x509 Standard)
     2.5 Digital Certificate Private Key
     2.6 Digital Certificate Public Key
     2.7 Certificate Signing Request(CSR)

  3. Working with Certificates

     3.1 Create a Private Key
     3.2 Create a Certificate Signing Request
     3.3 Creating a Self-Signed Certificate
     3.4 Installing your Web Server Certificate

  4. Configuring your Apache Server

     4.1 Define a Secure Virtual Host
        4.1.1 SSL Engine
        4.1.2 SSLCertificateFile
        4.1.3 SSLCertificateKeyFile
        4.1.4 SSLCACertificateFile
     4.2 Certificate Examples
        4.2.1 Server Certificate File
        4.2.2 Contents of the Certificate File
        4.2.3 Private Key File
        4.2.4 Contents of the Private Key
     4.3 Restart the Web Server

  5. Troubleshooting

     5.1 Server Appears to start, but you cannot access the secure site
     5.2 Certificate Name Check Warning is issued by the client's browser
     5.3 Certificate was Signed by an Untrusted Certificate Authority Warning is issued by the client's browser
     5.4 SSLEngine on is an un-recognized command (when starting Apache)
     5.5 You have forgotten your "PEM Passphrase" and you would like to know how to reset it

  6. Glossary


  1.  Purpose/Scope of this Guide

  The purpose of this guide is to assist RedHat Linux users with the
  installation of server (SSL) certificates using the Apache web server.
  The goal is to provide a clear procedure that will save time and, in
  many cases, money!

  First, I will cover what you need to know about the SSL protocol and
  digital certificates.  In my experience, building an Apache web server
  with ModSSL and OpenSSL is the most beneficial software combination.
  OpenSSL is a general-purpose cryptography library that supports the
  SSL v2/v3 and TLS v1 protocols.  ModSSL is an Apache API module
  designed to act as an interface between Apache and OpenSSL.  The
  biggest advantage is that all three packages are free.

  Then, beginning with Section 4, I will go through the step-by-step
  procedures for generating keys and installing certificates on a
  RedHat-Apache server compiled with ModSSL and OpenSSL.  The procedures
  in Section 4 will also work with commercial SSL-server packages such
  as Stronghold and Raven that are closely related to Apache.

  Disclaimer:  I am a technical support engineer for Equifax Secure
  Inc., a Certificate Authority.  Therefore, I use Equifax Secure
  certificates and examples geared towards installing Equifax Secure
  certificates.  However, the instructions will also work with
  certificates issued by other Certificate Authorities.  Since this
  document was written at my own initiative, Equifax Secure Inc. is
  neither liable nor accountable for any consequences resulting from the
  use of these procedures.

  My comments to the reader is in this style (emphasized).

  Example lines are in plain roman style.

  Note that extra comments and advice is found in comments within the
  SGML source.

  1.1.  About Secure Sockets Layer (SSL)

  SSL is a presentation layer service, located between the TCP and the
  application layer.  It is platform and application independent.  SSL
  is responsible for the management of a secure communications channel
  between the client and server.  SSL provides a strong mechanism for
  encrypting data transferred between a client and a server.

  1.2.  FeedBack

  Comments on this guide may be directed to the author

  1.3.  Copyrights and Trademarks

  Copyright (c) 2001 by Richard L. Sigle

  Please freely copy and distribute this document in any format. It's
  requested that corrections and/or comments be forwarded to the
  document maintainer. You may create a derivative work and distribute
  it provided that you:

  �  Send your derivative work (in the most suitable format such as
     sgml) to the LDP <> (Linux Documentation
     Project) or the like for posting on the Internet. If not the LDP,
     then let the LDP know where it is available.

  �  License the derivative work with this same license or use GPL.
     Include a copyright notice and at least a pointer to the license

  �  Give due credit to previous authors and major contributors.

  If you're considering making a derived work other than a translation,
  it's requested that you discuss your plans with the current

  1.4.  Acknowledgements and Thanks

  I would like to thank Tony Villasenor for tirelessly reading my drafts
  and offering his input and advice. Without Tony, this document would
  never have been finished.

  2.  Introduction to Secure Sockets Layer/Private Key Infrastructure

  PKI is an asymmetric key system which consists of a public key (which
  is sent to clients) and a private key (stays local on the server).
  PKI differs from a symmetric key system in which both the client and
  server use the same key for encryption/decryption.

  2.1.  Responsibilities of SSL/PKI

  SSL sets out to fulfill requirements that make it acceptable for use
  in the transmission of even the most sensitive of transactions, such
  as credit card information, medical records, legal documents, and e-
  commerce applications.  Each application can choose to utilize some or
  all of the following criteria depending on the sensitivity and value
  of the transactions it will be processing.

        Let's say that a message is to be coded for transmission from A
        to B. A uses B's public key to encrypt the message. In this way
        B will be the only person who can decode and read this message
        using his private key. We cannot however be sure that A is the
        person who he claims to be.

        In order to be sure that A is the person who he claims to be, we
        want guaranteed authenticity.  This requires a slightly more
        complex coding process. In this case, A's message to B is first
        encrypted with A's private key and then with B's public key.  B
        now has to decrypt it first with his private key and then with
        A's public key. Now B can be sure that A is who he claims to be
        as nobody else could create a message encrypted with his private
        key. SSL achieves this with the use of certificates (PKI). A
        certificate is issued by a neutral third party - such as a
        certificate authority (CA) - and includes a digital signature
        and/or a time stamp in addition to the public key of the
        certified party.  A self-signed digital certificate can be
        created by anyone with the correct SSL tools, but self-signed
        certificates lack the weight of validation performed by a
        mutually respected neutral third party.

        In SSL, integrity is guaranteed by using a MAC (Message
        Authentication Code) with the necessary hash table functions.
        Upon generation of a message, the MAC is obtained by applying a
        hash function and the result is then added to the message.
        After the message has been received, validity is then checked by
        comparing the message's embedded MAC with a new MAC computed
        from the received message.  This would immediately reveal
        messages that have been altered by a third party.

        Non-repudiation protects both parties from each other during
        online transactions.  It prevents one or the other from saying
        that they did not send a particular piece of information.  Non-
        repudiation does not allow either party to alter the transaction
        after it has been made.  Digital non-repudiation is the
        equivalent of signing a contract, in the traditional sense.

  2.2.  How SSL Works

  The SSL protocol includes two sub-protocols: the SSL record protocol
  and the SSL handshake protocol.  The SSL record protocol defines the
  format used to transmit data. The SSL handshake protocol involves
  using the SSL record protocol to exchange a series of messages between
  an SSL-enabled server and an SSL-enabled client when they first
  establish an SSL connection. This exchange of messages is designed to
  facilitate the following actions:

  �  Authenticate the server to the client.  The server certificate is
     signed by a Certificate Authority to insure that it is not
     corrupted and establishes a chain of trust.

  �  Allow the client and server to select the cryptographic algorithms,
     or ciphers, that they both support.

  �  Optionally authenticate the client to the server.

  �  Use public-key encryption techniques to generate shared secrets.

  �  Establish an encrypted SSL connection.

  2.2.1.  SSL Handshake Protocol

  The Handshake Protocol is used to co-ordinate the state of the client
  and the server. During the handshake, the following events take place:

  �  Certificates are exchanged between the client and server
     (asymmetric keys).  The server sends its public key to the client.
     If the server is set to verify client authentication via a
     certificate, the client sends its public key to the server.  The
     validity dates on the certificates are verified and they are
     checked for the digital signature of a trusted certificate
     authority.   If the validity date and/or digital signature are not
     correct, the browser will issue a warning to the user.  The user is
     then given the option to trust the certificate holder.

  �  The client then generates a random key (symmetric key). These will
     be used for encryption and for calculating MACs. They are encrypted
     using the server's public key and sent to the server.  Only the
     server has the ability to decrypt the new random key.  The new
     symmetric key is used for encrypting the data that is sent between
     client and server.

     Note:  The use of a symmetric key after server-browser
     authentication greatly enhances subsequent throughput performance.

  �  A message encryption algorithm and a hash function for integrity
     are negotiated.  This negotiation process could be carried out such
     that the client presents a list of supported algorithms to the
     server, which, in turn, selects the strongest cipher available to
     both of them. Identifiers for the chosen encryption algorithm and
     hash function are stored in the cipher spec field of the current
     state for use by the record protocol.

  �  All of the following fields are set during handshaking: Protocol
     Version, Session ID, Cipher Suite, Compression Method and two
     random values ClientHello.random and ServerHello.random.

  Note: An IP address is required for each SSL connection.  Name based
  virtual hosts are resolved during the application layer.  Remember
  Secure Sockets Layer resides below the application layer.

  2.2.2.  Session Key(Symmetric Code)

  �  40-bit, originally used only for export purposes

  �  56-bit, used by DES

  �  64-bit key - used by CAST, 256 times stronger than 56-bit

  �  80-bit key - used by CAST, 16 million times stronger than 56-bit
     (infeasible to break with current technology)

  �  128-bit key - used by CAST or RC2, exhaustive key search impossible
     now and for the foreseeable future

  2.2.3.  Public/Private Key Pair(Asymmetric Code)

  �  512-bit

  �  768-bit

  �  1024-bit

  �  2048-bit

  2.3.  How PKI Works

  The client and the server each have a public key and a private key
  (the client's browser randomly creates a key pair for the SSL session,
  unless, a client certificate is held by the client and requested by
  the server).

  The sender uses their private key to encrypt a message.  This act
  authenticates the source of the message.  The resulting cipher is
  encrypted once more with the receiving party's public key.  This
  action provides confidentiality because only the receiving party is
  able to do the initial decryption of the message using their private
  key.  The receiver uses the sender's public key to further decrypt the
  encrypted message. Because only the sender has access to their private
  key, the receiver is assured that the encrypted message originated
  from the sender.

  A message digest is used to verify that neither party or a third party
  has tampered with or changed the message in any way.  A message digest
  is obtained by applying a hash function (part of the private key known
  as the fingerprint) to the message.  The digest (which is now known as
  the signature) is attached or appended to the message.  The
  signature's length is constant (no matter how large the file is) and
  depends on what type of message digest the private key contains (md5 -
  128 bit, sha1 - 160 bit, etc).  Changing even one bit in the message
  will change the length of the signature and thus prove that the
  message has been tampered with.

  2.4.  Certificates(x509 Standard)

  Digital certificates make it possible to trust an entity on the
  Internet.  A digital certificate contains the user's credentials,
  which have been verified by a neutral third-party certificate

  A mathematical algorithm and a value (key) are used to encrypt data
  into an unreadable form.  A second key is used to decrypt the data,
  using a complementary algorithm and a related value.  The two keys
  must contain a related value and are known as a key pair.

  Note:  ITU-T Recommendation X.509 [CCI88c] specifies the
  authentication service for X.500 directories, as well as the X.509
  certificate syntax. The certificate is signed by the issuer to
  authenticate the binding between the subject (user's) name and the
  user's public key.  SSLv3 was adopted in 1994.  The major difference
  between versions 2 and 3 is the addition of the extensions field. This
  field grants more flexibility as it can convey additional information
  beyond just the key and name binding. Standard extensions include
  subject and issuer attributes, certification policy information, and
  key usage restrictions.

  An X.509 certificate consists of the following fields:

  �  Version

  �  serial number

  �  signature algorithm ID

  �  issuer name

  �  validity period

  �  subject (user) name

  �  subject public key information

  �  issuer unique identifier (version 2 and 3 only)

  �  subject unique identifier (version 2 and 3 only)

  �  extensions (version 3 only)

  �  signature on the above fields

  2.5.  Digital Certificate Private Key

  The private key is not embedded within a digital certificate.  The
  private key does not include any server information.  It contains
  encryption information and a fingerprint.  It is generated locally on
  your system and should remain in a secure environment.  If the private
  key is compromised, a perpetrator essentially has the code to your
  security system.  The transmissions between client and server can be
  intercepted and decrypted.  This type of vulnerability is why it is
  recommended to create a private key that is encrypted using triple DES
  technology.  The file is then encrypted and password protected making
  it all but impossible to use without the correct pass phrase.

  The security of a transaction is dependent on its private key. Should
  this key fall into the wrong hands then anyone can easily duplicate it
  and use it to compromise security.  A compromised key could lead to
  messages meant for the server to be intercepted and manipulated by
  unscrupulous hackers.  A fully secure system must be able to detect
  impostors and prevent the duplication of keys.

  2.6.  Digital Certificate Public Key

  The public key is embedded in a digital certificate, which is sent by
  the server to a client when a secure connection is requested.  This
  process identifies the server using the certificate.  The public key
  validates the integrity, authenticity, and is also used to encrypt
  data to create a private data transmission.

  2.7.  Certificate Signing Request(CSR)

  A CSR contains the information required by a certificate authority to
  create the certificate.  The CSR contains an encrypted version of the
  private key's complimentary algorithm, common value, and information
  that identifies the server.  This information includes, but is not
  limited to, country, state, organization, common name (domain name),
  and contact information.

  3.  Working with Certificates

  The following section covers the steps involved in creating the
  private key file, certificate signing request, and a self-signed
  certificate.  If you plan to obtain a certificate signed by a
  certificate authority, you will need to create a certificate signing
  request (CSR).  Otherwise, you can create a self-signed certificate.

  3.1.  Create a Private Key

  To create a private key, you must have the OpenSSL toolkit installed
  and configured with Apache.  The following examples use the OpenSSL
  command line tool which is located in the /usr/local/ssl/bin directory
  by default.  The examples assume that the directory containing the
  OpenSSL command line tool has been added to the $PATH.

  To create a private key using the triple des encryption standard
  (recommended), use the following command:

       openssl genrsa -des3 -out filename.key 1024

  You will be prompted to enter and re-enter a pass phrase.  If you
  choose to use triple des encryption, you will be prompted for the
  password each time you start the SSL server from a cold start.  (When
  using the restart command, you will not be prompted for the password).
  Some of you may find this password prompt to be a nuisance, especially
  if you need to boot the system during off-hours.  Or, you may believe
  that your system is already sufficiently secure.  So, if you choose
  not to have a password prompt (hence no triple des encryption), use
  the command below.  If you would rather create just a 512-bit key,
  then omit the 1024 at the end of the command and OpenSSL  will default
  to 512 bits.  Using the smaller key is slightly faster, but it is also
  less secure.

  To create a private key without triple des encryption, use the
  following command:

       openssl genrsa -out filename.key 1024

  To add a password to an existing private key, use the following

       openssl -in filename.key -des3 -out newfilename.key

  To remove a password from an existing private key, use the following

       openssl -in filename.key -out newfilename.key

  Note:  Your private key will be created in the current directory
  unless otherwise specified.  There are 3 easy ways to deal with this.
  If OpenSSL is in your path, you can run it from the directory that you
  have designated to store your key files in (default is
  /etc/httpd/conf/ssl.key if you installed Apache using the RPM or
  /usr/local/apache/conf/ssl.key if you installed Apache using the
  source files).  Another solution is to copy the files from the
  directory where they were created to the correct directory.  And, last
  but not least, you can specify the path when running the command (eg.
  openssl genrsa -out /etc/httpd/conf/ssl.key/filename.key 1024).
  Doesn't matter how you do it as long as it gets done before you

  For more information on the OpenSSL toolkit check out: OpenSSL Website

  3.2.  Create a Certificate Signing Request

  To obtain a certificate signed by a certificate authority, you will
  need to create a Certificate Signing Request (CSR).  The purpose is to
  send the certificate authority enough information to create the
  certificate without sending the entire private key or compromising any
  sensitive information.  The CSR also contains the information that
  will be included in the certificate, such as, domain name, locality
  information, etc.

  �  Locate the private key that you would like to creat a CSR from.
     Enter the following command:

       openssl req -new -key filename.key -out filename.csr

  �  You will be prompted for Locality information, common name (domain
     name), organizational information, etc.  Check with the CA that you
     are applying to for information on required fields and invalid

  �  Send the CSR to the CA per their instructions.

  �  Wait for your new certificate and/or create a self-signed
     certificate.  A self-signed certificate can be used until you
     receive your certificate from the certificate authority.

  Note: Use the following command to create a private key and request at
  the same time.
       openssl genrsa -des3 -out filename.key 1024

  3.3.  Creating a Self-Signed Certificate

  It is not necessary to create a self-signed certificate if you are
  obtaining a CA-signed certificate. However, creating a self-signed
  certificate is very simple.  All you need is a private key and the
  name of the server (fully qualified domain name) that you want to
  secure.  You will be prompted for information such as locality
  information, common name (domain name), organizational information,
  etc.  OpenSSL gives you a great deal of freedom here.  The only
  required field for the certificate to function correctly is the common
  name (domain name) field.  If this is not present or incorrect, you
  will receive a Certificate Name Check warning from your browser.

  To create a self-signed certificate:

       openssl req -new -key filename.key -x509 -out filename.crt

  3.4.  Installing your Web Server Certificate

  If you followed these instructions so far you shouldn't have any
  problems at this point.  If you sent your CSR to a certificate
  authority and you have not gotten your certificate back yet, you can
  take a break now!  If you are using a self-signed certificate, or you
  have received your certificate, you may continue.

  �  Ensure that the private key file is in the directory that you have
     chosen to use.  The following examples will be based on the RedHat
     RPM installation default of /etc/httpd/conf/ssl.key.

  �  Ensure that the CA-signed or self-signed certificate is in its
     designated location.  Again, I will be using the RPM default of
     /etc/httpd/conf/ssl.crt.  If it is not there already, put it there.

  �  If there is an intermediate (root) certificate to be installed,
     copy it to the /etc/httpd/conf/ssl.crt directory, also.

  �  Now, you will be required to edit the httpd.conf file.  Make a
     back-up of this file before you proceed to the next step,
     ``Configuring your Apache Server''.

  4.  Configuring your Apache Server

  The Apache server must be configured with supplementary API modules in
  order to support SSL.  There are many SSL software packages available.
  My examples are based on Apache configured with ModSSL and OpenSSL.
  There are countless mailing lists and newsgroups available to support
  these products.  You may find these instructions helpful for some
  commercial SSL software packages that are based on the Apache web
  A few things to keep in mind:  You can have multiple virtual hosts on
  the same server.  You can have numerous name-based virtual hosts on
  the same IP address.  You can also have numerous name-based virtual
  hosts and one (1) secure virtual host on the same IP.  But - you
  cannot have multiple secure virtual hosts on the same IP.  The
  question that so many ask:  Why?  The answer is:  SSL works below the
  application layer.  Name based hosts are not defined until the
  application layer.

  Specifically, you cannot have multiple secure virtual hosts on the
  same SOCKET (IP address + port).  By default, a secure host will use
  port 443.  You can change configure your virtual host to use a
  different port number with the same IP, thus creating another socket.
  There are many disadvantages to this approach.  The most obvious
  disadvantage is that if you are not using the default port, your URL
  must also contain the port number to access the secure site.


  �  Site using default port - - would be accessed as

  �  A site using port 8888 would be accessed as

  Another disadvantage is that if you introduce more ports, you will be
  providing more opportunities for port sniffing hackers.  Last, if you
  select a port that is used by something else, you will create conflict

  4.1.  Define a Secure Virtual Host

  Setting up virtual hosts is fairly straightforward.  I will go through
  the basics of setting up a secure virtual host.

  In these examples, I use the .crt and .key file extensions.  That is
  my personal way of avoiding confusion with the various files.  With
  Apache, you can use any extension you choose - or no extension at all.

  All of your secure virtual hosts should be contained within <IfDefine
  SSL> and </IfDefine SSL>, usually located towards the end of the
  httpd.conf file.

  An example of a secure virtual host:

  DocumentRoot /etc/httpd/htdocs
  ErrorLog /etc/httpd/logs/error_log
  TransferLog /etc/httpd/logs/access_log
  SSLEngine on
  SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
  SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
  SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt
  <Files ~ "\.(cgi|shtml)$">
        SSLOptions +StdEnvVars
  <Directory "/etc/httpd/cgi-bin">
        SSLOptions +StdEnvVars
  SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
  CustomLog /etc/httpd/logs/ssl_request_log \
            "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

  The directives that are the most important for SSL are the SSLEngine
  on, SSLCertificateFile, SSLCertificateKeyFile, and in many cases
  SSLCACertificateFile directives.

  4.1.1.  SSL Engine

  "SSLEngine on" - this is ModSSL's command to start SSL.

  4.1.2.  SSLCertificateFile

  SSLCertificateFile Tells Apache where to find the certificate file and
  what it is named.  The example above shows "server.crt" as the
  certificate file name.  This is the default that is added when you
  configure ModSSL with Apache.  I personally don't recommend using the
  default names.  Save yourself some frustration and name your
  certificates as servername.crt (domainname.crt).  You may also decide
  to use an alternative directory than the default
  /etc/httpd/conf/ssl.crt or /usr/local/apache/conf/ssl.crt.  Just
  remember to make the necessary changes to the path.

  4.1.3.  SSLCertificateKeyFile

  SSLCertificateKeyFile tells Apache the name of the private key and
  where to find it.  The directory defined here should have read/write
  permissions for root only.  No one else should have access to this

  4.1.4.  SSLCACertificateFile

  The SSLCACertificateFile directive tells Apache where to find the
  Intermediate (root) certificate.  This directive may or may not be
  necessary depending on the CA that you are using.  This certificate is
  essentially a ring of trust.

  Intermediate Certificate - A Certificate Authority obtains a
  certificate in much the same way as you.  This is known as an
  intermediate certificate.  It basically says that the holder of the
  intermediate certificate is whom they say they are and is authorized
  to issue certificates to customers.  Web browsers have a list of
  "trusted" certificate authorities that is updated with each release.
  If a Certificate authority is fairly new, its intermediate certificate
  may not be in the browser's list of trusted CA's.  Combine this with
  the fact that most people don't update their browsers very often; it
  could take years before a CA is recognized as trusted automatically.
  The solution is to install the intermediate certificate on the server
  using the SSLCACertificateFile directive.  Usually, a "trusted" CA
  issues the intermediate certificate.  If it is not, then you may need
  to use the SSLCertificateChainFile directive, although this is

  4.2.  Certificate Examples

  4.2.1.  Server Certificate File

       -----BEGIN CERTIFICATE-----
       -----END CERTIFICATE-----

  4.2.2.  Contents of the Certificate File

       Version: 3 (0x2)
       Serial Number: 1516 (0x5ec)
       Signature Algorithm: md5WithRSAEncryption
       Issuer: C=US, O=Equifax Secure Inc, CN=Equifax Secure E-Business CA
         Not Before: Jul 12 15:21:01 2000 GMT
         Not After : Jun  2 22:42:34 2001 GMT
       Subject: C=us, ST=ga, L=atlanta, O=Equifax, OU=Rick, CN=
       Subject Public Key Info:
         Public Key Algorithm: rsaEncryption
         RSA Public Key: (1024 bit)
             Modulus (1024 bit):
             Exponent: 65537 (0x10001)
       X509v3 extensions:
         X509v3 Key Usage: critical
            Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
         Netscape Cert Type:
            SSL Server
         X509v3 Authority Key Identifier:
     Signature Algorithm: md5WithRSAEncryption

  4.2.3.  Private Key File

  Proc-Type: 4,ENCRYPTED
  DEK-Info: DES-EDE3-CBC,124F61450D85A480


  4.2.4.  Contents of the Private Key

  read RSA key
  Enter PEM pass phrase:
  Private-Key: (1024 bit)
  publicExponent: 65537 (0x10001)

  4.3.  Restart the Web Server

  The script to restart the webserver may be located in /usr/local/sbin,
  /usr/sbin, (where the script is called httpd) or /usr/local/apache/bin
  (where the script is called apachectl).  If you are not running the
  server with SSL enabled, you will need to stop and start the server.
  You may also write your own customized scripts to start, restart, and
  stop your server.  As long as it starts the SSL engine, you should be

  The commands are:

       httpd stop
       httpd startssl
       httpd restart


       apachectl stop
       apachectl startssl
       apachectl restart

  5.  Troubleshooting

  Here are some common problems that may arise.

  5.1.  Server Appears to start, but you cannot access the secure site

  Check the error_log file.  If you did not set your virtual host to
  write to an error log, you may want to reconsider.  The example SSL
  virtual host writes to an error log file.  Most likely you will have a
  few warnings and an error at the end of the log that basically say
  that the private key does not match the certificate.


       [Tue Nov 21 09:09:02 2000] [notice] Apache/1.3.14 (Unix) mod_ssl/2.7.1
       OpenSSL/0.9.6 configured -- resuming normal operations
       [Tue Nov 21 09:09:16 2000] [notice] caught SIGTERM, shutting down
       [Tue Nov 21 14:39:54 2000] [notice] Apache/1.3.14 (Unix) mod_ssl/2.7.1
       OpenSSL/0.9.6 configured -- resuming normal operations
       [Tue Nov 21 14:40:31 2000] [notice] caught SIGTERM, shutting down
       [Tue Nov 21 14:43:53 2000] [error] mod_ssl: Init: (
       Unable to configure RSA server private key (OpenSSL library error follows)
       [Tue Nov 21 14:43:53 2000] [error] OpenSSL: error:0B080074:x509 certificate
       routines:X509_check_private_key:key values mismatch

  If you get the error messages above, chances are the key and
  certificate do not match.  Make sure you aren't using the default
  server.key file.  You should also check the httpd.conf file to make
  sure that the directives are pointing to the correct private key and

  You can check to make sure that you your private key and certificate
  are in the correct format and match each other.  To do this, give the
  commands below to decrypt the private key in one terminal window and
  decrypt the certificate in the other.  What you will be comparing are
  the Modulus and the Exponent of each key.  If the modulus and exponent
  from the key matches the set from the certificate, you have just
  confirmed that your certificate and key are correctly paired.

  If all else fails, create a new private key, CSR or self-signed
  certificate.  Before you do this, check your CA's re-issue policy.
  You may be charged for a re-issue.

  To view the contents of the certificate:

       openssl x509 -noout -text -in filename.crt

  To view the contents of the private key:

       openssl rsa -noout -text -in filename.key

  5.2.  Certificate Name Check Warning is issued by the client's browser

  The most common cause for this is omitting the "www" at the beginning
  of the domain name when creating the CSR.  The name defined by the
  "ServerName" directive for that virtual host must match the domain
  name presented by the certificate exactly or the browser will let the
  client know.  The exception is a wild card certificate.  A wild card
  certificate's domain name field would look like *
  This enables you to use one certificate for any number of sub-domains
  of (e.g. and

  5.3.  is issued by the client's browser Certificate was Signed by an
  Untrusted Certificate Authority Warning

  If you are using a self-signed certificate, you will get this warning.
  Your clients will be given the option to trust your certificate or
  not.  If you have a CA signed certificate and are getting the
  untrusted warning, you probably need to install their intermediate
  (root) certificate.

  5.4.  SSLEngine on is an un-recognized command (when starting Apache)

  This error message is issued if you do not have ModSSL compiled with
  Apache.  Some SSL packages use a different directive to start SSL
  within a virtual host.  If you are using a package that does use a
  different directive, you will also receive this error message.

  5.5.  how to reset it You have forgotten your "PEM Passphrase" and you
  would like to know

  There is no way to reset this passphrase.  The only solution is to
  remember the passphrase or create a new private key.  You will then
  need to obtain a new certificate or create a new self-signed

  6.  Glossary

        The positive identification of a network entity such as a
        server, a client, or a user.  In SSL context, authentication
        represents the server and client Certificate verification

     Access Control
        The restriction of access to network realms.  In Apache context
        usually the restriction of access to certain URLs.

        An unambiguous formula or set of rules for solving a problem in
        a finite number of steps.  Algorithms for encryption are usually
        called Ciphers.

        A data record used for authenticating network entities such as a
        server or a client. A certificate contains X.509 information
        pieces about its owner (called the subject) and the signing
        Certificate Authority (called the issuer), plus the owner's
        public key and the signature made by the CA.  Network entities
        verify these signatures using CA certificates.

     Certificate Authority (CA)
        A trusted third party whose purpose is to sign certificates for
        network entities that it has authenticated using secure means.
        Other network entities can check the signature to verify that a
        CA has authenticated the bearer of a certificate.

     Certificate Signing Request (CSR)
        An unsigned certificate for submission to a Certification
        Authority, which signs it with the Private Key of their CA
        Certificate. Once the CSR is signed, it becomes a real
        certificate.  Cipher An algorithm or system for data encryption.
        Examples are DES, IDEA, RC4, etc.

        The result after a Plaintext passed a Cipher.
     Configuration Directive
        A configuration command that controls one or more aspects of a
        program's behavior. In Apache context these are all the command
        names in the first column of the configuration files.

     Cryptography - Symmetric
        The client and server use the same key to encrypt and to decrypt

     Cryptography - Asymmetric
        Consists of a key pair (public and private).  PKI is Asymmetric

     Digital Signatures
        A piece of data that is sent with an encrypted message that
        identifies the originator and verifies that it has not been

        The HyperText Transport Protocol (Secure), the standard
        encrypted communication mechanism on the World Wide Web. This is
        actually just HTTP over SSL.

     Message Digest
        A hash of a message, which can be used to verify that the
        contents of the message have not been altered in transit.

        A service that provides proof of the integrity and origin of
        data, both in an non-forgeable relationship, which can be
        verified by any third party at any time, or, an authentication
        that with high assurance can be asserted to be genuine.

        A property achieved through cryptographic methods which prevents
        an individual or entity from denying having performed a
        particular action related to data (such as mechanisms for non-
        rejection or authority (origin); for proof of obligation,
        intent, or commitment, or for proof of ownership).

        The Open Source toolkit for SSL/TLS; see

     Pass Phrase
        The word or phrase that protects private key files. It prevents
        unauthorized users from encrypting them. Usually it's just the
        secret encryption/decryption key used for Ciphers.

        The unencrypted text.

     Private Key
        The secret key in a Public Key Cryptography system, used to
        decrypt incoming messages and sign outgoing ones.

     Public Key
        The publicly available key in a Public Key Cryptography system,
        used to encrypt messages bound for its owner and to decrypt
        signatures made by its owner.

     Public Key Cryptography
        The study and application of asymmetric encryption systems,
        which use one key for encryption and another for decryption. A
        corresponding pair of such keys constitutes a key pair. Also
        called Asymmetric Cryptography.

     Secure Sockets Layer (SSL)
        A protocol created by Netscape Communications Corporation for
        general communication authentication and encryption over TCP/IP
        networks. The most popular usage is HTTPS, i.e. the HyperText
        Transfer Protocol (HTTP) over SSL.

        The context information of an SSL communication.

        The original SSL/TLS implementation library developed by Eric A.
        Young <>; see

     Symmetric Cryptography
        The study and application of Ciphers that use a single secret
        key for both encryption and decryption operations.

     Transport Layer Security (TLS)
        The successor protocol to SSL, created by the Internet
        Engineering Task Force (IETF) for general communication
        authentication and encryption over TCP/IP networks. TLS version
        1 and is nearly identical with SSL version 3.

     Uniform Resource Locator (URL)
        The formal identifier to locate various resources on the World
        Wide Web. The most popular URL scheme is http. SSL uses the
        scheme https

        An authentication certificate scheme recommended by the
        International Telecommunication Union (ITU-T) and used for
        SSL/TLS authentication.

        Recommendation X.509 [CCI88c] specifies the authentication
        service for X.500 directories, as well as the X.509 certificate
        syntax.  Directory authentication in X.509 can be carried out
        using either secret-key techniques or public-key techniques; the
        latter is based on public-key certificates. The standard does
        not specify a particular cryptographic algorithm, although an
        informative annex of the standard describes the RSA algorithm.

  All copyrights belong to their respective owners. Other site content (c) 2014, GNU.WIKI. Please report any site errors to