Secure communications using SSL
SSL provides transport layer security including...
- data signing
- data encryption
SSL uses public key cryptography to guarantee that when an entity encrypts data using its public key, only entities with the corresponding private key can decrypt that data. WAS uses JSSE as the SSL implementation to handle handshake negotiation and protection capabilities. JSSE is part of the J2SE specification.
X.509 certificate contents, including distinguished name and expiration, are signed by any of the following...
- Certificate authority (CA)
- Root certificate in NodeDefaultRootStore or DmgrDefaultRootStore
X.509 certs use session-based secret keys to encrypt blocks of data.
- CA-signed X.509 certs are identified and freely distributed by WAS and represent the identity of an entity to the general public. Server-side ports accepting connections from the general public must use CA-signed certs. Most clients or browsers already have the signer certificate that can validate the X.509 certificate so signer exchange is not necessary for a successful connection.
- Self-signed X.509 certs are trusted only when a peer in a controlled environment accepts the signer certificate. To complete a trusted handshake, first send a copy of the entity certificate to every peer that connects to the entity.
All certs reside in Java keystores and truststores...
keystore Personal certs consisting of public and private keys. truststore Signer certs consisting of public keys
Public keys verify the signature of the identity received during a handshake.
We exchange signers to establish trust in an entity's personal certificate. Signer exchange extracts X.509 certs from peer keystores and adds them into the truststore of another entity. An SSL configuration determines which entities can connect to other entities, and the peer connections that are trusted by an SSL handshake. If we do not have the necessary signer certificate, the handshake fails because the peer cannot be trusted.
The signer certificate can originate from a CA as a...
- root signer certificate
- chained certificate's root signer certificate
- intermediate signer certificate
We can also extract a signer certificate directly from a self-signed certificate.
Private CAs and self-signed certs allow you to isolate the connections that you want to occur and prevent those that you do not want to occur.
An SSL configuration creates SSLContext objects used to obtain SSL socket factories. Attributes include...
- Alias for the SSLContext object
- Handshake protocol version
- Keystore reference
- Truststore reference
- Key manager
- One or more trust managers
- Security level selection of a cipher suite
- Certificate alias choice for client and server connections
We can select an SSL configuration using one of the following approaches:
Programmatic Set an SSL configuration on the running thread prior to an outbound connection. Dynamic Use a predefined selection criteria to associate an SSL configuration dynamically with a specific target host, port, or outbound protocol. Direct Select an SSL configuration using a specific alias. Scope Endpoints are located in one topology view of the cell.
With scope selection, the inheritance relationship between scopes reduces the number of SSL configuration assignments that set. Unless you override a specific configuration, the topology relies on the rules of inheritance from the cell level down to the endpoint level for each appserver.
The topology view displays an inbound tree and outbound tree. We can make different SSL configuration selections for each side of the SSL connection based on what that server connects to as an outbound connection and what the server connects to as an inbound connection.
SSL order of precedence
The runtime uses an order of precedence for determining which SSL configuration to choose...
- Programmatic selection.
If an application sets an SSL configuration on the running thread using the API...
...the SSL configuration is guaranteed the highest precedence.
- Dynamic selection criteria for outbound host and port or protocol.
- Direct selection.
- Scope selection.
Scope inheritance guarantees that the endpoint that you select is associated with an SSL configuration and is inherited by every scope beneath it that does not override this selection.
Default chained certificate configuration
By default, WAS creates a unique chained certificate for each node. The chained certificate is signed with a root, a self-signed certificate stored in either...
The following defaults are stored in the configuration repository within the node directory...
- key.p12 (keystore)
- trust.p12 (truststore)
- root-key.p12 (default root certificate)
Nodes put their signer certs from the root-key.p12 into trust.p12. After federating a node, the default SSL configuration is automatically modified to point to the common truststore, located in the cell directory. The node can now communicate with all other servers in the cell.
All default SSL configurations contain a keystore and truststore with suffixs DefaultKeyStore and DefaultTrustStore, and a rootstore with the suffix DefaultRootStore. These default suffixes instruct the WAS runtime to add the root signer of the personal certificate to the common truststore. If a truststore name does not end with DefaultKeyStore, the keystores root signer certs are not added to the common truststore when you federate the server.
Certificate expiration monitoring
Certificate monitoring ensures that the default chained certificate for each node is not allowed to expire, issuing warnings before certs and signers are set to expire. A chained certificate or self-signed certificate can be automatically recreated based on the same data used for the initial creation.
The monitor also can automatically replace old signers with the signers from the new chained or self-signed certs in keystores that are managed by WAS. The existing signer exchanges that occurred by the runtime during federation and by administration are preserved.
The expiration monitor is configured to replace chained personal certs that are signed by a root certificate in...
The certificate is renewed using the same root certificate that was used to sign the original certificate. The monitor also can automatically replace old signers with the signers from the new self-signed certs in keystores that are managed by WAS. The existing signer exchanges that occurred by the runtime during federation and by administration are preserved.
Signer exchange requirements
A new chained certificate is generated for each node during its initial startup. To ensure trust, clients must be given the root signers to establish a connection. Rather than exchanging the signer of a short lived self-signed certificate, we can exchange the long lived root signer, which allows for preserved trust across personal certificate renewals.
Options for gaining access to the signer certs of various nodes to which the client must connect include...
- A signer exchange prompt enables you to import signer certs that into the truststores.
By default, this prompt is enabled for admin connections and can be enabled for any client SSL configuration. When this prompt is enabled, any connection that is made to a server where the signer is not already present offers the signer of the server along with the certificate information and a Secure Hash Algorithm (SHA) digest of the certificate for verification. The user is given a choice whether to accept these credentials. If the credentials are accepted, the signer is added to the truststore of the client until the signer is explicitly removed. The signer exchange prompt does not occur again when connecting to the same server unless the personal certificate changes.
It is unsafe to trust a signer exchange prompt without verifying the SHA digest. An unverified prompt can originate from a browser when a certificate is not trusted.
- Run retrieveSigners from a client prior to making connections to servers.
To download signers, no administrative authority is required. To upload signers, have Administrator role authority. The script downloads all of the signers from a specified server truststore into the specified client truststore and can be called to download only a specific alias from a truststore. We can also call the script to upload signers to server truststores. When we select the CellDefaultTrustStore truststore as the specified server truststore and common truststore for a cell, all of the signers for that cell are downloaded to the specified client truststore, which is typically ClientDefaultTrustStore.
- Physically distribute to clients the trust.p12 common truststore located in the cell directory of the configuration repository.
Specify password in the client ssl.client.props file. The default password for this truststore is WebAS. Note that when changes are made to the personal certs on the server, automated exchange can fail.
Dynamic SSL configuration changesThe SSL runtime for WAS maintains listeners for most SSL connections. A change to the SSL configuration runtime causes the inbound connection listeners to create a new SSLContext object. Existing connections continue to use the current SSLContext object. Outbound connections automatically use the new configuration properties when they are attempted. Changes take effect when the new security.xml file reaches each node.
If configuration changes cause SSL handshake failures, admin connectivity failures also can occur, which can lead to outages. In this case, re-configure the SSL connections then perform manual node synchronization to correct the problem. You must carefully complete any dynamic changes. It is highly recommended that you perform changes to SSL configurations on a test environment prior to making the same changes to a production system.
Built-in certificate managementCertificate management that is comparable to iKeyMan functionality is now integrated into the keystore management panels of the admin console. Use built-in certificate management to manage...
- Personal certs
- Certificate requests
- Signer certs
For example, we can manage a file-based keystore that is located outside the configuration repository on any node from the dmgr. We also can remotely manage hardware cryptographic keystores from the dmgr.
With built-in certificate management, we can replace a chained or self-signed certificate along with all of the signer certs scattered across many truststores and retrieve a signer from a remote port by connecting to the remote SSL host and port and intercepting the signer during the handshake. The certificate is first validated according to the certificate SHA digest, then the administrator must accept the validated certificate before it can be placed into a truststore. When we make a certificate request, we can send it to a certificate authority (CA). When the certificate is returned, we can accept it within the admin console.
iKeyMan still ships with WAS and is still an alternative to the admin console.
AdminTask configuration management
The SSL configuration management panels in the admin console rely primarily on admin tasks. Use wsadmin commands to automate the management of keystores, SSL configurations, certs, and so on.
Keystore configurations for SSL
Dynamic outbound selection of SSL configurations
Central management of SSL configurations
SSL node, appserver, and cluster isolation
Default chained certificate configuration in SSL
Dynamic configuration updates in SSL
Management scope configurations
Certificate management using iKeyman
Certificate management in SSL
Use retrieveSigners to enable server to server trust
Related conceptsTrust manager control of X.509 certificate trust decisions
Key manager control of X.509 certificate identities