Sunday, July 22, 2007

CSR Generation Instructions- Tomcat

To generate a CSR, you will need to create a key pair for your server. These two items are a digital certificate key pair and cannot be separated. If you lose your public/private key file or your password and generate a new one, your SSL Certificate will no longer match. You will have to request a new SSL Certificate and may be charged.

Step 1: Generate the Keystore and Private Key

Please use JDK 1.3.1 or later.

  1. Create a certificate keystore and private key by executing the following command:

Unix: $JAVA_HOME/bin/keytool -genkey -alias -keyalg RSA -keystore

This command will prompt for the following X.509 attributes of the certificate:

Country Name (C): Use the two-letter code without punctuation for country, for example: US or CA.
State or Province (S): Spell out the state completely; do not abbreviate the state or province name, for example: California
Locality or City (L): The Locality field is the city or town name, for example: Berkeley.
Organization (O): If your company or department has an &, @, or any other symbol using the shift key in its name, you must spell out the symbol or omit it to enroll.
Example: XYZ Corporation
Organizational Unit (OU): This field is optional; but can be used to help identify certificates registered to an organization. The Organizational Unit (OU) field is the name of the department or organization unit making the request.
Common Name (CN): The Common Name is the Host + Domain Name. It looks like "www.company.com" or "company.com".
Note: When prompted for your "first- and lastname", enter the desired Common Name.

VeriSign certificates can only be used on Web servers using the Common Name specified during enrollment. For example, a certificate for the domain "domain.com" will receive a warning if accessing a site named "www.domain.com" or "secure.domain.com", because "www.domain.com" and "secure.domain.com" are different from "domain.com".

  1. Specify a password. The default value will be "changeit".

For further information, please refer to the Tomcat Web site.

Step 2: Generate a CSR

  1. The CSR is then created using the following command:

keytool -certreq -keyalg RSA -alias -file certreq.csr -keystore

  1. To copy and paste the file certreq.csr into the enrollment form, open the file in a text editor that does not add extra characters (Notepad or Vi are recommended).

Contact Information

During the verification process, VeriSign may need to contact your organization. Be sure to provide an email address, phone number, and fax number that will be checked and responded to quickly. These fields are not part of the certificate.

Digital Certificate Enrollment

Step by Step Overview

During the enrollment process, you will need the following information:

  1. The length of time you require the certificate to be valid (up to 3 years for some certificates)
  2. The number of servers hosting a single domain (up to 5 servers)
  3. The server platform
  4. The organization, organizational unit, country, state or locality
  5. Payment information and a billing contact
  6. The common name. the host + domain name such as “www.company.com” or “company.com”
  7. An email and telephone number where VeriSign can reach you to validate the information
  8. A CSR generated from the server you need to secure

Once VeriSign has validated the information provided, you will receive an email with installation instructions and a text file containing your approved SSL Certificate.

Authentication and Verification

Upon completion of the enrollment process, Verisign will authenticate your certificate application to verify that your organization exists and is registered with the proper government authorities. VeriSign will confirm that:

  • The Organization has a valid registration
  • The Organization owns/has rights to use the domain name listed in the common name field of the Certificate Signing Request (CSR)
  • The Corporate Contact is employed by or associated with the organization listed in the distinguished name
  • The Corporate Contact is aware of the certificate request
  • The Technical Contact listed is authorized to obtain the SSL Certificate

The steps taken to verify the above information differs by certificate type. For example, Extended Validation SSL Certificates require VeriSign to confirm that the Corporate Contact is authorized by the organization to approve and request EV SSL Certificates, that the Technical Contact has the authority to obtain the SSL Certificate, and confirm the physical address of the organization.

Name Information

The organization name submitted with the CSR must match the business registration certificate for the organization. In the case of EV SSL Certificates, the country, state and locality must match the location where the organization is registered. For example, VeriSign is a corporation registered in Delaware, therefore, the CSR for EV SSL Certificates must list Delaware not California where the servers may be located.

Correct Formatting

Do not use any shift characters in any of the enrollment fields. If your company has an & or @ symbol in its name, you must spell out the symbol or omit it in the enrollment field. An error 105 in CSR generation is usually caused by a Control character such as @, #, $, or % in one of the enrollment fields.

