HTTPS IN APACHE SERVER

 

What Is HTTP:

 

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web. Hypertext is structured text that uses logical links (hyperlinks) between nodes containing text. HTTP is the protocol to exchange or transfer hypertext. HTTP functions as a request-response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.

 

What Is HTTPS:

 

Hypertext Transfer Protocol Secure (HTTPS) is a communications protocol for secure communication over a computer network, with especially wide deployment on the Internet. Technically, it is not a protocol in and of itself; rather, it is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the SSL/TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications. HTTPS signals the browser to use an added encryption layer of SSL/TLS to protect the traffic.

 

What Is SSL:

 

Secure Socket Layer (SSL) is a protocol that provides security for communications between client and server by implementing encrypted data and certificate-based authentication. Technically, the term “SSL” now refers to the Transport Layer Security (TLS) protocol, which is based on the original SSL specification. SSL is one of the most common ways of integrating secure communication on the internet, as it is a mature protocol that is well-supported by every major browser and a number of well-respected organizations provide third party SSL authentication services.

 

SSL use Encryption. Before transmitting any data, the sender encrypts its message, and the receiver must in turn decrypt the message before processing it. The encryption and decryption is accomplished through a method called “public key encryption”. In order for public key encryption to provide secure communication, one more more of the communicating parties must have some way of proving to the other that they are, in fact, who they claim to be. SSL provides this proof by requiring that one or more of the parties present a digital certificate into the initial negotiation of the connection, prior to the transmission of any encrypted data. This process is called “handshaking.”

 

To ensure that the certificate is a valid proof of identity, SSL contacts a trusted third party server specified in the certificate, called a Certificate Authority (CA). A Certificate Authority is a trusted company that agrees to vouch for the identity of a site, usually for a fee. Generally, the more widely the CA is known as a reputable organization, the more they will charge you per year to verify your site’s identity.

 

HTTPS IN TOMCAT :

 

When To Use SSL With Tomcat

 

The most common reason you’d need to use Tomcat to handle SSL connections would be if you are running Tomcat as a stand-alone web server.

 

In other words, if you’re fronting Tomcat with a web server and using it only as an application server or Tomcat servlet container, in most cases you should let the web server function as a proxy for all SSL requests.

 

Why? Because all that decryption, encryption, and handshaking isn’t free – actually, it’s not just “not free,” it’s quite CPU-intensive, and it significantly slows down the speed of transmission. In other words, if you’re already using a web server to serve your static content, you’re better off letting it handle all that, freeing up your Tomcat server to focus on its specialty – quickly generating dynamic content, and allowing it to get that data to your web server as quickly as possible, in cleartext.

 

Configuring Tomcat To Use SSL

 

Setting up SSL for Tomcat can be divided into two main tasks:

 

  1. creating a functional keystore, and
  2. configuring the Tomcat connectors and applications.

 

 

 

PART I – The Keystore

 

Step 1 – Creating the Keystore

 

The keys Tomcat will use for SSL transactions are stored in a password-protected file called, creatively, the “keystore.” The first step to enabling SSL on your server is to create and edit this file. You can create this file in one of two ways – by importing an existing key into the keystore, or by creating an entirely new key.

 

A program called keytool, which is included with your JDK, will do the actual work of creating your new keystore. To create a new keystore using this program, enter the following command at the command-line:

 

$JAVA_HOME/bin/keytool -genkey -alias [youralias] -keyalg RSA -keystore [/preferred/keystore/path]

 

$JAVA_HOME/bin/

 

 

Use an [alias] and [path] of your choice.

 

e.g.

 

C:\Program Files\Java\jdk1.6.0_21\bin> keytool.exe –genkey  –alias localhost  –keyalg RSA  -keystore  c:\localhostgeneratedkey

 

Next, keytool will ask you to enter the password you want to use for the keystore. Again, choose whatever you like (but don’t forget it).

 

After you choose the keystore password, you will enter the information required for the Certificate, such as your company and your name. Make sure this information is accurate, as you will have to submit this file to the Certificate Authority of your choice to obtain a certificate.

 

The last thing keytool will ask you to specify is the key password, which is the password specific to this specific certificate. Rather than enter anything at this prompt, just press ENTER.

 

This will cause keytool to set the key password to a value equivalent to the keystore password. Matching passwords are REQUIRED for Tomcat to access the certificate. If you choose two different passwords, any attempts to access the keystore will result in a crash (so don’t do it).

 

Congratulations – if you followed the directions correctly, you should now have a usable keystore file named [youralias], located in the directory you chose.

 

If you entered as given example, you should now have a usable keystore file named localhostgeneratedkey located in C:\.

 

Step 2 – Creating the Certificate Signing Request

 

Now that you’ve created your keystore, it’s time to create a file called the Certificate Signing Request, or CSR, which will be used by the Certificate Authority of your choice to generate the Certificate SSL will present to other parties during the handshake.

 

You can use the keytool to create this file, as well. To do so, enter the following at the command line:

 

 

 

