+

Search Tips   |   Advanced Search

Trust manager control of X.509 certificate trust decisions


The role of the trust manager is to validate the SSL certificate that is sent by the peer, which includes verifying the signature and checking the expiration date of the certificate. A JSSE (JSSE) trust manager determines if the remote peer can be trusted during an SSL handshake.

WAS has the ability to call multiple trust managers during an SSL connection. The default trust manager does the standard certificate validation; custom trust manager plug-ins run customized validation such as host name verification.

See Example: Developing a custom trust manager for custom SSL trust decisions

When a trust manager is configured in a server-side SSL configuration, the server calls the isClientTrusted method. When a trust manager is configured in a client-side SSL configuration, the client calls the isServerTrusted method. The peer certificate chain is passed to these methods. If the trust manager chooses not to trust the peer information, it might produce an exception to force a handshake failure.

Optionally, WAS provides the com.ibm.wsspi.ssl.TrustManagerExtendedInfo interface so that additional information can be passed to the trust manager.

See the com.ibm.wsspi.ssl.TrustManagerExtendedInfo interface.

 

Default IbmX509 trust manager

The default IbmX509 trust manager, which is used in the following code sample, establishes trust by performing standard certificate validation. 

<trustManagers xmi:id="TrustManager_1132357815717" name="IbmX509" provider="IBMJSSE2" 
algorithm="IbmX509" managementScope="ManagementScope_1132357815717"/>
The trust manager provides a signer certificate to verify the peer certificate that is sent during the handshake. The signers who are added to the truststore for the SSL configuration must be trustworthy. If we do not trust the signers or do not want to allow others to connect to the servers, consider removing default root certificates from certificate authorities (CA). We might also remove any certificates if we cannot verify their origination.

 

Default IbmPKIX trust manager

Use the default IbmPKIX trust manager to replace the IbmX509 trust manager, which is shown in the following code sample: 

<trustManagers xmi:id="TrustManager_1132357815719" name="IbmPKIX" provider="IBMJSSE2" 
algorithm="IbmPKIX" trustManagerClass="" managementScope="ManagementScope_1132357815717">
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_1132357815717"  name="com.ibm.security.enableCRLDP" value="true" type="boolean"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_1132357815718"  name="com.ibm.jsse2.checkRevocation" value="true" type="boolean"/>
  </trustManagers>

<trustManagers xmi:id="TrustManager_managementNode_2" name="IbmPKIX" provider=
"IBMJSSE2" algorithm="IbmPKIX" trustManagerClass=""  managementScope="ManagementScope_managementNode_1">
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_1" name="com.ibm.se curity.enableCRLDP" value="false" type="boolean" displayNameKey="" nlsRangeKey="
" hoverHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_2" name="com.ibm.js se2.checkRevocation" value="false" type="boolean" displayNameKey="" nlsRangeKey=
"" hoverHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_3" name="ocsp.enabl e" value="false" type="String" displayNameKey="" nlsRangeKey="" hoverHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_4" name="ocsp.respo nderURL" value="http://ocsp.example.net:80" type="String" displayNameKey=""  nlsRangeKey="" hoverHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_5" name="ocsp.respo nderCertSubjectName" value="" type="String" displayNameKey="" nlsRangeKey="" hov erHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_6" name="ocsp.respo nderCertIssuerName" value="" type="String" displayNameKey="" nlsRangeKey="" hove rHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_7" name="ocsp.respo nderCertSerialNumber" value="" type="String" displayNameKey="" nlsRangeKey="" ho verHelpKey="" range="" inclusive="false" firstClass="false"/>
</trustManagers>

See Example: Enabling certificate revocation checking with the default IbmPKIX trust manager for additional information in using the default IbmPKIX trust manager.

In addition to its role of standard certificate verification, the IbmPKIX trust manager checks for OCSP properties and for certificates that contain certificate revocation list (CRL) distribution points. This process is known as extended CRL checking. When you select a trust manager, its associated properties are automatically set as Java System properties so that the IBMCertPath and IBMJSSE2 providers are aware that CRL checking is enabled.

 

Custom trust manager

We can define a custom trust manager to perform additional trust checking, which is based upon the needs of the environment. For example, in one environment, we might enable connections from the same Transmission Control Protocol (TCP) subnet only. The com.ibm.wsspi.ssl.TrustManagerExtendedInfo interface provides extended information about the connection not provided by the standard JSSE javax.net.ssl.X509TrustManager interface. The configured trustManagerClass attribute determines which class is instantiated by the runtime, as shown in the following code sample: 

<trustManagers xmi:id="TrustManager_1132357815718" name="CustomTrustManager"  trustManagerClass="com.ibm.ws.ssl.core.CustomTrustManager"  managementScope="ManagementScope_1132357815717"/>

The trustManagerClass attribute must implement the javax.net.ssl.X509TrustManager interface and, optionally, can implement the com.ibm.wsspi.ssl.TrustManagerExtendedInfo interface.

 

Disable the default trust manager

In some cases, we might not want to perform the standard certificate verification that is provided by the IbmX509 and IbmPKIX default trust managers. For example, you might be working with an internal automated test infrastructure not concerned with SSL client or server authentication, integrity, or confidentiality.

The following sample code shows a basic custom trust manager such as com.ibm.ws.ssl.core.CustomTrustManager whose property is set to true. 

com.ibm.ssl.skipDefaultTrustManagerWhenCustomDefined=true
You can set this property in the global properties at the top of the ssl.client.props file for clients or in the security.xml custom properties file for servers. You must configure a custom trust manager when you disable the default trust manager to prevent the server from calling the default trust manager even though it is configured. Disabling the default trust manager is not a common practice. Be sure to test the system with the disabled default trust manager in a test environment first.

See on setting up a custom trust manager, see Create a custom trust manager configuration for SSL


 

Related concepts


SSL configurations