The locality is the city or town. State or province names must be spelled out without abbreviations, “California,” for example. Countries must be specified by the two-letter country code without punctuation: US for the United States, CA for Canada, etc.

Common Name

The Common Name is the Host + Domain Name. It looks like "www.company.com" or "company.com".

VeriSign SSL Certificates can only be used on Web servers hosting the Common Name specified during enrollment. For example, an SSL Certificate for the domain "domain.com" will receive a warning if accessing a site named "www.domain.com" or "secure.domain.com", because "www.domain.com" and "secure.domain.com" are different from "domain.com".

Import Certificate

An SSL certificate is bound to both the server software (i.e., Microsoft to Microsoft) and the certificate common name (i.e., “www.company.com” or “acme.com”). If these remain identical, you can export the certificate and its private key from the original server and import it into the target server.

Apache

Import the Certificate
  1. Rename the files on the backup to conform to: 'https-admsrv-(servername).cert7.db' and 'https-admsrv-(servername).key3.db'
  2. Create a Trust Database for the server.
  3. In the Alias directory, replace the cert7.db and key3.db files of the admin server to the cert7.db and key3.db of the new site.
  4. Restart the Web Service.

Tomcat


  1. Copy the backed up Keystore file to your SSL Directory. This directory can sometimes be hidden. For example: /root/.keystore
  2. Edit the server.xml file to configure the SSL connector.

Move a Certificate

Move a Certificate


There may be certain instances in which the SSL certificate must be moved from one server to another. A SSL certificate is bound to the server software and the common name. Therefore, the certificate and its corresponding private key may be exported from the original server and imported into the target server as long as both servers run the same server software (i.e. Microsoft IIS to Microsoft IIS) and the target server will be hosting a site that matches the common name.

If multiple servers are being used, you will need to purchase 1 license for every server being secured. Per VeriSign's Certificate Practices Statement (CPS), you are required to license the TOTAL # of servers that will be secured. For more information please view the VeriSign Certificate Practices Statement (CPS).


Move to a New Host

If you do not manage your own servers, you will need to work with your hosting companies to move the certificates.

  1. Determine if the new hosting company uses the same server software vendor.
  2. Ask your current hosting company to export a copy of the certificate and send it to you.
  3. Provide the encrypted file to your new hosting company.



Backup a Certificate

Backup a Certificate

When you backup an SSL certificate, the system copies the private key into an encrypted file. The private key was created on the server when the Certificate Signing Request (CSR) was generated. Select the correct software vendor and version below for backup instructions.

Apache

  1. Locate the private key and certificate files. The following directives in the httpd.conf point to the location of the key and certificate files:

SSLCertificateFile .../path/to/mycertfile.crt

SSLCACertificateFile …/path/to/intermediate.crt

SSLCertificateKeyFile .../path/to/mykeyfile.key

  1. Copy the .key file, both .crt files (one is the server certificate and the other is the intermediate CA certificate), and the httpd.conf file onto a diskette or CD.

.key – private key

.crt – server certificate

.crt – intermediate CA certificate

httpd.conf - Web server configuration file

VeriSign highly recommends that you save the file to a diskette or CD and store it in a safe place.


Tomcat

  1. Navigate to the SSL Directory where the SSL Keystore is kept. By default this can be a hidden directory. For example: /root/.keystore
  2. Make a copy of the keystore file in this directory. This contains your Private and Public keys.

VeriSign highly recommends that you save the file to a diskette or CD and store it in a safe place.

Generate a Certificate Signing Request (CSR)

Before you purchase an SSL Certificate, you need to generate a Certificate Signing Request (CSR) for the server where the certificate will be installed. Select CSR generation instructions for your server software. If your server is not listed or you need additional information, refer to your server documentation or contact your server vendor. If you do not know what software your server uses, contact your technical support.

Instructions for Financial Certificates

If you plan to purchase a Financial or OFX Certificate, follow instructions from supported vendors:

Instructions for Apache Certificates

CSR Generation Instructions- Apache mod_SSL

To generate a CSR, you will need to create a key pair for your server. These two items are a digital certificate key pair and cannot be separated. If you lose your public/private key file or your password and generate a new one, your SSL Certificate will no longer match. You will have to request a new SSL Certificate and may be charged.

