Collection certificate
stores contain untrusted, intermediary
certificate files awaiting validation. You can
configure a collection certificate store on the server level.
About this task
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:
Procedure
- Access the default bindings
for the server level.
- Click .
- 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
- Click to access the default
bindings on the cell level.
- Under Additional
properties, click Collection
certificate store.
- 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. If you are creating a new configuration, enter a name in the
Certificate store name field. For example, you 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 you create the collection certificate store for the
server level, the store name must be unique to the server level. The
name that is specified in the Certificate store name field is used
by other configurations to refer to a predefined collection certificate
store. WebSphere Application Server 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.
- Specify a certificate store provider
in the Certificate
store provider field. WebSphere Application Server supports the IBMCertPath
certificate store provider. To use another certificate store provider,
you must define the provider implementation in the provider list within
the install_dir/propertiesprofile_root/properties/java.security file.
However, make sure that your provider supports the same requirements
of the certificate path algorithm as WebSphere Application Server.
- Click OK and Save to
save the configuration.
- Click the name of your
certificate store configuration. After you specify the
certificate store provider, you must specify
either the location of a certificate revocation list or the X.509
certificates. However, you can specify both a certificate revocation
list and the X.509 certificates for your certificate store configuration.
- 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.
- 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. You must specify the fully qualified
path to the location where WebSphere Application Server can find your
list of certificates that are not valid. WebSphere Application Server uses the certificate
revocation list to check the validity of the sender certificate.
For
portability reasons, it is recommended that you use the WebSphere Application Server variables to specify
a relative path to the certificate revocation lists. This recommendation
is especially important when you are working in a WebSphere Application Server, Network Deployment environment.
For
example, you might use the
USER_INSTALL_ROOT variable to define
a path such as
$USER_INSTALL_ROOT/mycertstore/mycrl1 where
mycertstore represents
the name of your certificate store and
mycrl1 represents
the certificate revocation list. For a list of supported variables,
click 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, you 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.
- Click OK and
then Save to
save the configuration.
- Return to the Collection
certificate store configuration
panel.
- Under Additional properties, click X.509
certificates. The X.509 certificate configuration
specifies intermediate certificate
files that are used for certificate path validation of incoming X.509-formatted
security tokens.
- 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 you are creating
a new configuration, enter a name in the Certificate store name field.
- 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.
You
can use the USER_INSTALL_ROOT variable as part
of path name. For example, you might type: $USER_INSTALL_ROOT/etc/ws-security/samples/intca2.cer.
Do not use this certificate path for production use. You must obtain
your own X.509 certificate from a certificate authority before putting
your WebSphere Application Server environment
into production.
Click in the administrative
console to configure the USER_INSTALL_ROOT variable.
- Click OK and then Save to
save your configuration.
- 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
you 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.
Results
You
have configured the collection certificate store for the server or
cell level.