diff options
Diffstat (limited to 'rse/doc/org.eclipse.rse.doc.user/tasks/tworkssl.html')
| -rw-r--r-- | rse/doc/org.eclipse.rse.doc.user/tasks/tworkssl.html | 88 |
1 files changed, 0 insertions, 88 deletions
diff --git a/rse/doc/org.eclipse.rse.doc.user/tasks/tworkssl.html b/rse/doc/org.eclipse.rse.doc.user/tasks/tworkssl.html deleted file mode 100644 index bb6661380..000000000 --- a/rse/doc/org.eclipse.rse.doc.user/tasks/tworkssl.html +++ /dev/null @@ -1,88 +0,0 @@ -<?xml version="1.0" encoding="utf-8"?> -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" - "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"> -<head> -<meta http-equiv="content-type" content="text/html; charset=utf-8" /> -<meta name="copyright" content="Copyright (c) IBM Corporation 2007. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." /> -<link rel="stylesheet" type="text/css" href="../book.css" /> -<title> Working with SSL </title> -</head> -<body> -<h1>Working with SSL</h1> -<h2>SSL Overview</h2> -<p> -Secure-Sockets Layer (SSL) is a communications facility that encrypts all communications -between a client and a target system. The DStore communications protocol in RSE supports SSL. -</p> -<p> -SSL achieves its security by using <em>certificates</em> to authenticate each side of a -connection made between two parties. The certificates allow for the certain identification of those -parties and for the negotiation of an encrypted channel for communication. The certificates -themselves are files whose alteration can be easily detected and whose origin is verified by a -trusted <em>certificate authority</em>. -</p> -<p> -Web browsers use SSL and request SSL certificates from their servers to communicate with -on-line stores, banks, and other service providers. These are the same kind of certificates, but are -used for a different purpose. A web browser will typically be verifying the identity of the server -and will be contacting a certificate authority to do so. RSE users, on the other hand, will -typically trust the target system to provide certificates to client systems so that the -communications can be encrypted. -</p> -<h2>Using SSL</h2> -<p> -Certificates are usually manufactured by a service provider (such as a target system) in concert -with a certificate authority. The authority can be any entity that the target system trusts including -itself. Certificates are delivered to a client system by the target system when the two are negotiating -an SSL connection. When starting a connection to a server, DStore first attempts an SSL connection -and then falls back to non-SSL if the SSL one fails. As a client, you don't need to be concerned -with the handling of certificates at all, but you can use the RSE SSL preferences -page to manage all your certificates that you have received from the target systems you have -connected to in the past. -</p> -<p> -You reach the RSE preferences page by opening the <code>Preferences</code> for the workbench, -expanding the <code>Remote Systems</code> category and selecting the <code>SSL</code> subcategory. -There you will see operations that allow you to add certificates, rename them to make them easier to -manage, remove them once they have expired, and view their contents. You would typically see one -certificate for each target system that you have connected to using SSL. -</p> -<h2>Setting Up The Server</h2> -<p> -You set up the DStore server to use SSL by editing the <code>ssl.properties</code> file in the -server location. This server names the keystore and its password used for holding certificates -generated using the <code>keytool</code> utility from the Java SDK. -These certificates are then given to the client during SSL -startup so that communications can be encrypted. -</p> -<p> -The keystore file referenced by <code>ssl.properties</code> can contain several entries but only one is -used when a client connects. The entries in the keystore may themselves have passwords, but dstore assumes -that these are all the same as the keystore password. It makes sense, therefore, to maintain only -one keystore for the dstore server, that it have only one entry, and that it exist in the same -directory as the dstore server. That entry can be a self-signed certificate. -</p> -<p> -The following command will create a keystore and add a single self-signed certificate to it. -</p> -<pre><code> -keytool -genkey -keystore keystore_file -alias entry_name -storepass d98kMn50sV - -dname "CN=dstore server, OU=division, O=company, L=city, ST=state, C=country" -</code></pre> -<p> -The command would be entered on a single line. It appears here on multiple lines for readability. -</p> -<p> -After entering this command you will be prompted to supply a password for the entry itself. -You should press enter to take the default which is the keystore password. -</p> -<p> -One would then edit the ssl.properties file to use this as follows: -</p> -<pre><code> -daemon_keystore_file=keystore_file -daemon_keystore_password=d98kMn50sV -</code></pre> -</body> -</html> |