Sunday, 20 April 2014

Apache SSL Key Creation and Configuration


The SSL authentication process uses certificates that are issued by a certificate authority. The same process applies if the certificates are issued by an certificate generation utility or if self-signed certificates are used.
Figure 1 illustrates the steps that authenticate the identity of an application:


Figure 1. Authenticating the identity of an application
To establish an SSL connection:
  • An application acting as an SSL client contacts an application acting as an SSL server.
  • The SSL server responds by sending the signed certificate stored in its keystore to the SSL client. A CA certificate contains identifying information about the CA that issued the certificate and the application (owner) that presents the certificate, a public key, and the digital signature of the CA.
  • The SSL client uses the corresponding CA certificate stored in its keystore to verify the digital signature on the certificate.
  • In addition to verifying the signature on the certificate, the SSL client requests the SSL server to prove its identity.
  • The SSL server uses its private key to encrypt a message.
  • The SSL server sends the encrypted message to the SSL client.
  • To decrypt the message, the SSL client uses the public key embedded in the signed certificate it received, and thereby verifies the identity of the owner of the certificate.
If the SSL server is set to use two-way SSL authentication (client authentication), it then asks the SSL client to verify and prove its identity, and the same process described above is used to verify the identity of the SSL client to the SSL server.
  • One-way SSL authentication
    One-way SSL authentication enables the application operating as the SSL client to verify the identity of the application operating as the SSL server.
One-way SSL authentication
One-way SSL authentication enables the application operating as the SSL client to verify the identity of the application operating as the SSL server.
The SSL-client application is not verified by the SSL-server application. Figure 1 illustrates the certificate configuration for one-way SSL authentication between two applications in the Tivoli Identity Manager Express environment:
Figure 1. One-way SSL authentication
For example, if the Tivoli Identity Manager Express Server initiates contact with a Tivoli Identity Manager adapter, the adapter operates as the SSL server and presents a signed certificate to the Tivoli Identity Manager Express Server, which acts as the SSL client. The Tivoli Identity Manager Express Server verifies the identity of the adapter and the authentication is complete. In this example, you must install a certificate and private key on the adapter and install the corresponding CA certificate on the Tivoli Identity Manager Express Server. The server authentication is the most commonly used SSL configuration.
  • Two-way SSL authentication
    In two-way SSL authentication, the SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSL-client application.
Two-way SSL authentication
In two-way SSL authentication, the SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSL-client application.
Two-way SSL authentication is also referred to as client authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client.
Figure 1 illustrates the certificate configuration for two-way SSL authentication between two applications in the Tivoli Identity Manager Express environment:
Figure 1. Two-way SSL authentication
For example, if the Tivoli Identity Manager Express Server initiates a connection to a Tivoli Identity Manager adapter and the adapter is set to use two-way SSL client authentication, the adapter presents its certificate to the Tivoli Identity Manager Express Server for verification, and then requests that the Tivoli Identity Manager Express Server send its certificate to the adapter for verification. In this case, you must install the Tivoli Identity Manager Express Server certificate and private key in its keystore, and you must install the corresponding CA certificate in the keystore of the Tivoli Identity Manager adapter. On the Tivoli Identity Manager adapter, you must install the adapter certificate and private key in its keystore, and you must install the corresponding CA certificate in the keystore of the Tivoli Identity Manager Express Server. If the same certificate authority issues both signed certificates, you can install the same CA certificate in the keystores of both applications. Two-way SSL authentication with signed certificates that are issued by one or more certificate authorities ensure maximum security of sensitive data.
If you are using self-signed certificates, you must create and install the self-signed certificate and private key on the SSL-client and SSL-server applications, then extract the certificate from the keystore of each application and add it to the keystore of the other application. Figure 2 illustrates the certificate configuration for two-way SSL authentication using self-signed certificates.
Figure 2. Self-signed two-way SSL authentication






How To Generate SSL Key, CSR and Self Signed Certificate For Apache

If you want to convert your website from HTTP to HTTPS, you need to get a SSL certificate from a valid organization like Verisign or Thawte. You can also generate self signed SSL certificate for testing purpose.

