Managing WebLogic Security Configuring SSL This following sections describe how to configure SSL for WebLogic Server: • • • • • • • • • • • • • • • • • • • Note: This chapter applies to WebLogic Server deployments using the security features in this release of WebLogic Server as well as deployments using Compatibility Security. Configuring SSL is an optional step; however, BEA recommends using SSL in a production environment. SSL: An Introduction Secure Sockets Layer (SSL) provides secure connections by allowing two applications connecting over a network connection to authenticate the other's identity and by encrypting the data exchanged between the applications. Authentication allows a server and optionally a client to verify the identity of the application on the other end of a network connection. Encryption makes data transmitted over the network intelligible only to the intended recipient.

SSL in WebLogic Server is an implementation of the SSL 3.0 and Transport Layer Security (TLS) 1.0 specifications. WebLogic Server supports SSL on a dedicated listen port which defaults to 7002. To establish an SSL connection, a Web browser connects to WebLogic Server by supplying the SSL listen port and the HTTPs schema in the connection URL, for example, Using SSL is computationally intensive and adds overhead to a connection. Avoid using SSL in development environments when it is not necessary.

However, always use SSL in a production environment. Private Keys, Digital Certificates, and Trusted Certificate Authorities Private keys, digital certificates, and trusted certificate authorities establish and verify server identity. SSL uses public key encryption technology for authentication. With public key encryption, a public key and a private key are generated for a server. The keys are related such that data encrypted with the public key can only be decrypted using the corresponding private key and vice versa.

The private key is carefully protected so that only the owner can decrypt messages that were encrypted using the public key. The public key is embedded into a digital certificate with additional information describing the owner of the public key, such as name, street address, and e-mail address. A private key and digital certificate provide identity for the server. The data embedded in a digital certificate is verified by a certificate authority and digitally signed with the certificate authority's digital certificate. Well-know certificate authorities include Verisign and Entrust.net. The trusted certificate authority (CA) certificate establishes trust for a certificate.