VeriSign recommends that you contact the Apache mod_SSL vendor for additional information.


Step 1: Generate a Key Pair

The utility "openssl" is used to generate the key and CSR. This utility comes with the OpenSSL package and is usually installed under /usr/local/ssl/bin. If you have installed them elsewhere you will need to adjust these instructions appropriately.

Type the following command at the prompt:

openssl genrsa –des3 –out www.mydomain.com.key 1024


image

This command generates a 1024 bit RSA private key and stores it in the file www.mydomain.com.key. When prompted for a pass phrase: enter a secure password and remember it, as this pass phrase is what protects the private key. Both the private key and the certificate are required to enable SSL.

Note: To bypass the pass phrase requirement, omit the -des3 option when generating the private key. If you leave the private key unprotected, VeriSign recommends access to the server be restricted so that only authorized server administrators can access or read the private key file.

Step 2: Generate the CSR

Type the following command at the prompt:

openssl req –new –key www.mydomain.com.key –out www.mydomain.com.csr

image

This command will prompt for the following X.509 attributes of the certificate:

Country Name: Use the two-letter code without punctuation for country, for example: US or CA.

State or Province: Spell out the state completely; do not abbreviate the state or province name, for example: California

Locality or City: The Locality field is the city or town name, for example: Berkeley.

Company: If your company or department has an &, @, or any other symbol using the shift key in its name, you must spell out the symbol or omit it to enroll.

Example: XYZ Corporation

Organizational Unit: This field is optional; but can be used to help identify certificates registered to an organization. The Organizational Unit (OU) field is the name of the department or organization unit making the request. To skip the OU field, press Enter on your keyboard.

Common Name: The Common Name is the Host + Domain Name. It looks like "www.company.com" or "company.com".

VeriSign certificates can only be used on Web servers using the Common Name specified during enrollment. For example, a certificate for the domain "domain.com" will receive a warning if accessing a site named "www.domain.com" or "secure.domain.com", because "www.domain.com" and "secure.domain.com" are different from "domain.com".

Please do not enter your email address, challenge password or an optional company name when generating the CSR.

A public/private key pair has now been created. The private key (www.mydomain.com.key) is stored locally on the server machine and is used for decryption. The public portion, in the form of a Certificate Signing Request (certrequest.csr), will be for certificate enrollment.

Below is a screenshot of the CSR.


image

To copy and paste the information into the enrollment form, open the file in a text editor such as Notepad or Vi and save it as a .txt file. (NOTE: Do not use Microsoft Word as it may insert extra hidden characters that will alter the contents of the CSR.)

Once the CSR has been created, proceed to Enrollment.

Step 3: Backup your private key

Verisign recommends backing up the .key file and storing of the corresponding pass phrase. A good choice is to create a copy of this file onto a diskette or other removable media. While backing up the private key is not required, having one will be helpful in the instance of server failure.

Contact Information

During the verification process, VeriSign may need to contact your organization. Be sure to provide an email address, phone number, and fax number that will be checked and responded to quickly. These fields are not part of the certificate.



SSL Certificates Installation Instructions- Apache SSL

This document provides instructions for installing SSL Certificates. If you are unable to use these instructions for your server, VeriSign recommends that you contact either the vendor of your software or an organization that supports Apache-SSL.

Step 1: Install CA Certificate

Secure Site

If you are installing a Secure Site Certificate, you need to first install the Secure Site Intermediate CA Certificate.

Secure Site Pro

If you are installing a Secure Site Pro Certificate, you need to first install the Secure Site Pro Intermediate CA Certificate.

  1. Copy the intermediate certificate into text file and name it "intermediate.crt". This file can be placed in the same directory as your SSL Certificate. For example: /usr/local/ssl/cr
    Step 2: Install the SSL Certificate

    Your VeriSign certificate will be sent via email. If the certificate is included as an attachment (Cert.cer), you may use the file. If the certificate is imbedded in the body of the email, copy and paste it into a text file (such as OriginalCert.txt) using Vi or Notepad. Do not use Microsoft Word or other word processing programs that may add characters. Confirm that there are no extra lines or spaces in the file.

  1. To follow the naming convention for Apache, rename the certificate filename with the .crt extension. For example: cert.crt
  2. Copy your Certificate into the directory that you will be using to hold your certificates. In For example: /usr/local/ssl/crt/.

