This chapter describes how WebLogic Server 12.1.3 ensures that each certificate in a certificate chain was issued by a certificate authority. All X509 V3 CA certificates used with WebLogic Server must have the Basic Constraint extension defined as CA, thus ensuring that all certificates in a certificate chain were issued by a certificate authority. By default, any certificates for certificate authorities not meeting this criteria are rejected. This chapter describes the command-line argument that controls the level of certificate validation.
This chapter includes the following sections:
Notes:
Note the following:Weblogic Server uses RSA Cert-J 3.1 for certain certificate processing.
If WebLogic Server is booted with a certificate chain that will not pass the certificate validation, an information message is logged noting that clients could reject it.
By default WebLogic Server rejects any certificates in a certificate chain that do not have the Basic Constraint extension defined as CA. However, you may be using certificates that do not meet this requirement or you may want to increase the level of security to conform to the IETF RFC 2459 standard. Use the following command-line argument to control the level of certificate validation performed by WebLogic Server:
-Dweblogic.security.SSL.enforceConstraints=option
Table 35-1 describes the options for the command-line argument.
Table 35-1 Options for -Dweblogic.security.SSL.enforceConstraints
| Option | Description |
|---|---|
|
|
Use this option to ensure that the Basic Constraints extension on the CA certificate is defined as CA. For example: -Dweblogic.security.SSL.enforceConstraints=strong or -Dweblogic.security.SSL.enforceConstraints=true By default, WebLogic Server performs this level of certificate validation. |
strong_nov1cas |
Functions the same as the For example: -Dweblogic.security.SSL.enforceConstraints=strong_nov1cas |
strict |
Use this option to ensure the Basic Constraints extension on the CA certificate is defined as CA and set to critical. This option enforces the IETF RFC 2459 standard. For example: -Dweblogic.security.SSL.enforceConstraints=strict This option is not the default because a number of commercially available CA certificates do not conform to the IETF RFC 2459 standard. |
strict_nov1cas |
Functions the same as the For example: -Dweblogic.security.SSL.enforceConstraints=strict_nov1cas |
off |
Use this option to turn off checking for the Basic Constraints extension. The rest of the certificate is still validated. For example: -Dweblogic.security.SSL.enforceConstraints=off Oracle does not recommend using this option in a production environment. Instead, purchase new CA certificates that comply with the IETF RFC 2459 standard. CA certificates from most commercial certificate authorities should work with the default strong option. |
WebLogic Server offers limited support for Certificate Policy Extensions in X.509 certificates. Use the weblogic.security.SSL.allowedcertificatepolicyids argument to provide a comma separated list of Certificate Policy IDs. When WebLogic Server receives a certificate with a critical Certificate Policies Extension, it verifies whether any Certificate Policy is on the list of allowed certificate policies and whether there are any unsupported policy qualifiers. This release of WebLogic Server supports Certification Practice Statement (CPS) Policy qualifiers and does not support User Notice qualifiers. A certificate is also accepted if it contains a special policy anyPolicy with the ID 2.5.29.32.0, which indicates that the CA does not wish to limit the set of policies for this certificate.
Note:
Theweblogic.security.SSL.allowedcertificatepolicyids argument is currently not supported in WebLogic Server when the JSSE-based SSL implementation is enabled.To enable acceptance of Certificate Policies, start WebLogic Server with the following argument:
-Dweblogic.security.SSL.allowedcertificatepolicyids <identifier1>,<identifier2>,...
This argument should contain a comma-separated list of Certificate Policy identifiers for all the certificates with critical extensions that might be present in the certificate chain, back to the root certificate, in order for WebLogic Server to accept such a certificate chain.
Use the WebLogic Server ValidateCertChain command-line utility to confirm whether an existing certificate chain will be rejected by WebLogic Server. The utility validates certificate chains from PEM files, PKCS-12 files, PKCS-12 keystores, and JKS keystores. A complete certificate chain must be used with the utility. The following is the syntax for the ValidateCertChain command-line utility:
java utils.ValidateCertChain -file pemcertificatefilename java utils.ValidateCertChain -pem pemcertificatefilename java utils.ValidateCertChain -pkcs12store pkcs12storefilename java utils.ValidateCertChain -pkcs12file pkcs12filename password java utils.ValidateCertChain -jks alias storefilename [storePass]
Example of valid certificate chain:
java utils.ValidateCertChain -pem zippychain.pem Cert[0]: CN=zippy,OU=FOR TESTING ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US Cert[1]: CN=CertGenCAB,OU=FOR TESTING ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US Certificate chain appears valid
Example of invalid certificate chain:
java utils.ValidateCertChain -jks mykey mykeystore Cert[0]: CN=corba1,OU=FOR TESTING ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US CA cert not marked with critical BasicConstraint indicating it is a CA Cert[1]: CN=CACERT,OU=FOR TESTING ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US Certificate chain is invalid
WebLogic Server SSL has built-in certificate validation. Given a set of trusted CAs, this validation:
Verifies that the last certificate in the chain is either a trusted CA or is issued by a trusted CA.
Completes the certificate chain with trusted CAs.
Verifies the signatures in the chain.
Ensures that the chain has not expired.
You can use certificate lookup and validation (CLV) providers to perform additional validation on the certificate chain. WebLogic Server includes two CLV providers:
WebLogic CertPath Provider—Completes certificate paths and validates certificates using the trusted CA configured for a particular server instance, providing the same functionality as the built-in SSL certificate validation. This is configured by default.
Certificate Registry—The system administrator makes a list of trusted CA certificates that are allowed access to the server; a certificate is valid if the end certificate is in the registry. The administrator revokes a certificate by removing it from the certificate registry, which is an inexpensive mechanism for performing revocation checking. This is not configured by default.
Alternatively, you can write a custom CertPathValidator to provide additional validation on the certificate chain. See "CertPath Providers" in Developing Security Providers for Oracle WebLogic Server.
Outbound SSL and two-way inbound SSL in a WebLogic Server instance receive certificate chains during the SSL handshake that must be validated. An example of two-way inbound SSL is a browser connecting to a Web application over HTTPS where the browser sends the client's certificate chain to the Web application. The inbound certificate validation setting is used for all two-way client certificate validation in the server.
Examples of WebLogic Server using outbound SSL (that is, acting as an SSL client) include:
Connecting to the Node Manager
Connecting to another WebLogic Server instance over the Administration port
Connecting to an external LDAP server, such as the LDAPAuthenticator
Using any of the administration tools listed in "Summary of System Administration Tools and APIs" in Understanding Oracle WebLogic Server, you can independently configure inbound and outbound SSL certificate validation using these SSLMBean attributes: InboundCertificateValidation and OutboundCertificateValidation.
Legal values for both attributes are:
BUILTIN_SSL_VALIDATION: Use the built-in SSL certificate validation code to complete and validate the certificate chain. That is, configure SSL to work as it has in previous releases. This is the default behavior.
BUILTIN_SSL_VALIDATION_AND_CERT_PATH_VALIDATORS: Use the built-in trusted CA-based validation and the configured CertPathValidator providers to perform additional validation. That is, configure SSL to work as it has in previous releases and to do extra validation.
See:
"SSLMBean" in the MBean Reference for Oracle WebLogic Server
"Set Up SSL" in the Oracle WebLogic Server Administration Console Online Help
If SSL communications that worked properly in a previous release of WebLogic Server start failing unexpectedly, the likely problem is that the certificate chain is failing the validation.
Determine where the certificate chain is being rejected, and decide whether to update the certificate chain with one that will be accepted, or change the setting of the -Dweblogic.security.SSL.enforceConstraints command-line argument.
To troubleshoot problems with certificates, use one of the following methods:
If you know where the certificate chains for the processes using SSL communication are located, use the ValidateCertChain command-line utility to check whether the certificate chains will be accepted.
Turn on SSL debug tracing on the processes using SSL communication. The syntax for SSL debug tracing is:
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
Note:
Additional detailed debug logging may be enabled using the following command-line property:-Djavax.net.debug=all
For more information, see Command-Line Properties for Enabling SSL Debugging.
The following message indicates the SSL failure results from problems in the certificate chain:
<CA certificate rejected. The basic constraints for a CA certificate were not marked for being a CA, or were not marked as critical>
When you use one-way SSL, look for this error in the client log. With two-way SSL, look for this error in the client and server logs.