The CDP server comes with SSL already set up. By default, SSL works with a self-signed certificate. This certificate can be used for encryption only and does not prove the identity of the server.
That default certificate is not signed by any well-known Certification Authority (CA), so when the users try to open the SSL version of the CDP Server Web Interface, they usually see the warning in the browser window (see the image below).
!certificate1.png!
If you decide to continue working with this self-signed certificate, you have to perform several steps to "accept" the certificate before you access the site. This usually occurs only the first time you access the site. Then the self-signed certificate is stored in the browser database marked as trusted. This scenario is suitable for testing purposes or for running the CDP Server on the company's internal networks.
But if you want to provide a CDP SSL interface to the outside world, you should obtain a certificate signed by a well-known CA. The role of a CA is to verify that the CDP Server you are trying to access actually has the name you are trying to access it by, and that this server actually belongs to your organization.
----
{toc:location=top|maxLevel=3|minLevel=3|type=flat|separator=pipe|style=border:1}
----
h3. Obtaining CA-Signed Certificate for Production Use
Certificates for production use are issued by trusted 3rd party Certification Authorities (CAs). Many CAs simply verify the domain name and issue the certificate, whereas others ([VeriSign|http://www.verisign.com/], etc.) verify the existence of your business, the ownership of your domain name, and your authority to apply for the certificate, providing a higher standard of authentication.
Every browser comes with a pre-defined list of well-known CAs. A sample list of CAs can be found [here|http://www.dmoz.org/Computers/Security/Public_Key_Infrastructure/PKIX/Tools_and_Services/Third_Party_Certificate_Authorities/].
Along with the name of your organization and the name of your server, a CA-signed certificate contains the public key of the server. This public key is used by the browser to encrypt data sent to the server. There is a private key on the server. The server uses the private key to decrypt the data encrypted by the public key. The private key should be kept secure on the server to prevent unauthorized access. Both private and public keys participate in the process of generating the certificate.
To learn more about public key cryptography, you can read this [wikipedia page|http://en.wikipedia.org/wiki/Public-key_cryptography]. To learn more about certificates and steps to buy a certificate, you need to take a look at CAs' websites. Some of the most well known CAs are:
* [VeriSign|http://www.verisign.com/]
* [Thawte|http://www.thawte.com/]
* [CAcert|http://www.cacert.org/]
----
h3. Generating Certificate Request
Before the CA can issue you the certificate, you should generate the certificate request and send it to the CA for signing. The steps for generating a certificate request are provided below.
In the examples below, all operations are performed by the *Java keytool* \- a key and certificate management utility. This utility does not come with the CDP Server. To get this utility, you should download and install Java Development Kit (JDK) or Java Runtime Environment (JRE). Both of these packages can be downloaded from the [java.sun.com|http://java.sun.com] website.
----
h3. Importing Certificate into the Trust-Store
The following steps show you how to install a SSL certificate purchased from a Certification Authority. Your SSL vendor may have different instructions, please check with them for proper certificate installation. The following examples refer to GoDaddy and VeriSign.
To enable a certificate, you need to use the *Java keytool* \- a key and certificate management utility. The keytool stores the keys and certificates in a so-called *keystore*.
{info:title=Note}In CDP 2.0, you could paste the SSL and private key into the HTTPS configuration page in the web interface. But this way had some limitations: only root CA signed certificates worked.
In CDP, the new method allows chained and wildcard certificates to be installed as well. Using the *keytool* is very standard for applications with a web interface using Java.
{info}
h4. Windows
*1. Start a Windows Command Prompt.*
Go to Start !arrow-transparent.gif! Programs !arrow-transparent.gif! Accessories !arrow-transparent.gif! Command Prompt.
!assessories.png!
Alternatively, you can go to Start !arrow-transparent.gif! Run !arrow-transparent.gif! type "{color:blue}cmd{color}" without quotes and press <Enter>.
!cmd.png!
*2. Use* *_\-import{_}* *option of Java keytool to place a certificate to keystore.*
You have the website certificate in a local {color:blue}.cer{color} file. Now you can use Java keytool to import it into keystore. Use the {color:blue}\-import{color} command:
{code}<keytool path> -import -alias <my alias> -file <certificate file name> -keystore <keystore path>{code}
Substitute the paths and option values with the correct ones for your specific system. For example, type the following command to create a keystore named "keystore" and import the certificate into an entry with an alias of "jetty."
{code}"C:\Program Files\Java\jre6\bin\keytool" -import -alias jetty -file "C:\temp\file.cer" -keystore "C:\keystore"{code}
Then you will be requested to enter a keystore password. It must be at least 6 characters.
!pass.png!
Since the keystore does not exist yet, keytool will create it. This sample command imports the certificate(s) in the file {color:blue}file.cer{color} and stores it in the keystore entry identified by the alias {color:blue}jetty{color}.
When you are adding a trusted certificate entry, the alias should not already exist in the keystore. If the alias does already exist, then keytool outputs an error, since there is already a trusted certificate for that alias, and does not import the certificate. If the alias does not exist in the keystore, keytool creates a trusted certificate entry with the specified alias and associates it with the imported certificate.
{note:title=Tip}You can display the contents of the keystore using the following command:
{code}keytool -list -v -keystore <keystore path>{code}
{note}
*3. Restart the CDP Server service.*
Follow the instructions below to restart the CDP Server using the CDP Configuration Utility.
Go to Start !arrow-transparent.gif! All Programs !arrow-transparent.gif! R1Soft CDP Backup !arrow-transparent.gif! CDP Configuration Utility.
!config-utility.png!
The Configuration Utility will start.
!config-utility1.png!
From the "Services" menu, select the "Restart CDP Server" option.
!services.png!
Confirm your request to restart the CDP Server by clicking "OK."
!confirm.png!
h4. Linux
1. Establish a SSH connection to the Linux server where the CDP Server is installed. Or log in on the text Linux console.
You should either log in as root or obtain root permissions after login via {color:#0000ff}su{color} or {color:#0000ff}sudo{color} command.
{info:title=Note}Your home directory should be set to /root.
{info}
2. Upload the key and the certificate to the CDP Server.
3. Use the {color:#0000ff}cd{color} command to go to the directory where the keys are in.
4. Run the following commands to convert the key and the certificate files from PEM into DER format.
{code}openssl pkcs8 -topk8 -nocrypt -in wildcard.r1soft.com.key -inform PEM -out wildcard.r1soft.com.key.der -outform DER{code}
{code}openssl x509 -in wildcard.r1soft.com.crt -inform PEM -out wildcard.r1soft.com.crt.der -outform DER{code}
5. Use the {color:#0000ff}cd{color} command to go to the directory where *keytool* is located.
{code}cd /usr/sbin/r1soft/jre/bin{code}
And define the access rights to the following applications. *keytool* that comes with our product is not executable, so you have to chmod 755 it.
{code}chmod 755 java{code}
{code}chmod 755 keytool{code}
6. Use the {color:#0000ff}wget{color} command to download the ImportKey utility:
{code}wget http://community.igniterealtime.org/servlet/JiveServlet/download/196707-4718/importkey.zip{code}
7. Unzip ImportKey.zip.
{code} unzip ImportKey.zip{code}
8. Run the following command. It will launch the ImportKey utility and create the keystore file (default name is *keystore.ImportKey*) in your home directory (root). The private key and the certificate will be placed there.
{code}./java ImportKey /root/wildcard.r1soft.com.key.der /root/wildcard.r1soft.com.crt.der{code}
{info:title=Note}The keystore's password and the key's passwords must be set to *password*.
{info}
9. The following command will allow you to set the password for your keystore file. The default password is *importkey*. Enter it when prompted and then type the new password, which must be set to "*password*".
{code}./keytool -storepasswd -keystore /root/keystore.ImportKey{code}
10. This command will allow you to set the password for the key file in the keystore. The default password is *importkey*. Enter it when prompted and then type the new password, which must be set to "*password*".
{code}./keytool -keypasswd -alias importkey -keystore /root/keystore.ImportKey{code}
11. Rename the *keystore.ImportKey* file (default name) into *keystore*.
{code}mv /root/keystore.ImportKey /root/keystore{code}
12. Run the following command to download the trusted certificate from the Certification Authority (CA). In our example, we connect to {color:#0000ff}Go Daddy{color}.
{code}wget -no-check-certificate https://certificates.godaddy.com/repository/sf_issuing.crt {code}
13. Import the received trusted certificate into your *keystore* file.
{code}./keytool -import -alias intermed -file /root/sf_issuing.crt -keystore /root/keystore -trustcacerts {code}
14. You may have another keystore in your R1Soft folder. To make a backup copy of it, you should rename it (for example, to "*keystore.old*" as shown in the following example).
{code}mv /usr/sbin/r1soft/conf/keystore /usr/sbin/r1soft/conf/keystore.old{code}
15. Copy the new keystore file to your *R1Soft* folder.
{code}cp /root/keystore /usr/sbin/r1soft/conf/keystore {code}
16. Restart the CDP Server.
{code}/etc/init.d/cdp-server restart{code}
h4. keytool Options
* *\- alias* \- All keystore entries are accessed via unique aliases. Aliases are case-insensitive. An alias is specified when you add an entity to the keystore using the {color:blue}\-import{color} command. Subsequent keytool commands must use this same alias to refer to the entity.
* *\- file* \- Define absolute or relative path to your certificate file. If you define only file name, it means, that the file is located in the root directory.
* *\- keystore* \- Each keytool command has a {color:blue}\-keystore{color} option for specifying the name and location of the persistent keystore file for the keystore managed by keytool. A keystore is created when you use {color:blue}\-import{color} command to add data to a keystore that does not already exist. If you do not specify a {color:blue}\-keystore{color} option, the default keystore is a file named {color:blue}.keystore{color} in your home directory (as determined by the "user.home" system property). If that file does not already exist, it will be created.
{excerpt:hidden=true}*Windows:*
Given user name uName, the "user.home" property value defaults to:
{code}C:\Winnt\Profiles\uName on multi-user Windows NT systems
C:\Windows\Profiles\uName on multi-user Windows 95 systems
C:\Windows on single-user Windows 95 systems{code}
{excerpt}
Read more about Java keytool for Windows:
[http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html]\\
{excerpt:hidden=true}*Linux:*
The keystore is by default stored in a file named _.keystore_ in the user's home directory, as determined by the "user.home" system property. If you do not specify a \-keystore option, the default keystore is a file named .keystore in your home directory.{excerpt}
Read more about Java keytool for Linux:
[http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html].
----
h3. Configuring CDP for SSL Communication
See [CDP3:Configuring Web Server Options].
{excerpt:hidden=true}Instructions on how to install a certificate signed by an Authority. The role of a CA is to verify that the CDP Server you are trying to access actually has the name you are trying to access it by, and that this server actually belongs to your organization. {excerpt}
That default certificate is not signed by any well-known Certification Authority (CA), so when the users try to open the SSL version of the CDP Server Web Interface, they usually see the warning in the browser window (see the image below).
!certificate1.png!
If you decide to continue working with this self-signed certificate, you have to perform several steps to "accept" the certificate before you access the site. This usually occurs only the first time you access the site. Then the self-signed certificate is stored in the browser database marked as trusted. This scenario is suitable for testing purposes or for running the CDP Server on the company's internal networks.
But if you want to provide a CDP SSL interface to the outside world, you should obtain a certificate signed by a well-known CA. The role of a CA is to verify that the CDP Server you are trying to access actually has the name you are trying to access it by, and that this server actually belongs to your organization.
----
{toc:location=top|maxLevel=3|minLevel=3|type=flat|separator=pipe|style=border:1}
----
h3. Obtaining CA-Signed Certificate for Production Use
Certificates for production use are issued by trusted 3rd party Certification Authorities (CAs). Many CAs simply verify the domain name and issue the certificate, whereas others ([VeriSign|http://www.verisign.com/], etc.) verify the existence of your business, the ownership of your domain name, and your authority to apply for the certificate, providing a higher standard of authentication.
Every browser comes with a pre-defined list of well-known CAs. A sample list of CAs can be found [here|http://www.dmoz.org/Computers/Security/Public_Key_Infrastructure/PKIX/Tools_and_Services/Third_Party_Certificate_Authorities/].
Along with the name of your organization and the name of your server, a CA-signed certificate contains the public key of the server. This public key is used by the browser to encrypt data sent to the server. There is a private key on the server. The server uses the private key to decrypt the data encrypted by the public key. The private key should be kept secure on the server to prevent unauthorized access. Both private and public keys participate in the process of generating the certificate.
To learn more about public key cryptography, you can read this [wikipedia page|http://en.wikipedia.org/wiki/Public-key_cryptography]. To learn more about certificates and steps to buy a certificate, you need to take a look at CAs' websites. Some of the most well known CAs are:
* [VeriSign|http://www.verisign.com/]
* [Thawte|http://www.thawte.com/]
* [CAcert|http://www.cacert.org/]
----
h3. Generating Certificate Request
Before the CA can issue you the certificate, you should generate the certificate request and send it to the CA for signing. The steps for generating a certificate request are provided below.
In the examples below, all operations are performed by the *Java keytool* \- a key and certificate management utility. This utility does not come with the CDP Server. To get this utility, you should download and install Java Development Kit (JDK) or Java Runtime Environment (JRE). Both of these packages can be downloaded from the [java.sun.com|http://java.sun.com] website.
----
h3. Importing Certificate into the Trust-Store
The following steps show you how to install a SSL certificate purchased from a Certification Authority. Your SSL vendor may have different instructions, please check with them for proper certificate installation. The following examples refer to GoDaddy and VeriSign.
To enable a certificate, you need to use the *Java keytool* \- a key and certificate management utility. The keytool stores the keys and certificates in a so-called *keystore*.
{info:title=Note}In CDP 2.0, you could paste the SSL and private key into the HTTPS configuration page in the web interface. But this way had some limitations: only root CA signed certificates worked.
In CDP, the new method allows chained and wildcard certificates to be installed as well. Using the *keytool* is very standard for applications with a web interface using Java.
{info}
h4. Windows
*1. Start a Windows Command Prompt.*
Go to Start !arrow-transparent.gif! Programs !arrow-transparent.gif! Accessories !arrow-transparent.gif! Command Prompt.
!assessories.png!
Alternatively, you can go to Start !arrow-transparent.gif! Run !arrow-transparent.gif! type "{color:blue}cmd{color}" without quotes and press <Enter>.
!cmd.png!
*2. Use* *_\-import{_}* *option of Java keytool to place a certificate to keystore.*
You have the website certificate in a local {color:blue}.cer{color} file. Now you can use Java keytool to import it into keystore. Use the {color:blue}\-import{color} command:
{code}<keytool path> -import -alias <my alias> -file <certificate file name> -keystore <keystore path>{code}
Substitute the paths and option values with the correct ones for your specific system. For example, type the following command to create a keystore named "keystore" and import the certificate into an entry with an alias of "jetty."
{code}"C:\Program Files\Java\jre6\bin\keytool" -import -alias jetty -file "C:\temp\file.cer" -keystore "C:\keystore"{code}
Then you will be requested to enter a keystore password. It must be at least 6 characters.
!pass.png!
Since the keystore does not exist yet, keytool will create it. This sample command imports the certificate(s) in the file {color:blue}file.cer{color} and stores it in the keystore entry identified by the alias {color:blue}jetty{color}.
When you are adding a trusted certificate entry, the alias should not already exist in the keystore. If the alias does already exist, then keytool outputs an error, since there is already a trusted certificate for that alias, and does not import the certificate. If the alias does not exist in the keystore, keytool creates a trusted certificate entry with the specified alias and associates it with the imported certificate.
{note:title=Tip}You can display the contents of the keystore using the following command:
{code}keytool -list -v -keystore <keystore path>{code}
{note}
*3. Restart the CDP Server service.*
Follow the instructions below to restart the CDP Server using the CDP Configuration Utility.
Go to Start !arrow-transparent.gif! All Programs !arrow-transparent.gif! R1Soft CDP Backup !arrow-transparent.gif! CDP Configuration Utility.
!config-utility.png!
The Configuration Utility will start.
!config-utility1.png!
From the "Services" menu, select the "Restart CDP Server" option.
!services.png!
Confirm your request to restart the CDP Server by clicking "OK."
!confirm.png!
h4. Linux
1. Establish a SSH connection to the Linux server where the CDP Server is installed. Or log in on the text Linux console.
You should either log in as root or obtain root permissions after login via {color:#0000ff}su{color} or {color:#0000ff}sudo{color} command.
{info:title=Note}Your home directory should be set to /root.
{info}
2. Upload the key and the certificate to the CDP Server.
3. Use the {color:#0000ff}cd{color} command to go to the directory where the keys are in.
4. Run the following commands to convert the key and the certificate files from PEM into DER format.
{code}openssl pkcs8 -topk8 -nocrypt -in wildcard.r1soft.com.key -inform PEM -out wildcard.r1soft.com.key.der -outform DER{code}
{code}openssl x509 -in wildcard.r1soft.com.crt -inform PEM -out wildcard.r1soft.com.crt.der -outform DER{code}
5. Use the {color:#0000ff}cd{color} command to go to the directory where *keytool* is located.
{code}cd /usr/sbin/r1soft/jre/bin{code}
And define the access rights to the following applications. *keytool* that comes with our product is not executable, so you have to chmod 755 it.
{code}chmod 755 java{code}
{code}chmod 755 keytool{code}
6. Use the {color:#0000ff}wget{color} command to download the ImportKey utility:
{code}wget http://community.igniterealtime.org/servlet/JiveServlet/download/196707-4718/importkey.zip{code}
7. Unzip ImportKey.zip.
{code} unzip ImportKey.zip{code}
8. Run the following command. It will launch the ImportKey utility and create the keystore file (default name is *keystore.ImportKey*) in your home directory (root). The private key and the certificate will be placed there.
{code}./java ImportKey /root/wildcard.r1soft.com.key.der /root/wildcard.r1soft.com.crt.der{code}
{info:title=Note}The keystore's password and the key's passwords must be set to *password*.
{info}
9. The following command will allow you to set the password for your keystore file. The default password is *importkey*. Enter it when prompted and then type the new password, which must be set to "*password*".
{code}./keytool -storepasswd -keystore /root/keystore.ImportKey{code}
10. This command will allow you to set the password for the key file in the keystore. The default password is *importkey*. Enter it when prompted and then type the new password, which must be set to "*password*".
{code}./keytool -keypasswd -alias importkey -keystore /root/keystore.ImportKey{code}
11. Rename the *keystore.ImportKey* file (default name) into *keystore*.
{code}mv /root/keystore.ImportKey /root/keystore{code}
12. Run the following command to download the trusted certificate from the Certification Authority (CA). In our example, we connect to {color:#0000ff}Go Daddy{color}.
{code}wget -no-check-certificate https://certificates.godaddy.com/repository/sf_issuing.crt {code}
13. Import the received trusted certificate into your *keystore* file.
{code}./keytool -import -alias intermed -file /root/sf_issuing.crt -keystore /root/keystore -trustcacerts {code}
14. You may have another keystore in your R1Soft folder. To make a backup copy of it, you should rename it (for example, to "*keystore.old*" as shown in the following example).
{code}mv /usr/sbin/r1soft/conf/keystore /usr/sbin/r1soft/conf/keystore.old{code}
15. Copy the new keystore file to your *R1Soft* folder.
{code}cp /root/keystore /usr/sbin/r1soft/conf/keystore {code}
16. Restart the CDP Server.
{code}/etc/init.d/cdp-server restart{code}
h4. keytool Options
* *\- alias* \- All keystore entries are accessed via unique aliases. Aliases are case-insensitive. An alias is specified when you add an entity to the keystore using the {color:blue}\-import{color} command. Subsequent keytool commands must use this same alias to refer to the entity.
* *\- file* \- Define absolute or relative path to your certificate file. If you define only file name, it means, that the file is located in the root directory.
* *\- keystore* \- Each keytool command has a {color:blue}\-keystore{color} option for specifying the name and location of the persistent keystore file for the keystore managed by keytool. A keystore is created when you use {color:blue}\-import{color} command to add data to a keystore that does not already exist. If you do not specify a {color:blue}\-keystore{color} option, the default keystore is a file named {color:blue}.keystore{color} in your home directory (as determined by the "user.home" system property). If that file does not already exist, it will be created.
{excerpt:hidden=true}*Windows:*
Given user name uName, the "user.home" property value defaults to:
{code}C:\Winnt\Profiles\uName on multi-user Windows NT systems
C:\Windows\Profiles\uName on multi-user Windows 95 systems
C:\Windows on single-user Windows 95 systems{code}
{excerpt}
Read more about Java keytool for Windows:
[http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html]\\
{excerpt:hidden=true}*Linux:*
The keystore is by default stored in a file named _.keystore_ in the user's home directory, as determined by the "user.home" system property. If you do not specify a \-keystore option, the default keystore is a file named .keystore in your home directory.{excerpt}
Read more about Java keytool for Linux:
[http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html].
----
h3. Configuring CDP for SSL Communication
See [CDP3:Configuring Web Server Options].
{excerpt:hidden=true}Instructions on how to install a certificate signed by an Authority. The role of a CA is to verify that the CDP Server you are trying to access actually has the name you are trying to access it by, and that this server actually belongs to your organization. {excerpt}