mirror of
https://github.com/eclipse-cdt/cdt
synced 2025-07-08 17:45:24 +02:00
47 lines
3.2 KiB
HTML
47 lines
3.2 KiB
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">
|
||
|
|
<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 also 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 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,
|
||
|
|
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 java SDK keytool. These certificates are then given to the client during SSL
|
||
|
|
startup so that communications can be encrypted.</p>
|
||
|
|
</body>
|
||
|
|
</html>
|