Step 3: Configure the Server

  1. In order to use the key pair, the httpd.conf file will need to be updated.
  2. In the Virtual Host settings for your site locate the httpd.conf file. Verify that you have the following 3 directives within this Virtual Host. Please add them if they are not present:

    SSLCertificateFile /usr/local/ssl/crt/public.crt
    SSLCertificateKeyFile /usr/local/ssl/private/private.key
    SSLCACertificateFile /usr/local/ssl/crt/intermediate.crt

The first directive tells Apache how to find the Certificate File, the second one where the private key is located, and the third line the location of the intermediate certificate.

If you are using a different location and certificate file names than the example above (which most likely you are) you will need to change the path and filename to reflect your server.

Note: Some instances of Apache contain both a httpd.conf and ssl.conf file. Please enter or amend the httpd.conf or the ssl.conf with the above directives. Do not enter both as there will be a conflict and Apache may not start.

  1. Save your httpd.conf file and restart Apache. You can most likely do so by using the apachectl script:

    apachectl stop
    apachectl startssl
  2. You should now be set to start using your VeriSign certificate with your Apache-SSL Server.

Digital Certificates

Cryptography literally means "the art of secret writing". It allows two people, commonly known as Alice and Bob, to communicate with each other securely. This means that an eavesdropper, referred to as Eve, will not be able to listen in on their communication. Cryptography also enables Bob to check that the message sent by Alice was not modified by Eve and that the message he receives was really sent by Alice.

Public key and secret key cryptography

There are two major classes of cryptographic systems. The first is called secret key encryption. These systems use a single key, which Alice and Bob both must know. They must keep it a secret (hence the name) from Eve, otherwise Eve will be able to decrypt any messages encrypted using that key.

The second class is called public key encryption. In these systems Alice and Bob both have a key pair, not just a single key. Every pair consists of a public key and a private key. Alice and Bob can freely tell each other what their public keys are, and Eve is allowed to obtain a copy of their public keys. Using Bob's public key Alice can encrypt messages to Bob. Bob can then only decrypt those messages using his private key.


Secret key cryptography


Secret key cryptography uses a single key which both parties (usually named Alice and Bob) both must know. They must keep this key a secret (hence the name) from an eavesdropper (named Eve), otherwise Eve will be able to decrypt any messages encrypted using that key.

Alice uses a secret key encryption scheme (or cryptographic algorithm) to transform a message into something resembling random noise. The scheme may be publicly known. The security of the system comes from the secret key that Alice uses. The transformation can only be undone by Bob and Alice herself, since only they know the secret key.

Encryption and decryption using a secret key

To secretly communicate with Bob, Alice encrypts her messages before sending them. There are many techniques (cryptographic algorithms) that she can use. All these algorithms have in common that they can transform a message using a key into something that resembles random noise. This is called encrypting the message. Only the persons who know the key can transform the random noise back into the original message, or in other words, decrypt the message. This means that those persons must keep this key a secret, hence the name secret key cryptography.

How to get the key to the recipient