In this article, let us review how to generate private key file (server.key), certificate signing request file (server.csr) and webserver certificate file (server.crt) that can be used on Apache server with mod_ssl.
Key, CSR and CRT File Naming Convention
I typically like to name the files with the domain name of the HTTPS URL that will be using this certificate. This makes it easier to identify and maintain.
  • Instead of server.key, I use www.thegeekstuff.com.key
  • Instead of server.csr, I use www.thegeekstuff.com.csr
  • Instead of server.crt, I use www.thegeekstuff.com.crt
1. Generate Private Key on the Server Running Apache + mod_ssl
First, generate a private key on the Linux server that runs Apache webserver using openssl command as shown below.
# openssl genrsa -des3 -out www.thegeekstuff.com.key 1024
Generating RSA private key, 1024 bit long modulus
.......................................++++++
...................................................++++++
e is 73547 (0x01001)
Enter pass phrase for www.thegeekstuff.com.key:
Verifying - Enter pass phrase for www.thegeekstuff.com.key:

-rw-r--r-- 1 root root 963 Jun 13 20:26 www.thegeekstuff.com.key
The generated private key looks like the following.
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,485B3C6371C9916E

ymehJu/RowzrclMcixAyxdbfzQphfUAk9oK9kK2
jadfoiyqthakLKNqw9z1MoaqkPyqeHevUm26no
AJKIETHKJADFS2BGb0n61/Ksk8isp7evLM4+QY
KAQETKjdiahteksMJOjXLq+vf5Ra299fZPON7yr
-----END RSA PRIVATE KEY-----
2. Generate a Certificate Signing Request (CSR)
Using the key generate above, you should generate a certificate request file (csr) using openssl as shown below.
# openssl req -new -key www.thegeekstuff.com.key -out www.thegeekstuff.com.csr
Enter pass phrase for www.thegeekstuff.com.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:California
Locality Name (eg, city) [Newbury]:Los Angeles
Organization Name (eg, company) [My Company Ltd]:The Geek Stuff
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server's hostname) []: thegeekstuff
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

-rw-r--r-- 1 root root 963 Jun 13 20:26 www.thegeekstuff.com.key
-rw-r--r-- 1 root root 664 Jun 13 20:35 www.thegeekstuff.com.csr
3. Generate a Self-Signed SSL Certificate
For testing purpose, you can generate a self-signed SSL certificate that is valid for 1 year using openssl command as shown below.
# openssl x509 -req -days 365 -in www.thegeekstuff.com.csr -signkey www.thegeekstuff.com.key -out www.thegeekstuff.com.crt
Signature ok
subject=/C=US/ST=California/L=Los Angeles/O=thegeekstuff/OU=IT/CN=www.thegeekstuff.com
Getting Private key
Enter pass phrase for www.thegeekstuff.com.key:

-rw-r--r-- 1 root root 963 Jun 13 20:26 www.thegeekstuff.com.key
-rw-r--r-- 1 root root 664 Jun 13 20:35 www.thegeekstuff.com.csr
-rw-r--r-- 1 root root 879 Jun 13 20:43 www.thegeekstuff.com.crt

-----BEGIN CERTIFICATE-----
haidfshoaihsdfAKDJFAISHTEIHkjasdjadf9w0BAQUFADCB
kjadfijadfhWQIOUQERUNcMNasdkjfakljasdBgEFBQcDAQ
kjdghkjhfortoieriqqeurNZXCVMNCMN.MCNaGF3dGUuY29
-----END CERTIFICATE-----

You can use this method to generate Apache SSL Key, CSR and CRT file in most of the Linux, Unix systems including Ubuntu, Debian, CentOS, Fedora and Red Hat.
4. Get a Valid Trial SSL Certificate (Optional)
Instead of signing it youself, you can also generate a valid trial SSL certificate from thawte. i.e Before spending the money on purchasing a certificate, you can also get a valid fully functional 21 day trial SSL certificates from Thawte. Once this valid certificate works, you can either decide to purchase it from Thawte or any other SSL signing organization.

This step is optional and not really required. For testing purpose, you can always use the self-signed certificate that was generated from the above step.

Go to Thwate trial certificate request page and do the following:
  • Select “SSL Web Server Certificate (All servers)” under the “select your trial certificate”.
  • Do not check the PKCS #7 check-box under the “configure certificate”
  • Copy/Paste the *.csr file that you generate above in the textbox under “certificate signing request (CSR)”
  • Click on next at the bottom, which will give you a 21-day free trial certificate.

