Differences between current version and revision by previous author of HowToSSLRedHatHOWTO.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
Newer page: | version 3 | Last edited on Sunday, October 31, 2004 1:35:16 am | by AristotlePagaltzis | |
Older page: | version 2 | Last edited on Friday, June 7, 2002 1:07:28 am | by perry | Revert |
@@ -1,1796 +1 @@
-
-
-
-Building a Secure !RedHat Apache Server HOWTO
-
-
-
-----
-
-!!!Building a Secure !RedHat Apache Server HOWTO
-
-!!Richard Sigle, Richard.sigle@equifax.com0.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.''
-----
-
-
-
-
-!!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.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.2 Certificate Examples
-
-*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
-
-*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
-
-
-
-
-
-!!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:
-
-
-*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 used.
-*
-
-*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:
-
-
-
-
-
-*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.
-*
-
-
-
-
-
-
-
-
-!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.
-
-
-
-
-
-
-
-!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
-*
-
-
-
-
-
-
-
-
-!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 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:
-
-
-*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 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.
-
-
-
-
-
-
-
-!!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 entries.
-*
-
-*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 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:
-
-
-*Site using default port - www.something.com - would be accessed
-as https://www.something.com
-*
-
-*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.
-
-
-
-
-!SSL Engine
-
-
-"SSLEngine on" - this is ModSSL's command to start SSL.
-
-
-
-
-!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.
-
-
-
-
-!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.
-
-
-
-
-!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
-
-
-!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-----
-
-
-
-
-
-
-
-
-
-!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
-
-
-
-
-
-
-
-
-
-!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-----
-
-
-
-
-
-
-
-
-
-!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/.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/.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 Certificate was Signed by an Untrusted Certificate Authority Warning
-is issued by the client's browser
-
-
-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 You have forgotten your "PEM Passphrase" and you would like to know
-how to reset it
-
-
-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/
-
-
-; __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/
-
-
-; __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.
-
-
-
-
-----
+Describe
[HowToSSLRedHatHOWTO
] here.