A fundamental problem with secret key encryption is that somehow the secret key has to be delivered to the recipient of the message in a secure way. Once that key has been securely delivered, other keys can be delivered by simply encrypting them with that first key. One way to solve this problem is to have Alice and Bob meet in person so they can agree on a key. They must make sure that Eve is not listening in on them, otherwise Eve also learns the key. This applies especially if Alice and Bob agree on a key via telephone or e-mail. Of course Bob must also be able to distinguish Alice and Eve if they meet for the first time (for Alice it shouldn't be a problem to tell Bob from Eve).

If Alice and Bob can not meet in private to agree on the key, it is very difficult for them to use secret key cryptography. If they simply agree on a key by e-mail for example, Eve could be listening in on their e-mail conversation and thus also learn what the key is. If Alice and Bob had a secure channel that Eve could not tap, they could use that channel to agree on a secret key. However, then they could also use the secure channel to simply transmit their messages.

This problem is solved by using public key cryptography, which is discussed in the next chapter.

How secret key cryptography works

Secret key cryptography transforms (scrambles) a message into something resembling random noise. The precise transformation is determined by the key. Mathematically seen, a cryptographic algorithm is a function that maps a message onto a ciphertext (an encrypted message). By using keys, it is possible to encrypt many different messages using one particular cryptographic algorithm in different ways. And keeping the key a secret is much easier than keeping a complete algorithm a secret.

Some cryptographic algorithms operate on single characters of the message. These are called stream ciphers. Others operate on entire blocks, and therefore are called block ciphers. Stream ciphers are easier to implement in hardware than block ciphers, and they are also generally faster. Block ciphers tend to be harder to crack.



Public key cryptography

When using public key cryptography, Alice and Bob both have their own key pairs. A key pair consists of a public key and a private key. If the public key is used to encrypt something, then it can be decrypted only using the private key. And similarly, if the private key is used to encrypt something, then it can be decrypted only using the public key. It is not possible to figure out what the private key is given only the public key, or vice versa.

This makes it possible for Alice and Bob to simply send their public keys to one another, even if the channel they are using to do so is insecure. It is no problem that Eve now gets a copy of the public keys. If Alice wants to send a secret message to Bob, she encrypts the message using Bob's public key. Bob then takes his private key to decrypt the message. Since Eve does not have a copy of Bob's private key, she cannot decrypt the message. Of course this means that Bob has to carefully guard his private key. With public key cryptography it is thus possible for two people who have never met to securely exchange messages.

Combining public key and secret key cryptography

A problem with public key cryptography is that it is very slow. Encrypting a message that is several megabytes long takes a very long time, much longer than when using secret key cryptography. For this reason few people use only public key cryptography. What Alice usually does is encrypt the message using a secret key encryption algorithm and a key she made up on the spot. She then encrypts this key (called the session key) using Bob's public key. Bob can then obtain the session key by decrypting it using his private key. And with the session key he can decrypt the message. This way a long message is encrypted very quickly and Alice can still send it to Bob without needing a secure way of agreeing on the key.


How public key cryptography works

Public key cryptography systems are usually based on the assumption that a particular mathematical operation is easy to do, but difficult to undo unless you know some particular secret. This particular secret that serves as the private key. The two most famous public key cryptography systems are Diffie-Hellman and the RSA system, named after its inventors Rivest, Shamir and Adleman. More recently public key cryptography based on so-called elliptic curves has gotten a lot of attention.

Using public key cryptography it is possible to easily encrypt a message for multiple recipients. It is even possible to later authorize recipients to read the message. The message is simply encrypted with a session key. The session key is encrypted multiple times, once for every recipient using his public key. If later another recipient needs to be added, the session key is simply then also encrypted using his public key. Every recipient can now decrypt the session key independently from every other recipient.


What is cryptography used for

Cryptography has many practical applications, in particular for electronic communication on the Internet. Alice and Bob can of course encrypt the e-mail messages they exchange. They can also encrypt live communication sessions such as remote logins or chat sessions. In such applications typically every character or sentence Alice enters is encrypted and transmitted as a separate message over an insecure channel. Cryptography is also often used to protect Web transactions and other e-commerce applications. For example, many e-commerce sites use SSL encryption to protect confidential transmissions (which can be seen from the 'https' URL or the little lock in the browser window).

Another popular application is securely logging into remote systems. Traditional methods, such as Telnet, are not secure. Using an application like Secure Shell (ssh) the connection to a remote host is encrypted, making it impossible for third parties to 'tap' the connection.

The basic principle

Alice needs a copy of Bob's public key to encrypt messages to him using public key cryptography. And Bob needs Alice's public key to verify any digital signatures on Alice's messages. Both must be sure that they have the right public key. This is where digital certificates come in.

Digital certificates are messages that couple an identity to a public key. They are signed by the person or authority that created them. If Bob trusts that authority, he can be sure that certificates issued by that authority are genuine and so he can check that he really has Alice's public key.

An important aspect of public key cryptography is that Alice and Bob must be convinced that they have the right public key of each other. Eve could have substituted her own public key for Bob's, and then Alice would be encrypting messages intended for Bob in a way that Eve could read them. Eve could then encrypt them again with Bob's real public key so that he would not notice Alice has the wrong public key. If Eve does the same the other way around, all communication between Alice and Bob can be read by Eve and neither of them knows it!

Alice and Bob could of course meet in person or call each other over the phone to verify that they have the right public keys. This is often impractical, and Alice and Bob might not even know each other. For example, Alice could own a Web store and use public key encryption so that her customer Bob can securely send her his credit card details. Now if Bob tries to call Alice, how can he possibly know that he's talking to Alice and not to Eve?

The use of digital certificates solves this problem. Next to Alice, Bob and Eve, there is now also a trusted third party, usually called Trent because that name also starts with a T. if Alice wants to have Bob's public key, she will go to Trent to ask for a copy. Trent will then send her a message containing details of Bob's identity and Bob's public key. This message, called the certificate for Bob's public key, is signed by Trent. Alice now verifies that the digital signature is correct using Trent's public key. If this is the case, she knows that she has Bob's real public key and she now also knows that Bob is called Bob.

Eve is now no longer able to impersonate Bob by giving Alice a public key pretending it is Bob's. Since this public key is not signed by Trent, Alice will not accept it. And Alice is sure that Trent checked Bob's passport or driver's license before making the certificate.

Of course Eve might now try to pretend that she is Trent. If she can pull this off, she can listen in on everybody's communication! To prevent this, Alice should make sure that she really has Trent's public key. This should be quite easy. Trent could be a government agency or a notary public, and so she can simply visit Trent and take a copy of this public key home with her. She only has to do this once and then she can securely communicate with everyone else who visited Trent and had him make a certificate.

What is HTTPS?

HTTPS stands for Hypertext Transfer Protocol over Secure Socket Layer, or HTTP over SSL.

HTTPS encrypts and decrypts the page requests and page information between the client browser and the web server using a secure Socket Layer (SSL). HTTPS by default uses port 443 as opposed to the standard HTTP port of 80. URL's beginning with HTTPS indicate that the connection between client and browser is encrypted using SSL.

SSL transactions are negotiated by means of a keybased encryption algorithm between the client and the server, this key is usually either 40 or 128 bits in strength (the higher the number of bits the more secure the transaction).

HTTPS should not be confused with S-HTTP, a security-enhanced version of HTTP. SSL and S-HTTP have very different designs and goals so it is possible to use the two protocols together. Whereas SSL is designed to establish a secure connection between two computers, S-HTTP is designed to send individual messages securely.

Both protocols have been submitted to the Internet Engineering Task Force (IETF) for approval as a standard.

What is Secure Socket Layer (SSL)?

Originally developed by Netscape, SSL - short for Secure Sockets Layer - has been universally accepted on the World Wide Web for authenticated and encrypted communication between clients and servers. SSL works by using a public key to encrypt data that's transferred over the SSL connection.

The Transmission Control Protocol/Internet Protocol (TCP/IP) controls and is responsible for the routing and transmission of data all over the Internet. The SSL protocol runs in a "layer" above TCP/IP and below higher-level protocols such as HTTP or IMAP. SSL allows an SSL enabled server to authenticate itself to an SSL enabled client and vice versa enabling both machines to establish an encrypted connection

SSL makes use of a public key infrastructure (PKI) to operate. The server operating securely generally obtains an SSL key and certificate pair from an issueing authority. It then makes these available on the server itself and announces the availability within the protocol exchanges between the server and client.

An SSL exchange is initiated with an SSL handshake where the client and the server exchange information with each other regarding the encryption information indicated by the SSL certificate.

Once this handshake is completed both the client and the server know exactly how to encrypt the information in a way that the other end will understand and be able to decrypt.

From that point on, anyone listening to (or snooping on) the data transfer between the client and the server will only see this encrypted information. They would then have to spend a long time decrypting it before they could make any sense out of it.

The greater the number of bits used when generating a certificate the stronger the encryption used with 1024 bit keys now being commonplace. It can take weeks of work using fast computers to successfully decrypt such a key.

SSL encryption is available on web pages to a secure server. Further, messaging servers (such as GMS) can also support SSL over POP3, IMAP4, SMTP as well as HTTP. By providing a complete secure route for messages, users of GMS can be confident that they can read, write and respond to email without anyone snooping on them.

SSL has more recently become known as Transport Layer Security, or TLS for short.

Topics