$JAVA_HOME/bin/keytool -certreq -keyalg RSA -alias [youralias] -file [yourcertificatname].csr -keystore [path/to/your/keystore]

 

 

 

 e.g.

 

C:\Program Files (x86)\Java\jdk1.6.0_21\bin>keytool.exe -certreq -keyalg RSA -alias localhost -file c:\ localhostcertreq.csr  -keystore c:\ localhostgeneratedkey

 

If you follow the instructions correctly, keytool will create a file called yourcertificatename.csr, which you can submit to the CA you’ve chosen via the process they provide on their website. Using this file, they will generate a custom certificate for your server, which you can download according to the instructions they provide on their website.

 

Step 3 – Installing Your New Certificate

 

SSL verifies the authenticity of a site’s certificate by using something called a “chain of trust,” which basically means that during the handshake, SSL initiates an additional handshake with the Certificate Authority specified in your site’s certificate, to verify that you haven’t simply made up your own CA.

 

In order to “anchor” your certificate’s chain of trust, you have to download an additional certificate, called a “Root Certificate,” from your CA, and then import both this certificate and your site’s new certificate into your keystore. Your CA should provide information about obtaining a Root Certificate on their website.

 

Once you’ve downloaded both your own Certificate and the Root certificate provided by your CA, import them into your keystore with the following commands, replacing the [placeholders]:

 

 

 

keytool -import -alias root -keystore [path/to/your/keystore] -trustcacerts -file [path/to/the/root_certificate]

 

To import the Root Certificate

 

 

 

e.g.

 

C:\Program Files\Java\jdk1.6.0_21\bin>keytool.exe -import -alias root -keystore  c:\ localhostgeneratedkey  -trustcacerts -file c:\rootcert.crt

 

To import your new Certificate –

 

 

 

keytool -import -alias [youralias] -keystore [path/to/your/keystore] -file [path/to/your_keystore]

 

 

 

 

e.g.

 

C:\Program Files\Java\jdk1.6.0_21\bin>keytool.exe -import -alias localhost -file c:\sitecert.crt”

 

Do everything right? Then pat yourself on the back – you are now the proud owner of a functional, certified keystore.

 

PART II – Configuring Tomcat to use SSL

 

Now that we have a functional keystore populated with valid certificates, it’s time to configure Tomcat to use SSL. First, we’ll configure Tomcat’s SSL connectors, and then we’ll specify which webapps we want to use SSL by default.

 

Step 1 – Configuring Tomcat’s SSL Connectors

 

Tomcat’s global Connector options are configured in Tomcat’s main configuration file, “$CATALINA_BASE/conf/server.xml”, so you should open this file now. The Connectors we are looking for connect on port 8443 by default, so search for this port, until you come across an entry that looks like this:

 

<!– Define a SSL HTTP/1.1 Connector on port 8443

 

This connector uses the JSSE configuration, when using APR, the

 

connector should be using the OpenSSL style configuration

 

described in the APR documentation –>

 

<!–

 

<Connector port=”8443″ protocol=”HTTP/1.1″ SSLEnabled=”true”

 

maxThreads=”150″ scheme=”https” secure=”true”

 

clientAuth=”false” sslProtocol=”TLS”/>

 

–>

 

You’ll notice that the comment enclosing this connector talks about a choice between APR and JSSE configurations. This refers to the implementation of SSL you are intending to use. JSSE, which is Tomcat’s default configuration, is supported by default, and included in all JDKs after version 1.4. So if you don’t even know what APR is, you only need to uncomment this entry, and add some additional information to allow Tomcat to find your keystore:

 

 

 

<Connector port=”8443″ maxThreads=”150″ scheme=”https” secure=”true” SSLEnabled=”true” keystoreFile=”path/to/your/keystore” keystorePass=”YourKeystorePassword” clientAuth=”false” keyAlias=”yourAlias” sslProtocol=”TLS”/>

 

 

 

 

 

 

e.g.

 

<Connector port=”8443″ protocol=”HTTP/1.1″ SSLEnabled=”true”  maxThreads=”150″ scheme=”https” secure=”true”  clientAuth=”false”  sslProtocol=”TLS” keystoreFile=c:\ localhostgeneratedkey keystorePass=”localhost”/>

 

 

 

<Connector port=”8443″ scheme=”https” secure=”true” SSLEnabled=”true” SSLCertificateFile=”/path/to/your/certificate.crt” SSLCertificateKeyFile=”/path/to/your/keyfile” SSLPassword=”YourKeystorePassword” SSLCertificateChainFile=”path/to/your/root/certificate” keyAlias=”yourAlias” SSLProtocol=”TLSv1″/>

 

If, on the other hand, you know that using the Apache Portable Runtime (APR), also known as Tomcat’s “native library,” is by far the best practice to follow, especially when using Tomcat as a standalone web server (which you probably are), and have already installed it on your server, then you’ll need to alter this entry as follows to allow Tomcat to use APR’s OpenSSL implementation in place of JSSE, or trying to use SSL will generate an error:

 

 

 

 

 

 

