Certificates and Authentication
Appendix
B
Introduction to Public-Key Cryptography
245
two assumptions are true only if unauthorized personnel have not gained access to
the user’s machine or password, the password for the client software’s private key
database has been set, and the software is set up to request the password at
reasonable frequent intervals.
These are the steps shown in Figure B-5:
1.
The client software, such as Communicator, maintains a database of the private
keys that correspond to the public keys published in any certificates issued for
that client. The client asks for the password to this database the first time the
client needs to access it during a given session—for example, the first time the
user attempts to access an SSL-enabled server that requires certificate-based
client authentication. After entering this password once, the user doesn’t need
to enter it again for the rest of the session, even when accessing other
SSL-enabled servers.
2.
The client unlocks the private-key database, retrieves the private key for the
user’s certificate, and uses that private key to digitally sign some data that has
been randomly generated for this purpose on the basis of input from both the
client and the server. This data and the digital signature constitute “evidence”
of the private key’s validity. The digital signature can be created only with that
private key and can be validated with the corresponding public key against the
signed data, which is unique to the SSL session.
3.
The client sends both the user’s certificate and the evidence (the randomly
generated piece of data that has been digitally signed) across the network.
4.
The server uses the certificate and the evidence to authenticate the user’s
identity. (For a detailed discussion of the way this works, see Appendix C,
“Introduction to SSL.”)
5.
At this point the server may optionally perform other authentication tasks,
such as checking that the certificate presented by the client is stored in the
user’s entry in an LDAP directory. The server then continues to evaluate
whether the identified user is permitted to access the requested resource. This
NOTE
Neither password-based authentication nor certificate-based
authentication address security issues related to physical access to
individual machines or passwords. Public-key cryptography can
only verify that a private key used to sign some data corresponds to
the public key in a certificate. It is the user’s responsibility to
protect a machine’s physical security and to keep the private-key
password secret.
Summary of Contents for NETSCAPE CONSOLE 6.0 - MANAGING SERVERS
Page 1: ...Managing Servers with Netscape Console Netscape Console Version6 0 December 2001 ...
Page 18: ...Getting Additional Help 18 Managing Servers with Netscape Console December 2001 ...
Page 20: ...20 Managing Servers with Netscape Console December 2001 ...
Page 40: ...Uninstallation 40 Managing Servers with Netscape Console December 2001 ...
Page 42: ...42 Managing Servers with Netscape Console December 2001 ...
Page 80: ...Working with Netscape Servers 80 Managing Servers with Netscape Console December 2001 ...
Page 110: ...110 Managing Servers with Netscape Console December 2001 ...
Page 118: ...The Netscape Administration Page 118 Managing Servers with Netscape Console December 2001 ...
Page 166: ...166 Managing Servers with Netscape Console December 2001 ...
Page 208: ...Using Client Authentication 208 Managing Servers with Netscape Console December 2001 ...
Page 226: ...Using the Windows NT SNMP Service 226 Managing Servers with Netscape Console December 2001 ...
Page 228: ...228 Managing Servers with Netscape Console December 2001 ...
Page 264: ...Managing Certificates 264 Managing Servers with Netscape Console December 2001 ...
Page 280: ...The SSL Handshake 280 Managing Servers with Netscape Console December 2001 ...
Page 302: ...302 Managing Servers with Netscape Console December 2001 ...
