+

Search Tips   |   Advanced Search

Web Services - Configure the collection certificate on the server or cell level

Collection certificate stores contain untrusted, intermediary certificate files awaiting validation. We can configure a collection certificate store on the server level.

Validation might consist of checking for a valid signature in a digitally signed SOAP message to see if the certificate is on a certificate revocation list (CRLs), checking that the certificate is not expired, and checking that the certificate is issued by a trusted signer.

In the following steps, use the first step to configure the collection certificate store for the server level and use the second step to configure the collection certificate store for the cell level:


Tasks

  1. Access the default bindings for the server level.

    1. Click Servers > Server Types > WebSphere application servers > server.

    2. Under Security, click JAX-WS and JAX-RPC security runtime.

      Mixed-version environment: In a mixed node cell with a server using WebSphere Application Server version 6.1 or earlier, click Web services: Default bindings for Web Services Security.mixv

  2. Click Security > Web services to access the default bindings on the cell level.

  3. Under Additional properties, click Collection certificate store.

  4. Click New to create a collection certificate store configuration, click Delete to delete an existing configuration, or click the name of an existing collection certificate store configuration to edit its settings. For a new configuration, enter a name in the Certificate store name field. For example, we might name your certificate store sig_certstore.

    The name of the collection certificate store must be unique to the level of the application server. For example, if we create the collection certificate store for the server level, the store name must be unique to the server level. The name specified in the Certificate store name field is used by other configurations to refer to a predefined collection certificate store. WAS searches for the collection certificate store based on proximity.

    For example, if an application binding refers to a collection certificate store named cert1, the Application Server searches for cert1 at the application level before searching the server level and then the cell level.

  5. Specify a certificate store provider in the Certificate store provider field. WAS supports the IBMCertPath certificate store provider. To use another certificate store provider, define the provider implementation in the provider list within the (ZOS) (Dist) install_dir/properties(iSeries) profile_root/properties/java.security file. However, make sure that our provider supports the same requirements of the certificate path algorithm as WAS.

  6. Click OK and Save to save the configuration.

  7. Click the name of our certificate store configuration. After we specify the certificate store provider, specify either the location of a certificate revocation list or the X.509 certificates. However, we can specify both a certificate revocation list and the X.509 certificates for our certificate store configuration.

  8. Under Additional properties, click Certificate revocation lists. For the generator binding, a certificate revocation list (CRL) is used when it is included in a generated security token. For example, a security token might be wrapped in a PKCS#7 format with a CRL. For more information on certificate revocation lists, see Certificate revocation list.

  9. Click New to specify a certificate revocation list path, click Delete to delete an existing list reference, or click the name of an existing reference to edit the path. Specify the fully qualified path to the location where WAS can find your list of certificates that are not valid. WAS uses the certificate revocation list to check the validity of the sender certificate.

    For portability reasons, IBM recommends that we use the WebSphere Application Server variables to specify a relative path to the certificate revocation lists. This recommendation is especially important when we are working in a WAS ND environment.

    For example, we might use the USER_INSTALL_ROOT variable to define a path such as $USER_INSTALL_ROOT/mycertstore/mycrl1 where mycertstore represents the name of our certificate store and mycrl1 represents the certificate revocation list. For a list of supported variables, click Environment > WebSphere variables in the administrative console. The following list provides recommendations for using certificate revocation lists:

    • If CRLs are added to the collection certificate store, add the CRLs for the root certificate authority and each intermediate certificate, if applicable. When the CRL is in the certificate collection store, the certificate revocation status for every certificate in the chain is checked against the CRL of the issuer.

    • When the CRL file is updated, the new CRL does not take effect until you restart the web service application.

    • Before a CRL expires, we must load a new CRL into the certificate collection store to replace the old CRL. An expired CRL in the collection certificate store results in a certificate path (CertPath) build failure.

  10. Click OK and then Save to save the configuration.
  11. Return to the Collection certificate store configuration panel.

  12. Under Additional properties, click X.509 certificates. The X.509 certificate configuration specifies intermediate certificate files used for certificate path validation of incoming X.509-formatted security tokens.

  13. Click New to create an X.509 certificate configuration, click Delete to delete an existing configuration, or click the name of an existing X.509 certificate configuration to edit its settings. If we are creating a new configuration, enter a name in the Certificate store name field.

  14. Specify a path in the X.509 certificate path field. This entry is the absolute path to the location of the X.509 certificate. The collection certificate store is used to validate the certificate path of the incoming X.509-formatted security tokens.

    Use the USER_INSTALL_ROOT variable as part of path name. For example, we might type: $USER_INSTALL_ROOT/etc/ws-security/samples/intca2.cer. Do not use this certificate path for production use. We must obtain our own X.509 certificate from a certificate authority before putting our WAS environment into production.

    Click Environment > WebSphere variables in the administrative console to configure the USER_INSTALL_ROOT variable.

  15. Click OK and then Save to save the configuration.
  16. Return to the Collection certificate store collection panel and click Update run time to update the Web Services Security run time with the default binding information, which is located in the ws-security.xml file. When we click Update run time, the configuration changes made to other web services are also updated in the run time for Web Services Security. Policy sets can only be used with JAX-WS applications. Policy sets cannot be used for JAX-RPC applications.

We have configured the collection certificate store for the server or cell level.


Related:

  • Certificate revocation list