Copy/Paste the trial certificate to the www.thegeekstuff.com.crt file as shown below.
-----BEGIN CERTIFICATE-----
haidfshoaihsdfAKDJFAISHTEIHkjasdjadf9w0BAQUFADCB
kjadfijadfhWQIOUQERUNcMNasdkjfakljasdBgEFBQcDAQ
kjdghkjhfortoieriqqeurNZXCVMNCMN.MCNaGF3dGUuY29
-----END CERTIFICATE-----
Installing your SSL Certificate
Copy the files in into the default locale
When you receive your SSL certificate from your authority, upload it to your server and place it in ~/domain.com.ssl/domain.com.crt
  • Copy the certificate, key, and csr into the Apache server directory in which you plan to store your certificates (by default: /usr/local/apache/conf/ssl.crt/ or /etc/httpd/conf/ssl.crt/).
Note: Copy the entire contents of the certificate from (and including) the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.
Edit the httpd.conf
Open the Apache httpd.conf file in a text editor(I prefer VIM, the true editor).
Create the following Virtual Host:
<VirtualHost 123.45.67.89:443>
ServerName www.domain.com
DocumentRoot /path/to/your/document/root/htdocs

SSLEngine ON
SSLCertificateFile /etc/httpd/conf/ssl.crt/domain.com.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/domain.com.key

ErrorLog logs/ssl.domain.com.error_log
CustomLog logs/ssl.domain.com.access_log combined
</VirtualHost>
  • keep in mind that the paths to the certificate files will need to be changed to where ever you choose to place your certificate.
Save the changes and exit the editor

# /etc/init.d/httpd restart
or
# /etc/init.d/apache2 restart


CentOS / Redhat Apache mod_ssl Configuration
The mod_ssl module provides strong cryptography for the Apache Web server via the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. How do I install and configure mod_ssl under CentOS / Fedora / Redhat Enterprise Linux?
mod_ssl is the SSL/TLS module for the Apache HTTP server. You can use self signed certificate or 3rd party SSL certificate. This module provides SSL v2/v3 and TLS v1 support for the Apache HTTP Server. It was contributed by Ralf S. Engeschall based on his mod_ssl project and originally derived from work by Ben Laurie. This module relies on OpenSSL to provide the cryptography engine.

Step #1: Install mod_ssl
Type the following command as the root user to install mod_ssl, enter:# yum install mod ssl
Step #2: Create an SSL Certificate
Type the following commands:# cd /etc/pki/tls/certs
# openssl genrsa -des3 -out apachekey.pem 2048
Sample outputs:
Generating RSA private key, 2048 bit long modulus
..................+++
...................................+++
e is 65537 (0x10001)
Enter pass phrase for apachekey.pem:
Verifying - Enter pass phrase for apachekey.pem:
Note enter a strong, passphrase to protect the Apache web server key pair.
Generate a Certificate Signing Request (CSR)
Type the following command:# openssl req -new -key apachekey.pem -out apachekey.csr
Sample outputs:
Enter pass phrase for apachekey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:IN
State or Province Name (full name) [Berkshire]:MH
Locality Name (eg, city) [Newbury]:Poona
Organization Name (eg, company) [My Company Ltd]:nixCraft LTD
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server's hostname) []:www.nixcraft.com
Email Address []:vivek@nixcraft.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
You need to provide the information fill or hit [Enter] key to accept defaults, but the Common Name field is very important. You must match the fullyqualified domain name of your server exactly (e.g. www.nixcraft.com) or the certificate will not work. No need to enter the challenge password.
Create the Web Server Certificate
You must signed the CSR to create the web server certificate, enter (you can send it to your CA to sign the same). To sign httpserver.csr using your CA:# openssl ca -in apachekey.csr -out apachecert.pem
Install SSL Certificate
Copy server key and certificates files /etc/pki/tls/http/, enter:# cp apachecert.pem /etc/pki/tls/http/
# cp apachekey.pem /etc/pki/tls/http/
Edit /etc/httpd/conf.d/ssl.conf, enter:# vi /etc/httpd/conf.d/ssl.conf
Listen to the the HTTPS port, enter:
Listen 10.10.29.68:443
Update it as follows to seed appropriately, enteR:
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024
Update VirtualHost as follows:

<VirtualHost www.nixcraft.com:443>
SSLEngine On
SSLCertificateFile /etc/pki/tls/http/apachecert.pem
SSLCertificateKeyFile /etc/pki/tls/http/apachekey.pem
SSLProtocol All -SSLv2
SSLCipherSuite HIGH:MEDIUM:!aNULL:+MD5
DocumentRoot "/var/www/html/ssl"
</VirtualHost>

Save and close the file. Make sure /var/www/html/ssl exits, enter:# mkdir -p /var/www/html/ssl
Edit /etc/httpd/conf/httpd.conf, enter:# vi /etc/httpd/conf/httpd.conf
Make sure SSL is used for /var/www/html/ssl and set other options for the same, enter:

<Directory /var/www/html/ssl>
SSLRequireSSL
SSLOptions +StrictRequire
SSLRequire %{HTTP_HOST} eq "www.nixcraft.com"
</Directory>

Now, you can upload ssl specific php or html pages in /var/www/html/ssl directory and can access them by visiting https://www.nixcraft.com/ url. Do not forgot to restart Apache:# service httpd restart
Firewall Configuration
Edit /etc/sysconfig/iptables. Add the following lines, ensuring that they appear before the final DROP lines:
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
Save and close the file. Restart the firewall:# service iptables restart




Step by Step: Configuring SSL Under Apache
by Juliet Kemp 
03/04/2008
Introduction
With a secure web server, clients can connect to your server secure in the knowledge both that it is who it claims to be and that the transaction is well-encrypted so their data is safe. The best way of doing this is with Apache 2, the leading Linux web server software, and Secure Sockets Layer, a secure communication protocol. Transport Layer Security (TLS) is the successor to SSL, but they work in basically the same way. I'll refer from here on just to SSL.


SSL is a protocol for cryptographically securing transactions between a web browser and a web server. In most cases, only the server end is authenticated, which means that the client has a guarantee that the server is who it claims to be, but not vice versa. However, once the connection is established, both ends are secure, as only the client and the server have access to the key material. This makes sense since for many transactions, the server doesn't care who the client is, as long as it stays the same client throughout the transaction. If you do care about client authentication, it is possible to use client SSL certificates (or htaccess, Kerberos, or other similar methods), but that won't be covered in this article.
As a client, obviously you do care that you're sending whatever private data you wish to encrypt to the person (server) you think you're sending it to. Hence the server, not the client, being authenticated. You also care about preventing a third party from accessing your data as you send it. SSL provides both of these types of security.
The SSL process works as follows:
  • Client connects to web server and gives a list of available ciphers.
  • Server picks the strongest cipher that both it and the client support, and sends back a certificate with its name and public encryption key, signed by a trusted Certificate Authority (such as Verisign).
  • The client checks the certificate with the CA. In practice, clients tend to have a collection of CAs locally, so this can be done without having to contact the CA in realtime, and therefore more quickly.
  • The client sends back a random number encrypted with the server's public key. Only the client knows the number, and only the server can decrypt it (using its private key); this is where the third-party security comes in.
  • Server and client use this random number to generate key material to use for the rest of the transaction.
