33 SSL Certificate Validation

Oracle WebLogic Server ensures that each certificate in a certificate chain was issued by a certificate authority. All X.509 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.


  • Weblogic Server uses RSA Cert-J 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.

This chapter includes the following sections:

Controlling the Level of Certificate Validation

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. You can use a command-line argument to control this level of certificate validation.

Use the following command-line argument to control the level of certificate validation performed by WebLogic Server:


Table 33-1 describes the options for the command-line argument.

Table 33-1 Options for -Dweblogic.security.SSL.enforceConstraints

Option Description

strong or true

Use this option to ensure that the Basic Constraints extension on the CA certificate is defined as CA.

For example:




By default, WebLogic Server performs this level of certificate validation.


Functions the same as the strong option, described in the preceding row, with the additional constraint that X.509 version 1 CA certificates are rejected.

For example:



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:


This option is not the default because a number of commercially available CA certificates do not conform to the IETF RFC 2459 standard.


Functions the same as the strict option, described in the preceding row, with the additional constraint that X.509 version 1 CA certificates are rejected.

For example:



Use this option to turn off checking for the Basic Constraints extension. The rest of the certificate is still validated.

For example:


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.

Accepting Certificate Policies in Certificates

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, which indicates that the CA does not wish to limit the set of policies for this certificate.


The weblogic.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.

Checking Certificate Chains

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


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

Using Certificate Lookup and Validation Providers

WebLogic Server SSL has built-in certificate validation which performs validation on the certificate chain. WebLogic Server includes two certificate lookup and validation (CLV) providers to perform additional validation on the certificate chain.

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.

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.

How SSL Certificate Validation Works in 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.


  • SSLMBean in the MBean Reference for Oracle WebLogic Server

  • Set Up SSL in the Oracle WebLogic Server Administration Console Online Help

Troubleshooting Problems with Certificate Validation

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 to a certificate chain 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


    Additional detailed debug logging may be enabled using the following command-line property:


    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.