Authentication Keystores

The Sun N1 Service Provisioning System 5.2 supports self-signed certificates and certificates signed by a Certifying Authority. Two types of keystores exist:

• Private Keystore – The private keystore contains the public-private key pairs that the application uses to authenticate itself when connecting to other applications.

• Trust Keystore – The trust keystore contains the public key, in self-signed certificates, of other applications that the keystore trusts and allows them to connect to the application.

When enabling SSL for client-server authentication, each enabled application needs to be configured with two keystores that SSL will use to authenticate itself to other applications and to authenticate other applications.

When enabling SSL for server-only authentication, the application acting as the SSL server requires a private keystore and the application acting as the SSL client requires a public, or trusted, keystore. The public keystores are in the proprietary JKS format provided by the Java Secure Sockets Extension (JSSE) v1.0.3.

You must specify a password for both of the keystores. The password for both of the keystores must be the same.

For example, application A, an SSL client, and application B, an SSL server, want to connect with each other using SSL. Both are configured to use a cipher suite that requires server authentication. Application B must have a public-private key pair in its private keystore, and application A must have application B's public key in its trust keystore. When application A attempts to connect to application B, application B sends its public key down to application A. Application A is able to verify the public key by finding it in its trust keystore.

If application B is configured to require client authentication, application A must have a public-private key pair in its private keystore. Also, application B must have application A's public key in its trust keystore. After application A has authenticated application B, application B is able to verify application A's public key, as it finds the public key in its trust keystore.

When you generate a keystore using the crkeys command, you use the -mode upstream|downstream option to specify the location of the machine that is being authenticated in relationship to the machine that is performing the authentication. When attempting an SSL connection, the server that is validating the connection verifies that the certificate it received contains a mode that matches the relative location of the server that transmitted the certificate. For example, a Local Distributor receives an SSL connection request from a Master Server. The Local Distributor verifies that the Master Server certificate does not have a downstream annotation.

The server does not verify that a certificate contains an upstream annotation. The server only verifies that the certificate does not have a downstream annotation. Consequently, any servers that were originally configured to use SSL without an upstream annotation will continue to connect using SSL.

A CLI client cannot validate a connection with a server that transmits a certificate with an upstream annotation because no server can be upstream from a CLI client. A Remote Agent cannot validate a connection with a server that transmits a certificate with a downstream annotation because no server can be downstream from a Remote Agent.