rse/doc/org.eclipse.rse.doc.user/tasks/tworkssl.html - tm/org.eclipse.tm - Git at Google

 <?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" lang="en">
 <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>
 <div role="main">
 <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>
 </div>
 </body>
 </html>
	<?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" lang="en">
	<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>
	<div role="main">
	<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>
	</div>
	</body>
	</html>