1260 lines
46 KiB
Plaintext
1260 lines
46 KiB
Plaintext
|
Building a Secure RedHat Apache Server HOWTO
|
|||
|
Richard Sigle, Richard.sigle@equifax.com
|
|||
|
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
|
|||
|
(richard.sigle@equifax.com).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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:
|
|||
|
|
|||
|
<20> Send your derivative work (in the most suitable format such as
|
|||
|
sgml) to the LDP <http://www.LinuxDoc.org/> (Linux Documentation
|
|||
|
Project) or the like for posting on the Internet. If not the LDP,
|
|||
|
then let the LDP know where it is available.
|
|||
|
|
|||
|
<20> License the derivative work with this same license or use GPL.
|
|||
|
Include a copyright notice and at least a pointer to the license
|
|||
|
used.
|
|||
|
|
|||
|
<20> 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
|
|||
|
maintainer.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
Privacy
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
Authenticity
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
integrity
|
|||
|
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
|
|||
|
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:
|
|||
|
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> Allow the client and server to select the cryptographic algorithms,
|
|||
|
or ciphers, that they both support.
|
|||
|
|
|||
|
<20> Optionally authenticate the client to the server.
|
|||
|
|
|||
|
<20> Use public-key encryption techniques to generate shared secrets.
|
|||
|
|
|||
|
<20> 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:
|
|||
|
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> 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)
|
|||
|
|
|||
|
|
|||
|
<20> 40-bit, originally used only for export purposes
|
|||
|
|
|||
|
<20> 56-bit, used by DES
|
|||
|
|
|||
|
<20> 64-bit key - used by CAST, 256 times stronger than 56-bit
|
|||
|
|
|||
|
<20> 80-bit key - used by CAST, 16 million times stronger than 56-bit
|
|||
|
(infeasible to break with current technology)
|
|||
|
|
|||
|
<20> 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)
|
|||
|
|
|||
|
|
|||
|
<20> 512-bit
|
|||
|
|
|||
|
<20> 768-bit
|
|||
|
|
|||
|
<20> 1024-bit
|
|||
|
|
|||
|
<20> 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
|
|||
|
authority.
|
|||
|
|
|||
|
|
|||
|
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:
|
|||
|
|
|||
|
<20> Version
|
|||
|
|
|||
|
<20> serial number
|
|||
|
|
|||
|
<20> signature algorithm ID
|
|||
|
|
|||
|
<20> issuer name
|
|||
|
|
|||
|
<20> validity period
|
|||
|
|
|||
|
<20> subject (user) name
|
|||
|
|
|||
|
<20> subject public key information
|
|||
|
|
|||
|
<20> issuer unique identifier (version 2 and 3 only)
|
|||
|
|
|||
|
<20> subject unique identifier (version 2 and 3 only)
|
|||
|
|
|||
|
<20> extensions (version 3 only)
|
|||
|
|
|||
|
<20> 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
|
|||
|
command:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
openssl -in filename.key -des3 -out newfilename.key
|
|||
|
|
|||
|
|
|||
|
|
|||
|
To remove a password from an existing private key, use the following
|
|||
|
command:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
proceed.
|
|||
|
|
|||
|
|
|||
|
For more information on the OpenSSL toolkit check out: OpenSSL Website
|
|||
|
<http://www.openssl.org/>.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
<20> 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> 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
|
|||
|
entries.
|
|||
|
|
|||
|
<20> Send the CSR to the CA per their instructions.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> If there is an intermediate (root) certificate to be installed,
|
|||
|
copy it to the /etc/httpd/conf/ssl.crt directory, also.
|
|||
|
|
|||
|
<20> 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
|
|||
|
server.
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
<20> Site using default port - www.something.com - would be accessed as
|
|||
|
https://www.something.com
|
|||
|
|
|||
|
<20> A site using port 8888 would be accessed as
|
|||
|
https://www.something.com:8888
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
problem.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<VirtualHost 172.18.116.42:443>
|
|||
|
DocumentRoot /etc/httpd/htdocs
|
|||
|
ServerName www.somewhere.com
|
|||
|
ServerAdmin someone@somewhere.com
|
|||
|
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
|
|||
|
</Files>
|
|||
|
<Directory "/etc/httpd/cgi-bin">
|
|||
|
SSLOptions +StdEnvVars
|
|||
|
</Directory>
|
|||
|
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"
|
|||
|
</VirtualHost>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
directory.
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
unlikely.
|
|||
|
|
|||
|
|
|||
|
4.2. Certificate Examples
|
|||
|
|
|||
|
4.2.1. Server Certificate File
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-----BEGIN CERTIFICATE-----
|
|||
|
MIIC8DCCAlmgAwIBAgIBEDANBgkqhkiG9w0BAQQFADCBxDELMAkGA1UEBhMCWkEx
|
|||
|
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
|
|||
|
VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
|
|||
|
biBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEm
|
|||
|
MCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wHhcNOTkwNTI1
|
|||
|
MDMwMDAwWhcNMDIwNjEwMDMwMDAwWjBTMQswCQYDVQQGEwJVUzEbMBkGA1UEChMS
|
|||
|
RXF1aWZheCBTZWN1cmUgSW5jMScwJQYDVQQDEx5FcXVpZmF4IFNlY3VyZSBFLUJ1
|
|||
|
c2luZXNzIENBLTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMYna8GjS9mG
|
|||
|
q4Cb8L0VwDBMZ+ztPI05urQb8F0t1Dp4I3gOFUs2WZJJv9Y1zCFwQbQbfJuBuXmZ
|
|||
|
QKIZJOw3jwPbfcvoTyqQhM0Yyb1YzgM2ghuv8Zz/+LYrjBo2yrmf86zvMhDVOD7z
|
|||
|
dhDzyTxCh5F6+K6Mcmmar+ncFMmIum2bAgMBAAGjYjBgMBIGA1UdEwEB/wQIMAYB
|
|||
|
Af8CAQAwSgYDVR0lBEMwQQYIKwYBBQUHAwEGCCsGAQUFBwMDBgorBgEEAYI3CgMD
|
|||
|
BglghkgBhvhCBAEGCCsGAQUFBwMIBgorBgEEAYI3CgMCMA0GCSqGSIb3DQEBBAUA
|
|||
|
A4GBALIfbC0RQ9g4Zxf/Y8IA2jWm8Tt+jvFWPt5wT3n5k0orRAvbmTROVPHGSLw7
|
|||
|
oMNeapH1eRG5yn+erwqYazcoFXJ6AsIC5WUjAnClsSrHBCAnEn6rDU080F38xIQ3
|
|||
|
j1FBvwMOxAq/JR5eZZcBHlSpJad88Twfd7E+0fQcqgk+nnjH
|
|||
|
-----END CERTIFICATE-----
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.2.2. Contents of the Certificate File
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Certificate:
|
|||
|
Data:
|
|||
|
Version: 3 (0x2)
|
|||
|
Serial Number: 1516 (0x5ec)
|
|||
|
Signature Algorithm: md5WithRSAEncryption
|
|||
|
Issuer: C=US, O=Equifax Secure Inc, CN=Equifax Secure E-Business CA
|
|||
|
Validity
|
|||
|
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=172.18.116.44/Email=richard.sigle@equifax.com
|
|||
|
Subject Public Key Info:
|
|||
|
Public Key Algorithm: rsaEncryption
|
|||
|
RSA Public Key: (1024 bit)
|
|||
|
Modulus (1024 bit):
|
|||
|
00:c8:eb:93:26:97:ca:00:ce:4c:e4:f3:fd:43:31:
|
|||
|
cd:53:ed:b4:8a:ad:93:84:dc:7a:48:39:b5:28:57:
|
|||
|
03:7f:a9:ac:3e:58:6a:7a:e3:52:3e:1e:52:58:a2:
|
|||
|
6f:23:ad:bb:84:d8:88:ed:6d:a5:da:08:6b:c8:6c:
|
|||
|
a5:4c:34:67:d8:46:1c:ca:20:50:b0:e8:54:7f:ca:
|
|||
|
5e:ef:09:ff:6e:8d:a6:2b:02:f5:54:0f:c2:d0:45:
|
|||
|
12:ad:66:e7:8b:dd:68:be:64:a4:9b:69:bd:a4:1a:
|
|||
|
5e:ef:09:ff:6e:8d:a6:2b:02:f5:54:0f:c2:d0:45:
|
|||
|
12:ad:66:e7:8b:dd:68:be:64:a4:9b:69:bd:a4:1a:
|
|||
|
5a:2f:3b:6e:73:84:d8:d6:17:bd:12:39:34:fa:3d:
|
|||
|
d8:a9:e8:59:3c:c2:61:c5:b3
|
|||
|
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:
|
|||
|
keyid:5B:E0:A8:75:1C:78:02:47:71:AB:CE:27:32:E7:24:88:42:28:48:56
|
|||
|
Signature Algorithm: md5WithRSAEncryption
|
|||
|
87:53:74:e9:e1:a6:10:56:8c:fa:63:0e:7b:72:ff:76:4b:79:
|
|||
|
0e:49:2a:58:ed:71:7a:bf:77:61:fa:e8:74:04:37:8c:d3:6a:
|
|||
|
9a:3d:80:76:7a:c3:64:30:e7:1b:40:25:4e:2a:81:8b:e5:ac:
|
|||
|
76:a4:38:67:cc:3f:93:43:e1:1d:c3:8d:ba:ed:cc:d7:aa:a4:
|
|||
|
ab:d3:84:77:7c:8f:26:f6:dd:ba:3b:6a:99:81:e1:9e:7e:0f:
|
|||
|
ca:a6:ff:c0:c3:59:6e:dc:a6:03:23:bf:8f:24:ff:15:ad:ac:
|
|||
|
0d:85:fc:38:bf:d1:24:2d:1a:d3:72:55:12:95:5f:65:f0:60:
|
|||
|
df:b1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.2.3. Private Key File
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-----BEGIN RSA PRIVATE KEY-----
|
|||
|
Proc-Type: 4,ENCRYPTED
|
|||
|
DEK-Info: DES-EDE3-CBC,124F61450D85A480
|
|||
|
|
|||
|
ELz64SV+tFSRybsHjY9NH7CP7yDHXP6xcd9FY6MVgQykTkq2h0n7j+tmpfUPbStT
|
|||
|
6jCgm/dTYM9mpkQ3jYZBALiVD5JNJ9t1dWisxQXY/nsak8LSTN7LhUtZSfk5xSmV
|
|||
|
Zsl4gwQS20UdBzFiJ+4qDajP/pzocSdSuQvxIHq7UzNwJsW8UYxR3I1qrDgyNXKS
|
|||
|
db41BWH4QdNtE0p+pi9VndDzXktqZGHEvtrQTV+39DV/dwOdnGBpYBETljMO5X6t
|
|||
|
D42xcVs0Doa1vZ6PiMCkwFNPXsPlKHZtHwEL4I3CQdiH4E0oYh3klBzlXBY4YldN
|
|||
|
A+s4xU44FpXp5xwt9nnVPUKHPo+NpdaRK7dAcRNO3GN3+ek1ggzvEjjuWKes3RQh
|
|||
|
PlHPuF7VWo4KeaTfTIwJWfGxz4nvwlVByPJ6Z73Mn0VcDXCkVm6+h3PLlYL0FMqM
|
|||
|
baUyQPpw6bhfW71FO/IIQxz3R1EqkxW7OHv74uuYl8kjHXf3S6qRZEGUG/zOGLGr
|
|||
|
mI5s2qnU69HlBObFkc6WQq0QxMq4PiUi7HhCLMkH8+wBsNNMnb75+7lQKkEhdOeE
|
|||
|
iUMKe5kgQqfd9w8jsBH5nu+J/nCfvPdp0isQW+P3/Rrh6YMwdKnlVfNZWdGiTzpQ
|
|||
|
ngThAGq5lit4uf4zdTIYYrs+T9I5ltjj0KgCUD4VL5/7OfnR3gcphpbHXQf0E2cz
|
|||
|
Qwq7q7ppKwCf/x92pHi8oVevlV5Dx9NQbGhEOA5pooqD6S2xZBbPLzkUKWDEO2il
|
|||
|
oBZ5L1jClR5jjdF2U61w7aRrL0t6luDU/aRv/fcoYes=
|
|||
|
-----END RSA PRIVATE KEY-----
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.2.4. Contents of the Private Key
|
|||
|
|
|||
|
|
|||
|
|
|||
|
read RSA key
|
|||
|
Enter PEM pass phrase:
|
|||
|
Private-Key: (1024 bit)
|
|||
|
modulus:
|
|||
|
00:c8:eb:93:26:97:ca:00:ce:4c:e4:f3:fd:43:31:
|
|||
|
cd:53:ed:b4:8a:ad:93:84:dc:7a:48:39:b5:28:57:
|
|||
|
03:7f:a9:ac:3e:58:6a:7a:e3:52:3e:1e:52:58:a2:
|
|||
|
6f:23:ad:bb:84:d8:88:ed:6d:a5:da:08:6b:c8:6c:
|
|||
|
a5:4c:34:67:d8:46:1c:ca:20:50:b0:e8:54:7f:ca:
|
|||
|
5e:ef:09:ff:6e:8d:a6:2b:02:f5:54:0f:c2:d0:45:
|
|||
|
12:ad:66:e7:8b:dd:68:be:64:a4:9b:69:bd:a4:1a:
|
|||
|
5a:2f:3b:6e:73:84:d8:d6:17:bd:12:39:34:fa:3d:
|
|||
|
d8:a9:e8:59:3c:c2:61:c5:b3
|
|||
|
publicExponent: 65537 (0x10001)
|
|||
|
privateExponent:
|
|||
|
00:b6:57:7d:3b:58:24:1e:a9:1b:85:e9:9c:9e:5f:
|
|||
|
d3:3d:69:0c:21:93:37:bf:2b:2c:da:e1:6c:74:48:
|
|||
|
cb:c7:0f:60:5f:50:74:8a:44:45:be:54:5c:5d:4e:
|
|||
|
45:58:f6:f1:a8:b5:af:46:f2:ec:c2:bc:43:bd:28:
|
|||
|
44:b7:ad:13:d3:ca:de:59:24:e8:fa:f8:e5:5f:45:
|
|||
|
38:2c:a0:a3:de:98:13:d8:80:38:e1:47:53:4c:ea:
|
|||
|
e4:66:c3:82:93:89:c3:90:83:44:e1:13:4f:74:76:
|
|||
|
e2:c0:89:97:77:5f:33:d8:7d:27:21:52:55:c2:d7:
|
|||
|
dc:01:f9:bc:21:8d:a3:f5:c1
|
|||
|
prime1:
|
|||
|
00:e3:2d:6b:5e:05:6b:e1:46:e6:ab:ae:f3:8b:d0:
|
|||
|
5f:94:5c:6f:f5:47:46:1d:4e:66:d3:7e:98:18:e0:
|
|||
|
2c:0d:08:ca:b7:29:72:af:53:62:30:ec:be:26:1f:
|
|||
|
cc:5a:ed:65:62:65:70:1e:18:19:61:e3:77:00:a7:
|
|||
|
3a:9e:4e:12:93
|
|||
|
prime2:
|
|||
|
00:e2:69:56:78:e8:39:ff:17:db:cc:39:d7:7f:70:
|
|||
|
41:dc:c5:59:43:16:c1:84:4c:ae:e7:5d:8a:c5:4b:
|
|||
|
da:88:8e:03:99:7c:88:f2:8a:13:31:57:44:e0:b5:
|
|||
|
c8:0a:60:b0:05:de:f6:9e:f2:00:ec:37:21:8d:3b:
|
|||
|
dc:8e:c9:d4:61
|
|||
|
exponent1:
|
|||
|
1a:ad:6a:be:4f:c4:ab:5f:b8:16:d1:24:a8:76:7f:
|
|||
|
c2:dc:58:09:65:a5:46:2b:be:c7:77:46:45:25:8e:
|
|||
|
06:b9:d1:94:50:b9:b6:fd:03:ba:db:12:39:47:e2:
|
|||
|
a7:8a:d9:2d:04:dc:75:ac:3e:ce:cf:f7:59:8c:49:
|
|||
|
c5:ed:45:21
|
|||
|
exponent2:
|
|||
|
2d:4e:fd:32:06:ef:0c:40:7f:08:d8:8e:6a:7f:51:
|
|||
|
7e:d7:b3:6c:3c:92:8f:62:35:22:31:d3:02:76:92:
|
|||
|
8d:ff:35:73:32:bb:c9:25:9e:7f:a2:42:33:61:cd:
|
|||
|
5d:5e:49:fb:72:ca:11:b6:c6:3e:7f:2d:e4:b0:95:
|
|||
|
0b:b2:12:21
|
|||
|
coefficient:
|
|||
|
50:52:09:22:cb:fb:b2:b8:58:85:ab:1d:82:b9:6e:
|
|||
|
d0:f6:dc:e8:ce:a6:5d:a1:ff:c8:4d:3b:2b:1c:19:
|
|||
|
64:f0:c4:4a:bc:b2:1d:2b:2d:09:59:83:a3:9a:89:
|
|||
|
f8:db:2c:2c:8a:bd:fd:a3:16:51:76:aa:ce:ea:85:
|
|||
|
6b:1c:9f:f7
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
OK.
|
|||
|
|
|||
|
|
|||
|
The commands are:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
httpd stop
|
|||
|
httpd startssl
|
|||
|
httpd restart
|
|||
|
|
|||
|
|
|||
|
|
|||
|
or
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[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: (esi.fin.equifax.com:443)
|
|||
|
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
|
|||
|
certificate.
|
|||
|
|
|||
|
|
|||
|
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 *.somedomain.com.
|
|||
|
This enables you to use one certificate for any number of sub-domains
|
|||
|
of somedomain.com (e.g. host1.somedomain.com and
|
|||
|
host2.somedomain.com).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
certificate.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
6. Glossary
|
|||
|
|
|||
|
|
|||
|
Authentication
|
|||
|
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
|
|||
|
process.
|
|||
|
|
|||
|
|
|||
|
Access Control
|
|||
|
The restriction of access to network realms. In Apache context
|
|||
|
usually the restriction of access to certain URLs.
|
|||
|
|
|||
|
|
|||
|
Algorithm
|
|||
|
An unambiguous formula or set of rules for solving a problem in
|
|||
|
a finite number of steps. Algorithms for encryption are usually
|
|||
|
called Ciphers.
|
|||
|
|
|||
|
|
|||
|
Certificate
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
Ciphertext
|
|||
|
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
|
|||
|
data.
|
|||
|
|
|||
|
|
|||
|
Cryptography - Asymmetric
|
|||
|
Consists of a key pair (public and private). PKI is Asymmetric
|
|||
|
Cryptography
|
|||
|
|
|||
|
|
|||
|
Digital Signatures
|
|||
|
A piece of data that is sent with an encrypted message that
|
|||
|
identifies the originator and verifies that it has not been
|
|||
|
altered.
|
|||
|
|
|||
|
|
|||
|
HTTPS
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
Non-repudiation
|
|||
|
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).
|
|||
|
|
|||
|
|
|||
|
OpenSSL
|
|||
|
The Open Source toolkit for SSL/TLS; see http://www.openssl.org/
|
|||
|
<http://www.openssl.org/>
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
Plaintext
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
Session
|
|||
|
The context information of an SSL communication.
|
|||
|
|
|||
|
|
|||
|
SSLeay
|
|||
|
The original SSL/TLS implementation library developed by Eric A.
|
|||
|
Young <eay@aus.rsa.com>; see http://www.ssleay.org/
|
|||
|
<http://www.ssleay.org/>
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
X.509
|
|||
|
An authentication certificate scheme recommended by the
|
|||
|
International Telecommunication Union (ITU-T) and used for
|
|||
|
SSL/TLS authentication.
|
|||
|
|
|||
|
|
|||
|
ITU-T
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|