Filter
Top Products
Chapter 3 System Preparation
HPSS Installation Guide September 2002 193
Release 4.5, Revision 2
you can pay to issue X.509 certificates to you. Certificates can also be created by individuals and
self-signed by the party owning the certificate. A program uses a file of these certificates as its
"trusted store", the set of certificates of parties it will trust.
Whereas a digitalsignature confirms that the issuingparty possesses the private key corresponding
to a particular public key, a certificate confirms that some verification has been done as to the
identity of its owner. After all, anyone can generate a public/private key pair, publish the public
key, and claim to be User X or Company Y. A certificate proves that some verification has been done
(by the certificate authority) to insure that the party really is User X or Company Y, and it binds the
party to his public key. If you pay a company like Verisign for a certificate, they contact you and
follow some procedures to ascertain that you really are who you claim to be.
The validity of a certificate itself can be verified by a checksum called a fingerprint. Before the
system administrator places a certificate in his trusted store, he checks its fingerprint against the
known value for that certificate. For certificates from authorities like Verisign, these fingerprints are
published somewhere, like a web page. For self-signed certificates, the administrator gets the
fingerprint from the certificate owner/creator, who of course should be someone the administrator
trusts.
When one program presents its certificate to a second program, the second program checks its
trusted store for the certificate. If it is there, then the second program assumes the first program is
really who he claims to be. More often, the certificate of the first program is not in the trusted store,
but it is signed by a certificate authority whose certificate IS in the trusted store. You can also have
chains of certificates: a certificate is signed by an authority whose certificate is signed by an
authority whose certificate is in the trusted store. So long as the second program can find a
certificate in the chain which is in his trusted store, he can trust the certificate owner. This chaining
ability was designed to allow systems to verify certificates from many arbitrary parties, without
having to import each of their certificates individually (which would involve manually verifying
their fingerprints).
SSL uses X.509 certificates to identify the server (in our case, the SSM Data Server) to the client (in
our case, the hpssadm utility). Then the client generates a secret piece of data and passes it to the
server using the server's public key. The client and server use this initial secret piece of data to
negotiate a new shared symmetric key, and then use the symmetric key for the remainder of the
session.
Java stores keys and certificates in files called keystores. The keystore file is password-protected;
even if you have read-access to the file, you can't get the key out unless you know this password.
SSL requires that the server be able to obtain his private key, so he must know this password. This
means that the server must be started manually and allow a user to type in this password, or that
the password must be stored online somewhere. The SSM Data Server may be executed either way;
in Low Security mode, the password to the keystore is stored on a file on the Data Server's machine
and read by the Data Server at startup time. In Normal Security mode, the Data Server prompts for
the password at the beginning of execution.
The Data Server and the hpssadm utility are connected by two RMI (Java Remote Method
Invocation) sessions. In the first session, the Data Server acts as the server and hpssadm acts as the
client. This is the session on which all hpssadm requests, such as to start or stop servers, force
migrations, or lock devices are issued. It is also the session over which the hpssadm user's
password is transferred to the Data Server. This session uses SSL underneath RMI to encrypt the
entire connection, not just the password.
In the second session, the hpssadm utility acts as the server and the Data Server acts as the client.
This is the session used by the Data Server to send asynchronous data change notifications to the