Obtaining Pri vate Keys, Digital Certificates, and Trusted Certificate Authorities. To use SSL, the server needs a private key, a digital certificate containing the. Web security tool to make fuzzing at HTTP inputs, made in C with libCurl. You can do: brute force passwords in auth forms; directory disclosure ( use PATH list to.

An application participating in an SSL connection is authenticated when the other party evaluates and accepts the application's digital certificate. Web browsers, servers, and other SSL-enabled applications generally accept as genuine any digital certificate that is signed by a trusted certificate authority and is otherwise valid. For example, a digital certificate can be invalidated because it has expired or the digital certificate of the certificate authority used to sign it expired.

A server certificate can be invalidated if the host name in the digital certificate of the server does not match the URL specified by the client. One-Way and Two-Way SSL SSL can be configured one-way or two-way: • With one-way SSL, the server is required to present a certificate to the client but the client is not required to present a certificate to the server.

To successfully negotiate an SSL connection, the client must authenticate the server but the server will accept any client into the connection. One-way SSL is common on the Internet where customers want to create secure connections before they share personal data. Often, clients will also use SSL to log on so that the server can authenticate them. • With two-way SSL (SSL with client authentication), the server presents a certificate to the client and the client presents a certificate to the server.

WebLogic Server can be configured to require clients to submit valid and trusted certificates before completing the SSL connection. Setting Up SSL: Main Steps To set up SSL. • Set SSL attributes for the private key alias and password in the WebLogic Server Administration Console. Optionally, set attributes that require the presentation of client certificates (for two-way SSL). Note: When starting a WebLogic Server instance, you can specify the command line argument -Dweblogic.security.SSL.nojce=true to use a FIPS-compliant (FIPS 140-2) crypto module in the server's SSL implementation.

FIPS 140-2 is a standard that describes U.S. Federal government requirements for sensitive, but unclassified use. For more information on these steps, see: • • • • • Obtaining Private Keys, Digital Certificates, and Trusted Certificate Authorities To use SSL, the server needs a private key, a digital certificate containing the matching public key, and a certificate for at least one trusted certificate authority. WebLogic Server supports private keys, digital certificates, and trusted CA certificates from the following sources: • The demonstration digital certificates, private keys, and trusted CA certificates in the WL_HOME server lib directory.

The demonstration digital certificates, private keys, and trusted CA certificates should be used in a development environment only.• Sun Microsystem's keytool utility can also be used to generate a private key, a self-signed digital certificate for WebLogic Server, and a Certificate Signing Request (CSR). Submit the CSR to a certificate authority to obtain a digital certificate for WebLogic Server. Use keytool to update the self-signed digital certificate with a new digital certificate. Use the keytool utility to obtain trust and identity when using WebLogic Server in a production environment. For more information about Sun's keytool utility, see keytool—Key and Certificate Management Tool.

Note: WebLogic Server does not support the use of the Digital Signature Algorithm (DSA). When using the keytool utility, the default key pair generation algorithm is DSA. Specify another key pair generation and signature algorithm when using WebLogic Server.• The Cert Gen utility generates digital certificates and private keys that should be used only for demonstration or testing purposes and not in a production environment. Use the Cert Gen utility if you want to set an expiration date in the digital certificate or specify a correct host name in the digital certificate so that you can use host name verification. (The demonstration digital certificate provided by WebLogic Server uses the machine's default host name as the host name.) For more information about using the Cert Gen utility to obtain private keys and digital certificates, see. Note: The Certificate Request Generator servlet is deprecated in this release of WebLogic Server. Use the keytool utility from Sun Microsystems in place of the Certificate Request Generator servlet.

For more information, see. When using the deprecated file-based private keys, digital certificates, and trusted CA, WebLogic Server can use digital certificates in either privacy-enhanced mail (PEM) or distinguished encoding rules (DER) format. A.pem format file begins with this line: ----BEGIN CERTIFICATE---- and ends with this line: ----END CERTIFICATE---- A.pem format file supports multiple digital certificates (for example, a certificate chain can be included). The order is important (include the files in the order of trust). The server digital certificate should be the first digital certificate in the file. The issuer of that digital certificate should be the next file and so on until you get to the self-signed root certificate authority certificate. A.der format file contains binary data.

A.der file can be used only for a single certificate, while a.pem file can be used for multiple certificates. Microsoft is often used as a certificate authority. Microsoft issues trusted CA certificates in p7b format.

The trusted CA certificates must be converted to PEM before they can be used with WebLogic Server. For more information, see. Private key files (meaning private keys not stored in a keystore) must be in PKCS#5/PKCS#8 PEM format. You can still use private keys and digital certificates used with other versions of WebLogic Swith with this version of WebLogic Server.

Convert the private key and digital certificate from privacy-enhanced mail (PEM) format to distinguished encoding rules (DER) format. For more information, see the description of the utility in Using WebLogic Server Java Utilities. After converting the files, ensure the digital certificate file has the -----BEGIN CERTIFICATE----- header and the -----END CERTIFICATE----- footer. Otherwise, the digital certificate will not work. Using the Cert Gen Utility Note: The Cert Gen utility generates digital certificates and private keys that should only be used for demonstration or testing purposes and not in a production environment.

The CertGen utility provides command line options to specify a CA certificate and key to be used for issuing generated certificates. It will default to using the CertGenCA.der and CertGenCAKey.der files which contain the digital certificate and private key of the demonstration CA certificate. The digital certificates generated by the CertGen utility have the host name of the machine on which they were generated as the value for its common name field ( cn) by default only. Command line options let you specify values for the cn and other Subject domain name (DN) fields, such as orgunit, organization, locality, state, countrycode.

The CertGen utility generates public certificate and private key files in PEM and DER formats. On Windows, double-click.der files to view the details of the generated digital certificate. The.pem files can be used when you boot WebLogic Server or use the digital certificates with a client. Note: By default, the CertGen utility looks for the CertGenCA.der and CertGenCAKey.der files in the current directory, or in the WL_HOME /server/lib directory, as specified in the weblogic.home system property or the CLASSPATH. If you want to use the default settings you need not specify CA files on the command line.

Alternatively, you can specify CA files on the command line, as shown in the following command syntax. • To generate a certificate, enter the following command at a command prompt: $ java utils.CertGen [-cacert ] [-cakey ] [-cakeypass ] [-selfsigned] [-certfile ] [-keyfile ] [-keyfilepass ] [-strength ] [-cn ] [-ou ] [-o ] [-l ] [-s ] [-c ] [-subjectkeyid ] [-subjectkeyidformat UTF-8 BASE64]. Argument Definition ca_cert_filename The file name of the issuer's CA public certificate. Ca_key_filename The file name of the issuer's CA private key. Ca_key_password The password for the issuer's CA private key. Selfsigned Generates a self-signed certificate that can be used as a trusted CA certificate. If this argument is specified, the ca_cert_filename, ca_key_filename, and ca_key_password arguments should not be specified.

Certfile The name of the generated certificate file. Privatekeyfile The name of the generated private key file.

Keyfilepassword The password for the private key. Keystrength The length (in bits) of the keys to be generated. The longer the key, the more difficult it is for someone to break the encryption. Commonname The name to be associated with the generated certificate.

Orgunit The name of the organizational unit associated with the generated certificate. Organization The name of the organization associated with the generated certificate. Locality The name of a city or town. State The name of the state or province in which the organizational unit (ou) operates if your organization is in the United States or Canada, respectively.

Do not abbreviate. Countrycode Two-letter ISO code for your country. The code for the United States is US. Subjectkeyidentifier Generates a certificate with the Subject Key identifier extension and the ID value specified on the command line. UTF-8 BASE64 Format of the subjectkeyid value.

Allowed values are UTF-8 or BASE64, with UTF-8 assumed by default. • Use the ImportPrivateKey utility load the digital certificate and private key into a keystore. See in the WebLogic Server Command Reference. By default, the CertGen tool generates domestic strength certificates. Specify the [export] option if you want the tool to generate export strength certificates.

If you want to export domestic strength digital certificates that use a host name, specify [domestic]. The CertGen tool uses the JDK version 1.3 InetAddress.getLocalHost().getHostname() method to get the hostname it puts in the Subject common name. The getHostName() method works differently on different platforms. It returns a fully qualified domain name (FQDN) on some platforms (for example, Solaris) and a short host name on other platforms (for example, Windows NT). If WebLogic Server is acting as a client (and by default hostname verification is enabled), you need to ensure the hostname specified in the URL matches the Subject common name in the certificate.

Otherwise, your connection fails because the host names do not match. On Solaris, when you type hostname on the command line the server looks at the /etc/hosts file and gets a short host name. When you invoke java.net.InetAddress.getHostName(), the host goes to the /etc/nsswitch.conf file and depending on how the host is configured returns a FQDN or a short host name. If the host entry is configured as: hosts: dns nis [NOTFOUND=return] The host performs a name service look up first and uses the information /etc/hosts file only if DNS is not available.

In this case, a FQDN is returned. If the host entry is configured as: hosts: files dns nis [NOTFOUND=return] The host goes to the /etc/hosts file first and then goes to DNS. In this case, a short hostname is returned.

Using Certificate Chains (Deprecated) Note: The use of file-based certificate chains is deprecated in this release of WebLogic Server. Now the whole certificate chain is imported into a keystore.

The steps in this section are provided for the purpose of backward compatibility only. To use certificate chains with WebLogic Server. • Specify the file in the Server Certificate File Name attribute in the SSL Configuration portion of the Keystores and SSL tab in the WebLogic Server Administration Console. Shows a sample certificate chain. • Configure WebLogic Server to use the Trust keystore. For more information, see. Getting a Digital Certificate for a Web Browser Low-security browser certificates are easy to acquire and can be done from within the Web browser, usually by selecting the Security menu item in Options or Preferences.

Go to the Personal Certificates item and ask to obtain a new digital certificate. You will be asked for some information about yourself. The digital certificate you receive contains public information, including your name and public key, and additional information you would like authenticated by a third party, such as your email address. Later you will present the digital certificate when authentication is requested. As part of the process of acquiring a digital certificate, the Web browser generates a public-private key pair.

The private key should remain secret. It is stored on the local file system and should never leave the Web browser's machine, to ensure that the process of acquiring a digital certificate is itself safe.

With some browsers, the private key can be encrypted using a password, which is not stored. When you encrypt your private key, you will be asked by the Web browser for your password at least once per session. Note: Digital certificates obtained from Web browsers do not work with other types of Web browsers or on different versions of the same Web browser. Storing Private Keys, Digital Certificates, and Trusted Certificate Authorities Once you have obtained private keys, digital certificates, and trusted CA certificates, you need to store them so that WebLogic Server can use them to find and verify identity.

Private keys, their associated digital certificates, and trusted CA certificates are stored in keystores. The keystores can be configured through the WebLogic Server Administration Console or specified on the command-line.

Use the Keystore Configuration section of the Keystores and SSL page of the WebLogic Server Administration Console to configure Identity and Trust keystores for WebLogic Server. For the purpose of backward compatibility, private keys and trusted CA certificates can be stored in a file or in a JKS keystore accessed via the WebLogic Keystore provider.

In addition, trusted CA certificates can be stored in a JKS keystore. Use the SSL Configuration section of the Keystores and SSL page of the WebLogic Server Administration Console to specify identity and trust attributes when using a file or a JKS keystore accessed via the WebLogic Keystore provider. For more information, see: • • Creating a Keystore and Loading Private Keys and Trusted Certificate Authorities into the Keystore A keystore is a mechanism designed to create and manage private keys/digital certificate pairs and trusted CA certificates. Use the following mechanisms to create a keystore and load private keys and trusted CA certificates into the keystore: • The WebLogic ImportPrivateKey utility. The ImportPrivateKey utility allows you to take private key and digital certificate files and load them into a keystore.

For more information, see in the WebLogic Server Administration Guide. • Sun Microsystem's keytool utility. Use the keytool utility to generate a private key/digital certificate pair and then import the signed private key into the keystore. For more information, see. While you can use the keytool utility to generate new private keys and digital certificates and add them to a keystore, the utility does not allow you to take an existing private key from a file and import it into the keystore.

Instead, use the WebLogic ImportPrivateKey utility. Note: The keytool utility does allow you to import trusted CA certificates in a file into a keystore.• Custom utilities. This release of WebLogic Server can use keystores created with custom tools or utilites.

How to create and use these utilities is outside the scope of this document. When configuring SSL you have to decide how identity and trust will be stored. Although one keystore can be used for both identity and trust, for the following reasons, BEA recommends using separate keystores for both identity and trust: The Identity keystore (private key/digital certificate pairs) and the Trust keystore (trusted CA certificates) may have different security requirements. For example: • The Identity keystore may be prohibited by company policy from ever being put in the network while the Trust keystore can be distributed over the network. • The Identity keystore may be protected by the operating system for both reading and writing by non-authorized users while the Trust keystore only needs to be write protected.

• The password for the trust keystore is generally known by more people than the password for the Identity keystore. For identity, you only have to put the certificates (non-sensitive data ) in the keystore while for trust, you have to put the certificate and private key (sensitive data) in the keystore.

Machines tend to have the same trust rules across an entire domain (meaning, they use the same set of trusted CAs), while they tend to have per server identity. Identity requires a private key and private keys should not be copied from one machine to another. Therefore, separate keystores per machine are created each containing only the server identity needed for that machine. However, trust keystores can be copied from machine to machine thus making it easier to standardizes trust rules. Identity is more likey to be store in hardware keystores such as nCipher. Trust can be stored in a file-based JDK keystore without having security issues since trust only has certificates not private keys. By default, WebLogic Server looks for an Identity keystore named DemoIdentity.jks in the WL_HOME server lib directory and Trust keystores named DemoTrust.jks in the WL_HOME server lib directory and cacerts in the JAVA_HOME jre lib security directory.

All private key entries in a keystore are accessed by WebLogic Server via unique aliases. You specify the alias when loading the private key into the keystore. Aliases are case-insensitive; the aliases Hugo and hugo would refer to the same keystore entry. Aliases for private keys are specified in the Private Key Alias attribute when configuring SSL. All certificate authorities in a keystore identified as trusted by WebLogic Server are trusted. Fungilab Viscometer Manual Treadmill. Although WebLogic Server does not use the alias to access trusted CA certificates, the keystore does require an alias when loading a trusted CA certificate into the keystore. Common Keytool Commands the keytool commands when creating and using JKS keystores with WebLogic Server.

Note: The keytool utility is a product of Sun Microsytems. Therefore, BEA Systems does not provide complete documentation on the utility. For more information, see keytool-Key and Certificate Management Tool.

Table 8-1 Commonly Used keytool Commands Command Description keytool -genkey -keystore keystorename -storepass keystorepassword Generates a new private key entry and self-signed digital certificate in a keystore. If the keystore does not exist, it is created. Keytool -import -alias aliasforprivatekey -file privatekeyfilename.pem -keypass privatekeypassword -keystore keystorename -storepass keystorepassword Updates the self-signed digital certificate with one signed by a trusted CA. Keytool -import -alias aliasfortrustedca -trustcacerts -file trustedcafilename.pem -keystore keystorename -storepass keystorepassword Loads a trusted CA certificate into a keystore. If the keystore does not exist, it is created.

-certreq -alias alias -sigalg sigalg -file certreq_file -keypass privatekeypassword -storetype keystoretype -keystore keystorename -storepass keystorepassword Generates a CSR, using the PKCS#10 format. Sent the CSR to be sent to a trusted CA. The trusted CA authenticates the certificate requestor and returns a digital certificate to replace the existing self-signed digital certificate in the keystore. Keytool -list -keystore keystorename Displays what is in the keystore. Keytool -delete -keystore keystorename -storepass keystorepassword -alias privatekeyalias Delete a private key/digital certifcate pair for the specified alias from the keystore. Keytool -help Provides online help for keytool. How WebLogic Server Locates Trust WebLogic Server uses the following algorithm when it loads its trusted CA certificates.

• Else load trusted CA certificates from WL_HOME server lib cacerts keystore. Configuring Keystores By default, WebLogic Server is configured with two keystores: • DemoIdentity. Dell Axim X51 Instruction Manual. jks—Contains a demonstration private key for WebLogic Server. This keystore contains the identity for WebLogic Server.

• DemoTrust.jks—Contains the trusted certificate authorities from the WL_HOME server lib DemoTrust.jks and the JDK cacerts keystores. This keystore establishes trust for WebLogic Server. These keystores are located in the WL_HOME server lib directory. For testing and development purposes, the keystore configuration is complete. However, the demonstration keystores should not be used in a production environment.

All the digital certificates and trusted CA certificates in the keystores are signed by a WebLogic Server demonstration certificate authority. Therefore, all WebLogic Server installations trust each other. This will leave your SSL connections wide open to a number of security attack. Use the steps in this section to configure Identity and Trust keystores for production use.

Before you perform the steps in this section, you need to. • Choose the type of keystore configuration being used. The following options are available: • Demo Identity and Demo Trust—The demonstration Identity and Trust keystores located in the WL_HOME server lib directory and configured by default and the cacerts file in the JAVA_HOME jre lib security directory. • Custom Identity and Java Standard Trust—An Identity keystore you create and the trusted CAs defined in the cacerts file in the JAVA_HOME jre lib security directory. • Custom Identity and Custom Trust—Identity and Trust keystores you create. • Custom Identity and Command-Line Trust—An Identity keystore you create and command-line arguments that specify the location of the Trust keystore. Use this option in a production environment when the Administration port is enabled and Managed servers are started on the command-line instread of by the Node Manager.

• Define attributes for the Identity keystore. • Custom Identity Keystore File Name—The fully qualified path to the Identity keystore.

• Custom Identity Keystore Type—The type of the keystore. Generally, this attribute is jks. If this attribute is not specified, the default keystore type defined in the security policy file for the JDK is used. • Custom Identity Keystore PassPhrase—The password defined when creating the keystore. This attribute is optional or required depending on the type of keystore.

All keystores require the passphrase in order to write to the keystore. Some keystores do not require the passphrase to read from the keystore. Whether or not you define this property depends on the requirements of the keystore. For example, WebLogic Server only reads from the keystore so a passphrase is not required, however, WebLogic Integration writes to keystores and therefore requires a passphrase. Confirm the password.

Note: The passphrase for the Demo Identity keystore is DemoIdentityKeyStorePassPhrase. • Define attributes for the Trust keystore. If you choose Java Standard Trust, specify the password defined when creating the keystore. Confirm the password. If you choose Custom Trust, define the following attributes: • Custom Trust Keystore File Name—The fully qualified path to the trust keystore. • Custom Trust Keystore Type—The type of the keystore. Generally, this attribute is jks.

If this attribute is not specified, the default keystore type defined in the security policy file for the JDK is used. • Custom Trust Keystore PassPhrase—The password defined when creating the keystore. This attribute is optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. Some keystores do not require the passphrase to read from the keystore.

Whether or not you define this property depends on the requirements of the keystore. For example, WebLogic Server only reads from the keystore so a passphrase is not required, however, WebLogic Integration writes to keystores and therefore requires a passphrase. Confirm the password.

• Specify how the identity and trust for WebLogic Server is stored. The following options are available: • Key Stores—Use this option if you created Identity and Trust keystores for WebLogic Server. If you choose this option, go to step 8. • Files or Key Store Providers—Use this option if you stored private keys and trusted CA certificates in a file or in a JKS keystore accessed via the WebLogic Keystore provider (as supported in previous releases of WebLogic Server). If you choose this option, go to step 9. This option is available for the purpose of backward compatibility only and it automatcally set with security information from a previous release of WebLogic Server. • Specify the alias used to load the private key into the keystore in the Private Key Alias and the password used to retrieve the private key from the keystore in the Passphrase attibute.

You may have specified this information when creating the Identity keystore; however, for the purpose of SSL configuration specify the information again. Skip to step 10. Note: You do not have to specify this information for the Trust keystore because trusted CA certificates are not individually identified to WebLogic Server with aliases. All trusted CA certificates in a keystore identified as trusted by WebLogic Server are trusted. Therefore, WebLogic Server does not require an alias when retrieving a trusted CA certificate from the keystore. • Specify information about the location of identity and trust for WebLogic Server. Note: This step only applies if the Files or Key Store Providers option is specified.

• Private Key File Name—The directory location of the private key for WebLogic Server. Specify a value for this attribute only if you stored the private key for WebLogic Server in a file (versus a WebLogic Keystore provider).

• Private Key Alias—The alias specified when loading the private key for WebLogic Server from the keystore. Specify a value for this field only if you stored the private key for WebLogic Server in a keystore accessed by the WebLogic Keystore provider.

• Passphrase—The password specified when loading the private key for WebLogic Server into the keystore. Specify a value for this field only if you stored the private key for WebLogic Server in a keystore accesssed by the WebLogic Keystore provider. Confirm the password.

If you protected the private key file with a password, specify the weblogic.management.pkpassword command-line argument when starting the server. • Server Certificate File Name— The directory location of the digital certificate for WebLogic Server. If you are using a certificate chain that is deeper than two certificates, you to need to include the entire chain in PEM format in the certificate file. • Trusted CA File Name—The name of the file containing the PEM-encoded trusted certificate authorities. • Reboot WebLogic Server. Configuring Two-Way SSL By default, WebLogic Server is configured to use one-way SSL (the server passes its identity to the client).

For a more secure SSL connection, use two-way SSL. In a two-way SSL connection, the client verifies the identity and trust of the server and then passes its identity to the server. The server then validates the identity and trust of the client before completing the SSL connection.

The server determines whether or not two-way SSL is used. Before configuring two-way SSL, ensure the Trust key store for the server includes the certificate for the trusted certificate authority that signed the certificate for the client. To enable two-way SSL. • Reboot WebLogic Server.

Using Host Name Verification A host name verifier ensures the host name in the URL to which the client connects matches the host name in the digital certificate that the server sends back as part of the SSL connection. A host name verifier is useful when an SSL client or an SSL server acting as a client connects to an application server on a remote host. It helps to prevent man-in-the-middle attacks. By default, WebLogic Server has host name verification enabled.

As a function of the SSL handshake, WebLogic Server compares the common name in the SubjectDN in the SSL server's digital certificate with the host name of the SSL server used to initiate the SSL connection. If these names do not match, the SSL connection is dropped. The SSL client is the actual party that drops the SSL connection if the names do not match.

In this release of WebLogic Server, the host name verification feature is updated so that if the host name in the certificate matches the local machine's host name, host name verification passes if the URL specifies localhost, 127.0.01 or the default IP address of the local machine. To verify that host name verification is enabled for your WebLogic Server deployment, perform the following steps for each server in your domain. Note: The following steps only apply when a WebLogic Server instance is acting as an SSL client.

Java clients acting as SSL clients specifiy the use of host name verification via command-line arguments. • Verify that the the Hostname Verification field is set to BEA Hostname Verifier. If anything other than the default behavior is desired, either turn off host name verification or configure a custom host name verifier. Turning off host name verification leaves WebLogic Server vulnerable to man-in-the-middle attacks.

BEA recommends leaving host name verification on in production environments. Turn off host name verification in one of the following ways: • On the command line of the SSL client, enter the following argument: -Dweblogic.security.SSL.ignoreHostnameVerification=true When using Java clients, host name verification must be set on the command-line.• In the WebLogic Server Administration Console. • Reboot WebLogic Server. When using Java clients, a custom host name verifier must be specified on the command-line using the following argument: -Dweblogic.security.SSL.HostnameVerifier= classname where classname specifies the implementation of the weblogic.security.SSL.HostnameVerifier interface.

Enabling SSL Debugging SSL debugging provides more detailed information about the SSL events that occurred during an SSL handshake. • Ensure Identity and Trust keystores for the Node Manager, Administration Server, and any Managed Servers exist. In previous releases, WebLogic Server only supported JKS keystores.

In this release, WebLogic Server can access private keys and trusted CA certificates from any type of keystore. When you configure the keystore in the WebLogic Server Administration Console, you optionally specify its type. In a production environment, you can also use the Java Standard Trust keystore (JAVA_HOME jre lib security cacerts)as the Trust keystore for the Node Manager, the Administration Server, or any Managed Servers. • Edit the nodemanager.properties file to specify the keystore location and passwords for the Node Manager. Node Manager SSL Demonstration Configuration: Main Steps Using the demonstration Identity and Trust keystores provided by WebLogic Server to configure SSL for the Node Manager involves verifying the default settings for the keystore attributes and ensuring that the Administration Server and any Managed Servers are listening for SSL communications on different ports. Illustrates the SSL demonstation configuration for the Node Manager. Figure 8-1 SSL Demonstration Configuration for the Node Manager Note: The following procedure assumes the Node Manager, the Administration Server, and all Managed Servers are running on the same machine.

To configure the Node Manager to use SSL and the demonstration Identity and Trust keystores. • On the Server-->Keystores and SSL tab, verify the settings of the following Trust keystore attributes for the Managed Server: • Demo Trust Keystore— DemoTrust.jks • Type— JKS • Passphrase— DemoTrustKeyStorePassPhrase Note: No changes to the nodemanager.properties file are required. The Node Manager will automatically default to the demonstration Identity and Trust keystores. Node Manager SSL Production Configuration: Main Steps illustrates the SSL production configuration for the Node Manager. Figure 8-2 SSL Production Configuration for the Node Manager Note: The following procedure assumes the Node Manager, the Administration Server, and all Managed Servers are running on the same machine. Warning: When you configure keystores through the WebLogic Administration Servers, passwords are available in clear text during the configuration process. The passwords will be encrypted automatically when the configuration is complete and the Node Manager is started.

For a more secure deployment, BEA recommends taking the machine on which you are configuring the Node Manager off the Internet or ensure the machine is protected behind a firewall so that passwords can not be snooped. To configure SSL for the Node Manager. • Set the Listen Address for the Administration Server. The Listen Address is the host name of the machine on which the Administration Server runs. This host name should match the host name in the CN field of the digital certificate for the Administration Server.

If you don't set the Listen Address correctly, you may encounter host name verification errors. Use the following command to determine the host name specified in the CN field of the digital certificate: keytool -list -v -keystore fulldirectorypathtokeystore keystorename. • Specify information about the Identity keystore: CustomIdentityKeystoreType CustomIdentityAlias CustomIdentityKeystoreFileName CustomIdentityKeyStorePassPhrase The CustomIdentityKeystoreType attribute is optional and defaults to the keystore type defined in the security policy file for the JDK. The CustomIdentityKeyStorePassPhrase attribute is optional depending on the type of keystore. All keystores require the passphrase in order to write to the keystore.

Some keystores do not require the passphrase to read from the keystore. Whether or not you define this property depends on the requirements of the keystore. For example, WebLogic Server only reads from the keystore so a passphrase is not required, however, WebLogic Integration writes to keystores and therefore requires a passphrase. • Specify information about the Trust keystore. If you use a custom Trust keystore, specify: CustomTrustKeystoreType CustomTrustKeystoreFileName CustomTrustKeyStorePassPhrase The CustomTrustKeystoreType attribute is optional and defaults to the keystore type defined in the security policy file for the JDK. The CustomTrustKeyStorePassPhrase attribute is optional depending on the type of keystore.

All keystores require the passphrase in order to write to the keystore. Some keystores do not require the passphrase to read from the keystore. Whether or not you define this property depends on the requirements of the keystore. For example, WebLogic Server only reads from the keystore so a passphrase is not required, however, WebLogic Integration writes to keystores and therefore requires a passphrase. If you use the Java Standard Trust keystore, specify: Keystores=CustomIdentityandJavaStandardTrust JavaStandardTrustKeyStorePassPhrase The JavaStandardTrustKeyStorePassPhrase attribute is optional depending on the type of keystore.

All keystores require the passphrase in order to write to the keystore. Some keystores do not require the passphrase to read from the keystore. Whether or not you define this property depends on the requirements of the keystore. For example, WebLogic Server only reads from the keystore so a passphrase is not required; however, WebLogic Integration writes to keystores and therefore requires a passphrase. • Start the Administration Server.

Using Files and the WebLogic Keystore Provider For backward compatibility, WebLogic Server supports using files and the WebLogic Keystore provider as a way to store identity and trust when configuring the Node Manager to use SSL. However, both of these methods are deprecated in this release. Also, private keys stored in files may or may not be password protected. Private keys that are not password protected can be vulnerable to security attacks.

BEA recommends upgrading to keystores as a way to store identity and trust for the Node Manager, the Administration Server, and any Managed Servers. The SSL requirements for identity and trust are as follows: • Administration Servers and Managed Servers use private keys stored in JKS keystores accessed through the WebLogic Keystore provider or in a file.

• The digital certificate for an Administration Server and a Managed Server must be stored in a file. • Administration Servers and Managed Servers can use trusted CA certificates stored: • In a JKS keystore specified by the -Dweblogic.security.SSL.trustedCAKeyStore command-line in the start script for the Administration Server or Managed Server. • In a JKS keystore accessed by the WebLogic Keystore provider • A file containing the PEM-encoded trusted certificate authorities. If no trusted CA certificate is located in either of these storage mechanisms, WebLogic Server assumes anyAdministration Server and Managed Servers trust all the certificate authorities in the cacerts files in the WL_HOME server lib.• The Node Manager can only use digital certificates and private keys stored in files. Identity is specified by the command-line arguments for the Node Manager. • The Node Manager uses trusted CA certificates stored in a JKS keystore for trust. The Trust keystore is specified by the command-line arguments for the Node Manager Note: Perform the following steps on the Administration Server and each Managed Server you plan to use.

To use files or the WebLogic Keystore provider to store identity and trust for an Administration Server or a Managed Server. • Specify information about the location of identity and trust for WebLogic Server.

• Private Key File Name—The directory location of the private key for WebLogic Server. Specify a value for this attribute only if you stored the private key for WebLogic Server in a file (versus a WebLogic Keystore provider). • Private Key Alias—The alias specified when loading the private key for WebLogic Server from the keystore. Specify a value for this field only if you stored the private key for WebLogic Server in a keystore accessed by the WebLogic Keystore provider. • Passphrase—The password specified when loading the private key for WebLogic Server into the keystore.

Specify a value for this field only if you stored the private key for WebLogic Server in a keystore accesssed by the WebLogic Keystore provider. Confirm the password. If you protected the private key file with a password, specify the weblogic.management.pkpassword command-line argument when starting the server.

• Server Certificate File Name— The directory location of the digital certificate for WebLogic Server. If you are using a certificate chain that is deeper than two certificates, you to need to include the entire chain in PEM format in the certificate file. • Specify the location of the Trust keystore for the Managed Server on the Servers-->Configuration-->Remote Start tab as follows: weblogic.security.SSL.trustedCAKeyStore To use files or a JKS keystore to store identity and trust for the Node Manager, specify the following command-line arguments when starting the Node Manager: • Use weblogic.nodemanager.keyFile=filename to specify the location of the private key file. • If you password protected the private key file, use weblogic.nodemanager.keyPassword=password to specify the password. • Use weblogic.nodemanager.certificateFile=filename to specify the location of the digital certificate for the Node Manager. • Use weblogic.security.SSL.trustedCAKeyStore=keystorename to specify the location of the JKS trusted keystore.

Configuring RMI over IIOP with SSL Use SSL to protect IIOP connections to RMI remote objects. SSL secures connections through authentication and encrypts the data exchanged between objects. To use SSL to protect RMI over IIOP connections, do the following. • Use the SSL IOR when obtaining the initial reference to the CosNaming service that accesses the WebLogic Server JNDI tree.

For more information about using RMI over IIOP, see and. SSL Certificate Validation In previous releases, WebLogic Server did not ensure each certificate in a certificate chain was issued by a certificate authority.

This problem meant anyone could get a personal certificate from a trusted certificate authority, use that certificate to issue other certificates, and WebLogic Server would not detect the invalid certificates. Now all X509 V3 CA certificates used with WebLogic Server must have the Basic Constraint extension defined as CA, thus ensuring 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 section describes the command-line argument that controls the level of certificate validation. If WebLogic Server is booted with a certificate chains that will not pass the certificate validation, an information message is logged noting that clients could reject it. 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.

Use the following command-line argument to control the level of certificate validation performed by WebLogic Server: -Dweblogic.security.SSL.enforceConstraints= option describes the options for the command-line argument. Table 8-2 Options for -Dweblogic.security.SSL.enforceConstraints Option Description strong or true Use this option to check 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. Strict Use this option to check whether 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 commerically available CA certificates do not conform to the IETF RFC 2459 standard.

Off Use this option to turn off checking for the Basic Constraints extension. The rest of the certificate validation still happens. CA certificates from most commercial certificate authorities should work with the default strong option. For example: -Dweblogic.security.SSL.enforceConstraints=off BEA does not recommend using this option in a production environment.

Instead, purchase new CA certificates that comply with the IETF RFC 2459 standard. 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 therea 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. To enable acceptance of Certificate Policies, start WebLogic Server with the following argument: -Dweblogic.security.SSL.allowedcertificatepolicyids. 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 WebLogic Server provides a ValidateCertChain command-line utility to check whether or not an existing certificate chain will be rejected by WebLogic Server. The utility uses certificate chains from PEM files, PKCS-12 files, PKCS-12 keystores, and JKS keystores.

A complete certificate chain must be used with the utility. • Install the files for the nCipher JCE provider. The following files are required: • JCE 1.2.1 framework JAR • Jurisdiction policy files • JCE provider • Certificate that signed the JAR file Note: This step may have been performed as part of installing the hardware for nCipher JCE provider.

In that case, verify that the files are correctly installed. The files are installed in one of the following ways: • As an installed extension. Copy the files to one of the following locations: Windows NT%JAVA_HOME% jre lib ext For example:%WL_HOME% jdk141 jre lib ext UNIX $JAVA_HOME/jre/lib/ext For example: $WL_HOME/jdk141/jre/lib/ext• In the CLASSPATH of the server. • Edit the Java security properties file ( java.security) to add the nCipher JCE provider to the list of approved JCE providers for WebLogic Server.

The Java security properties file is located in: Windows NT%JAVA_HOME% jre lib security java.security UNIX $JAVA_HOME/jre/lib/security/java.security Specify the nCipher JCE provider as: security.provider.n =com.ncipher.provider.km.mCipherKM where n specifies the preference order which determines the order in which providers are searched for requested algorithms when no specific provider is requested. The order is 1-based; 1 is the most preferred, followed by 2, and so on. The nCipher JCE provider must follow the RSA JCA provider in the security properties file. For example: security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.rsajca.Provider security.provider.3=com.ncipher.provider.km.mCipherKM.

• To ensure the nCipher JCE provider is working properly, enable debugging per the nCipher product documentation. Specifying the Version of the SSL Protocol WebLogic Server supports both the SSL V3.0 and TLS V1.0 protocols. By default, WebLogic Server, when acting as an SSL server, will agree to either SSL 3.0 or TLS 1.0 protocol versions, and use whichever of these the client has specified as preferred in its client hello message. When WebLogic Server is acting as an SSL client, it will specify TLS1.0 as the preferred protocol in its SSL V2.0 client hello message, but will agree to SSL V3.0 as well, if that's the highest version that the SSL server on the other end supports. The peer must respond with an SSL V3.0 or TLS V1.0 message or the SSL connection is dropped.

While in most cases the SSL V3.0 protocol is acceptable there are circumstances (compatibility, SSL performance, and environments with maximum security requirements) where the TLS V1.0 protocol is desired. The weblogic.security.SSL.protocolVersion command-line argument allows you to specify what protocol is used for SSL connections. Note: The SSL V3.0 and TLS V1.0 protocols can not be interchanged. Only use the TLS V1.0 protocol if you are certain all desired SSL clients are capable of using the protocol. The following command-line argument can be specified so that WebLogic Server supports only SSL V3.0 or TLS V1.0 connections: • -Dweblogic.security.SSL.protocolVersion=SSL3—Only SSL V3.0 messages are sent and accepted.

• -Dweblogic.security.SSL.protocolVersion=TLS1—Only TLS V1.0 messages are sent and accepted. • -Dweblogic.security.SSL.protocolVersion=ALL—This is the default behavior. Using the SSL Protocol to Connect to WebLogic Server from weblogic.Admin Using the SSL protocol to connect to WebLogic Server from weblogic.Admin requires you to disable two-way SSL on the server, use a secure server port in the URL for the client, specify trust for the client, and configure how the client uses host name verification. The following sections describe these steps in detail. Ensure Two-Way SSL Is Disabled on the SSL Server There is no way to specify identity when using weblogic.Admin.

Identity (private key and digital certificate or certificate chain) is required when the SSL server is configured for two-way SSL. Therefore, two-way SSL cannot be enabled when using weblogic.Admin.

Before establishing an SSL connection from weblogic.Admin to an SSL server, ensure that the SSL server is not configured to use two-way SSL. If two-way SSL is enabled on the SSL server, the SSL connection will fail.

To disable two-way SSL when using WebLogic Server. • Reboot WebLogic Server. Use a Secure Port in the URL To use the SSL protocol to make a connection, specify a secure protocol and port in the URL for weblogic.Admin. For example: weblogic.Admin -url t3s:// localhost:9002 Specify Trust for weblogic.Admin All SSL clients need to specify trust. Trust is a set of CA certificates that specify which trusted certificate authorities are trusted by the client.

In order to establish an SSL connection the client needs to trust the certificate authorities that issued the server's digitial certificates. When using weblogic.Admin, the trusted CA certificates must be stored in a keystore. By default, all the trusted certificate authorities available from the JDK (. Jre lib security cacerts) are trusted by weblogic.Admin. Optionally, use the following command-line argument to specify a password for the JDK cacerts trust keystore: -Dweblogic.security.JavaStandardTrustKeyStorePassPhrase= password where password is the password for the Java Standard Trust keystore. This password is defined when the keystore is created. You also have the option of specifying the one of the following types of trust: • Demo Trust—The trusted CA certificates in the demonstration Trust keystore ( DemoTrust.jks) located in the WL_HOME server lib directory.

In addition, the trusted CAs in the JDK cacerts keystore are trusted. To use the Demo Trust, specify the following command-line argument: -Dweblogic.security.TrustKeyStore=DemoTrust Optionally, use the following command-line argument to specify a password for the JDK cacerts trust keystore: -Dweblogic.security.JavaStandardTrustKeyStorePassPhrase= password where password is the password for the Java Standard Trust keystore. This password is defined when the keystore is created.• Custom Trust—A trust keystore you create. To use Custom Trust, specify the following command-line arguments: • weblogic.security.TrustKeyStore=CustomTrust This required command-line argument specifies the use of Custom Trust• weblogic.security.CustomTrustKeyStoreFileName= filename This required command-line argument specifies the fully qualified path to the trust keystore• weblogic.security.TrustKeystoreType= keystore_type This optional command-line argument specifies the type of the keystore. Generally, this value for type is the default value, jks.• weblogic.security.CustomTrustKeyStorePassPhrase= password This optional command-line argument specifies the password defined when creating the keystore. Specify Host Name Verification for weblogic.Admin By default, weblogic.Admin performs a host name verification check.

It compares the CN field in the digital certificate received from the server with the server name in the URL the client used to connect to the server. The CN field and the server name must match to pass the host name verification check. This check is performed to prevent man-in-the-middle attacks. In this release of WebLogic Server, the default host name verifier handles the case where the URL contains localhost or an IP address and the CN field of the digital certificate matches the name of the local host.

It is possible to disable the check by specifying the following command-line argument: -Dweblogic.security.SSL.ignoreHostnameVerification=true Note: If the SSL server specified an IP address in its URL, disable the host name verification check. Use the following command-line argument to specify a custom host name verifier: -Dweblogic.security.SSL.hostnameVerifier= classname where classname specifies the implementation of the weblogic.security.SSL.HostnameVerifier interface.