[Sblim-commit] jsr48-client/src/org/sblim/cimclient/doc-files secure_indications.html, 1.1.2.2, 1.1.2.3

[Dave H. <hel...@us...>]

Update of /cvsroot/sblim/jsr48-client/src/org/sblim/cimclient/doc-files
In directory vz-cvs-3.sog:/tmp/cvs-serv23875/src/org/sblim/cimclient/doc-files

Modified Files:
      Tag: Experimental
	secure_indications.html 
Log Message:
3536399 - fix SSLConfigurationTest bugs

Index: secure_indications.html
===================================================================
RCS file: /cvsroot/sblim/jsr48-client/src/org/sblim/cimclient/doc-files/Attic/secure_indications.html,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -d -r1.1.2.2 -r1.1.2.3
--- secure_indications.html	27 Aug 2012 00:02:22 -0000	1.1.2.2
+++ secure_indications.html	27 Aug 2012 21:52:20 -0000	1.1.2.3
@@ -74,7 +74,7 @@
      <li><em>sblim.wbem.sslListenerPeerVerification</em>: Determines how a HTTPS listener will handle authentication of a client (i.e. indication sender). If set to ignore, no SSL authentication (peer verification) will be performed. If set to require, the listener will attempt to verify the server certificate against the contents of the truststore defined in &quot;javax.net.ssl.trustStore&quot; and will fail the connection if the certificate cannot be verified.  If set to accept, the listener will request the sender to present a certificate, but will not fail the connection even if an untrusted certificate is presented (this setting is of little practical value).</li>
    </ul>
 
-<p>If the truststore properties are set but <code>sslListenerPeerVerification</code> is <code>ignore</code>, the truststore is not activated and all connections will be allowed (i.e. every sender is trusted). The only real use of this configuration is to temporarily disable the truststore for testing.  Conversely, if <code>sslListenerPeerVerification</code> is <code>require</code> but the truststore properties are not set (or the truststore file is missing or otherwise unreadable), no connections will be allowed (i.e. no listener is trusted), as this is considered to be a misconfiguration.  In both cases, a WARNING message is sent to the logger. (Note: <code>sslListenerPeerVerification=accept</code> behaves like <code>require</code> but the connection will not actually fail in this case.)</p>
+<p>If the truststore properties are set but <code>sslListenerPeerVerification</code> is <code>ignore</code>, the truststore is not activated and all connections will be allowed (i.e. every sender is trusted). The only real use of this configuration is to temporarily disable the truststore for testing.  Conversely, if <code>sslListenerPeerVerification</code> is <code>require</code> but the truststore properties are not set (or the truststore file is missing or otherwise unreadable), no connections will be allowed (i.e. no sender is trusted), as this is considered to be a misconfiguration.  In both cases, a WARNING message is sent to the logger. (Note: <code>sslListenerPeerVerification=accept</code> behaves like <code>require</code> but the connection will not actually fail in this case.)</p>
 
 <p>As mentioned above, there is a way to set the keystore or truststore properties independently for client and listener, and in this manner it is possible to configure a separate set of keystores for each. However, this cannot be done via the properties file; it can only be done programmatically.  This is described <a href="#independent">here</a>.</p>