mirrors/cdt
1
0
Fork 0
mirror of https://github.com/eclipse-cdt/cdt synced 2025-07-03 23:25:26 +02:00
Code Issues Wiki Activity

[154508] updated users guide on using SSL

Browse source
This commit is contained in:
David Dykstal 2007-06-20 01:35:21 +00:00
parent 657cb0d400
commit ec5d25d7be
1 changed files with 56 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

70
rse/doc/org.eclipse.rse.doc.user/tasks/tworkssl.html
View file

@ -11,36 +11,78 @@
<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
<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 also use SSL and request SSL certificates from their servers to communicate with
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>
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
<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 if you are curious you can use the RSE SSL preferences
page to manage all your certificates that you use with RSE.</p>
<p>You reach the RSE preferences page by opening the <code> Preferences</code>for the workbench,
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>
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
<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 java SDK keytool. These certificates are then given to the client during SSL
startup so that communications can be encrypted.</p>
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>