We want this to be as transparent as possible on the client side, to make the transaction as easy as possible.
Setting up Apache with SSL is straightforward, but there are several necessary steps. This article covers how to get a certificate signed by a CA, and how to compile and configure Apache with SSL. I'm using Apache2 with mod_ssl. ApacheSSL (an implementation of Apache with SSL capabilities) is also available, but is now quite old; mod_ssl is a better bet.
Creating a Certificate
The first step is certificate creation. You can create your certificate either with or without a passphrase. The major disadvantage of using a passphrase is that it must be typed every time the web server starts up. So it won't start unattended or automatically on boot, for example, after a power cut. Depending on your setup, this may or may not be significant for you.
In theory, the advantage of having a passphrase is that it increases protection. However, in practice the passphrase doesn't actually give that much protection. If someone can read or copy the private key, then they already have root-level access to the system and could obtain the passphrase, for example by using a program like keylogger. A passphrase will protect against script kiddies, but not against a serious hacker. For most people it's probably not worth using one.
For testing purposes, or for small LANs, you can create a self-signed certificate. This can be done by issuing this command:
openssl req -new -x509 -days 365 -sha1 -newkey rsa:1024 \
-nodes -keyout server.key -out server.crt \
-subj '/O=Company/OU=Department/CN=www.example.com'
Let's have a look at the options in detail:
  • -x509 identifies that a certificate is required, rather than just a certificate request (see below).
  • -days 365 sets the certificate to expire in a year. You may want to extend this period. Make a note of the expiry date so that you can renew it when necessary!
  • -sha1 specifies that SHA1 encryption should be used.
  • rsa:1024 sets the key as 1024 bit RSA.
  • -nodes specifies no passphrase.
  • -keyout and -out specify where to store the certificate and key. The key should be root-readable only; the certificate can be world-readable, and must be readable by the user that Apache runs as.
  • -subj flag sets the company name, department name, and the web site address. If you leave these out, you'll be prompted for them. The CN must be the same as the address of your web site, otherwise the certificate won't match and users will receive a warning when connecting. Make sure you don't use a challenge password.