Notice that if you are using APR, the “SSLCertificateFile” and “SSLCertificateKey”-type attributes are used in place of the keystoreFile attribute. For more information on the differences between using APR in place of JSSE, consult Apache’s Tomcat APR Documentation.

 

Restart Tomcat. Once you’re up and running again, test your configuration by connecting to a secure page, using a URL such as https://[yourhost]:8443. If you followed the directions correctly, you should be able to view the page over a secure HTTPS connection!

 

 

 

 

 

Step 2 – Limiting SSL Usage

 

Enabling SSL in Tomcat’s server.xml file causes all files to be run both as secure and insecure pages, which can cause unnecessary server load. You can choose which applications offer SSL connections on a per-application basis by adding the following <security-constraint> element to the application’s WEB-INF/web.xml file:

 


 

<security-constraint>

 

<web-resource-collection>

 

<web-resource-name>YourAppsName</web-resource-name>

 

<url-pattern>/*</url-pattern>

 

</web-resource-collection>

 

<user-data-constraint>

 

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

 

</user-data-constraint>

 

</security-constraint>

 

This configuration allows you to set SSL options for all an application’s pages in one place. For example, to disable SSL for all your application’s pages, change “CONFIDENTIAL” to “NONE”.

 

 

 

HTTPS IN APACHE SERVER :

 

Follow These Steps:

 

  1. Open the Command Prompt and browse to [apache 2.2 path]/bin.
  2. Enter openssl req -config ../conf/openssl.cnf -new -out foo.csr -keyout foo.pem

 

e.g.

 

C:\Apache24\bin>openssl req -config ../conf/openssl.cnf -new -out c:\localhost.csr -keyout c:\localhost.pem

 

When you run the final command, a certificate request is generated. The following is an example of a certification request:

 

Country Name (2 letter code) [AU]: US

 

State or Province Name (full name)[Some-State]: California

 

Locality name (eg, city) []: Redwood Shores

 

Organization Name (eg, company) [Internet Widgits Pty Ltd}: Oracle

 

Organizational Unit Name (eg, section) []: EITQA

 

Common Name (eg, YOUR name) []:pdarshan-pc.us.oracle.com

 

Email Address []: [email protected]

 

 

 

Please enter the following “extra” attributes to be sent with your certification request:

 

A challenge password []:

 

An optional company name []:

 

 

 

  1. To Genearate a key:

 

 

 

C:\Apache24\bin>openssl rsa -in c:\localhost.pem -out c:\localhost.key

 

 

 

Be sure to take note of the following:

 

  • These commands create two files: localhost.pem  (Encrypted File) and localhost.csr (certificate request).
  • For Common Name, include the FULL name of the HOST and DOMAIN you are running the command on.
  • Remember the password you enter. This password is used every time Oracle HTTP Server is started.

 

  1. Send the Certification Request. In the CSR area, paste the certification request from localhost.csr  file.

 

  • When you receive the certificate, paste it into a file named portalcert.crt.

 

Be sure that you get the Root Trial CA certificate by going to the URL mentioned in the Certificate Authority email. Export that certificate from the browser to a file named rootcacert.crt.

 

  • Copy the following in appropriate directories:

 

  • Certificate file portalcert.crt into the …\Apache\Apache\conf\ssl.crt directory.
  • localhost.key  file into the …\Apache\Apache\conf\ssl.key directory.
  • Root Trial CA file rootcacert.crt into the …\Apache\Apache\conf\ssl.crt directory.

 

 

 

You can create a self-signed Certificate to taste HTTPS in Apache.

 

E.g.

 

C:\Apache24\bin> openssl x509 -in c:\ localhost.csr  -out c:\ localhost.crt  -req -signkey c:\ localhost.key” -days 7300

 

Here, “localhost.crt” is a self-signed certificate, and 7300 is validity date of certificate (7300 Days = 20years).

 

Modify httpd.conf File to Enable SSL

 

  • Add Listen 443
  • Uncomment out LoadModule ssl_module modules/mod_ssl.so
  • Certificate Entries

 

e.g.

 

 

 

SSLEngine on

 

SSLProtocol “TLSv1”

 

SSLCertificateKeyFile “c: /localhost.key”

 

SSLCertificateFile “c: localhost.crt”

 

 

For CA :

 


 

        SSLCACertificateFile conf\ssl.crt

 

                    SSLCACertificateFile conf\ssl.crt\rootcacert.crt

 

 

 

  • Restart Apache.

 

NOTE

 

 

http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html

 

SSL Entries in Virtual Host

 

E.g.

 

<VirtualHost *:443>

 

SSLEngine on

 

SSLProxyEngine on

 

SSLProtocol “TLSv1”

 

SSLCertificateKeyFile “/path/of/your/keyfile”

 

SSLCertificateFile “/path/of/your/certificate/file”

 

SSLCACertificateFile "/path/of/your/CAcertificate/file

 

SSLCACertificateFile "/path/of/your/CARootcertificate/file

 

 

 

# if you are using proxy, Proxy code here

 

</VirtualHost>

 

Leave a Reply