The problem with using a self-signed certificate for a real-life working web server is that any browser connecting to the site will not recognize the certificate authority. This means that the user will be asked to verify the certificate. Obviously, in most cases this is suboptimal. However, it's fine for test purposes, and on small LANs it may not be worth paying for a certificate from an external CA.
For most uses, though, and certainly for dealing with external customers, it will be better to use a certificate that's signed by a trusted Certificate Authority such as Verisign (who have the largest share of the market), or a smaller organization. Most browsers already have a number of trusted CAs preinstalled, which will verify your web server's certificate when the client connects. This minimizes the hassle to the end user, and ensures that they are certain your site is legitimate.
To get a certificate signed by a CA, you first need to create a keypair and a certificate request:
openssl req -new -sha1 -newkey rsa:1024 -nodes \
-keyout server.key -out www.example.com.csr \
-subj '/O=Company/OU=Department/CN=www.example.com'
This works much as the previous example, but this time, we don't use the -x509 switch. The command will therefore generate a key and certificate request, but not a certificate. If you fill in the CN, etc., when challenged rather than on the command line, you should not fill in an email address or a challenge password.
The server key (server.key, which again should only be readable by root) stays on your web server; the request (www.example.com.csr) goes to the CA. You can call the request file whatever you want, but calling it by your domain name will simplify life for the CA.
The next stage, then, is to send that www.example.com.csr file to the CA, with your payment. They should be able to turn it around fairly quickly, if you have provided all required information with your certificate request. Your chosen CA will explain their procedures on their webpage. You may need to change it into PEM format, but in the case of Verisign, this shouldn't be necessary.
When you get it back and have it in PEM format, rename it to server.crt (this isn't strictly necessary but fits with Apache conventions) and verify it:
openssl verify -CAfile /path/to/trusted_ca.crt -purpose sslserver server.crt
Next, check that the output of these two commands is the same, i.e., that the certificate corresponds to the private key:
openssl x509 -noout -modulus -in server.pem | openssl sha1
openssl rsa -noout -modulus -in server.key | openssl sha1
Now install your key (generated as server.key above) and certificate (server.crt), into /etc/apache2/ssl, or your preferred Apache2 config directory, if that's different. As mentioned above, it's important to make sure that the server.key is readable only by root, while the server certificate should be world-readable, but owned and writeable only by root.
Compiling Apache with SSL
So that's your certificate generated. Next you need to set up your web server to use it.
For the vast majority of people, the best way to install and manage Apache2 and its modules is via your distribution's package management system. The Debian Apache2 web server comes with the SSL module available, but it is not automatically enabled. In order to enable it you must execute: a2enmod ssl and restart the web server.
The generic way to do this is to have the line
Include /etc/apache2/mod_ssl.conf
in your /etc/apache2/apache2.conf (this file may also be called httpd.conf). You'll need to edit it to give the appropriate location for mod_ssl.conf in your setup. Then restart the web server.
If you wish to compile Apache2 from source, depending on what options you have previously used, you may or may not already have SSL support. Check with the command apache2 -l. If you do need to recompile, run ./configure with all options you previously used, and the addition of --enable-ssl and --enable-setenvif (the latter is needed for compatibility with some Internet Explorer quirks). Then install with make;make install as usual, and check that the ownership and permissions are correct.
Configuring Apache with SSL
Next, you need to configure Apache2. The following instructions assume that you wish to run both a secure server (on port 443) and a regular server (on port 80). First, you need to configure the server to listen on both ports. Either edit /etc/apache2/ports.conf(in Debian; this is included in apache2.conf) or edit /etc/apache2/apache2.conf directly to include the lines:
Listen 80
Listen 443
Next, edit /etc/apache2/sites-enabled/yoursite to use the SSL settings. Separating the regular and secure server settings out by using VirtualHosts is the easiest option in terms of maintainability. Any configuration outside the VirtualHosts sections (such as setting the ServerAdmin) will apply to both (and any other) VirtualHosts. Add the following section to your config file:
# =================================================
# SSL/TLS settings
# =================================================
NameVirtualHost *:443

<VirtualHost *:443>

DocumentRoot "/local/www/ssl_html"

SSLEngine on
SSLOptions +StrictRequire

<Directory />
SSLRequireSSL
</Directory>

SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024

SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm
SSLSessionCacheTimeout 600

SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

SSLVerifyClient none
SSLProxyEngine off

<IfModule mime.c>
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
</IfModule>

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>
A few notes on this configuration:
  • SSLEngine must be enabled so that the server uses SSL.
  • DocumentRoot sets the root directory for this virtual host. This means that you can separate secure content entirely from regular content.
  • SSLRequireSSL requires SSL to be used (on this virtual host): i.e., a user can't connect to this host using a regular HTTP request. This is why we separate out the secure and regular root directory.
  • SSLProtocol disables all protocols other than TLS v1.0 and SSL v3.0. This will be OK for current web browsers.
  • SSLCipherSuite is set to use only HIGH and MEDIUM security cipher suites. SHA1 is considered to be more secure than MD5 so is preferred.
  • SSLCertificateFile and SSLCertificateKeyFile should be set to the locations where you put your certificate and key files.
  • SSLVerifyClient should be set to none if not using client authentication.
To run the regular server on port 80, add the following section to the config file:
NameVirtualHost *:80

<VirtualHost *:80>
DocumentRoot "/local/www/html"
# Host-specific directory setup, options, etc
# Most of these options are likely to be set outside the VirtualHosts
# sections.
</VirtualHost>
After you've saved the edited configuration file, restart the web server. If you did use a passphrase when generating your certificate, you'll need to enter it when challenged.
Testing
Create a basic index.html page wherever the root directory for your web server is located, if you don't already have content there.
Then point your web browser at https://www.yoursite.com. You should see an SSL connection opened and the page delivered. If you're using a self-signed certificate, your browser will pop up an alert warning you that the server's identity cannot be verified. You can choose to view and accept the certificate. If using an external certificate, it should all happen without intervention.
Make sure as well that you can't access the protected content using http://. If you try, you should get an error message.
Troubleshooting
If it's not working as expected, first check that your server is actually running, using ps -a | grep apache. If that doesn't return anything, try restarting it, and check for error messages on the terminal.
Also check that the permissions on your key and certificate files are set correctly (see above), as well as the permissions on your test HTML file and its parent directory.
Next, check the logs. You should check both the main server logs and also the SSL logs that you set up in your config file above. If you don't get anything useful, try changing the LogLevel value in the Apache2 config file to "debug", restart Apache2, and test again. This should give more logfile data.
If you are running a regular web server on port 80 as well, try fetching a test page via http:// rather than https:// to help identify whether the problem is with the web server or with the SSL connection. Note that in the setup above, the web server's root directory is different for http:// and https://, so you won't (or shouldn't!) be able to access the same content. If your test page in the http:// root directory works fine, though, and your test page in the https:// root directory doesn't, then that can help you to pinpoint the problem.
If the problem is the SSL connection, a useful tool is s_client, which is a diagnostic tool for troubleshooting TLS/SSL connections. The basic usage is: /usr/bin/openssl s_client -connect localhost:443. There are numerous other options as well, for which you can check the documentation. If you get error messages, this should help you in locating the problem
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)