- SSL: An Introduction
- One-Way and Two-Way SSL
- Setting Up SSL: Main Steps
- Using Host Name Verification
- Enabling SSL Debugging
- SSL Session Behavior
- SSL Certificate Validation
- Using the nCipher JCE Provider with WebLogic Server
- Specifying the Version of the SSL Protocol
Notes: This chapter applies to WebLogic Server deployments using the security features in this release of WebLogic Server as well as deployments using Compatibility Security.
All machines must be kept up to date with the current set of recommended patches from the operating system vendors.
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 protocol in the connection URL, for example, https://myserver:7002.
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.
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 a connection from any client. 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 in order for the server can authenticate them.
- With two-way SSL, 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
- Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) for WebLogic Server. Use the digital certificates, private keys, and trusted CA certificates provided by the WebLogic Server kit, the CertGen utility, Sun Microsystem's
keytoolutility, or a reputable vendor such as Entrust or Verisign to perform this step.
Note: This release of WebLogic Server supports private keys and trusted CA certificates stored in files, or in the WebLogic Keystore provider for the purpose of backward compatibility only.
- Configure the identity and trust keystores for WebLogic Server in the WebLogic Server Administration Console. See "Configure Keystores" in the Administration Console Online Help.
- Set SSL configuration options for the private key alias and password in the WebLogic Server Administration Console. Optionally, set configuration options that require the presentation of client certificates (for two-way SSL). See "Configure SSL" and "Configure two-way SSL" in the Administration Console Online Help.
- Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) for WebLogic Server. Use the digital certificates, private keys, and trusted CA certificates provided by the WebLogic Server kit, the CertGen utility, Sun Microsystem's
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.
For information on configuring identity and trust for WebLogic Server, see Obtaining Private Keys, Digital Certificates, and Trusted Certificate Authorities and Storing Private Keys, Digital Certificates, and Trusted Certificate Authorities.
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 a WebLogic Server acting as an SSL 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.
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.
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.
For more information, see the following topics in the Administration Console Online Help:
- "Verify Host Name Verification is enabled"
- "Disable Host Name Verification"
- "Configure a Custom Host Name Verifier"
- "Configuring SSL"
Enabling SSL Debugging
SSL debugging provides more detailed information about the SSL events that occurred during an SSL handshake. The SSL debug trace displays information about:
- Trusted certificate authorities
- SSL server configuration information
- Server identity (private key and digital certificate)
- The encryption strength that is allowed by the license in use
- Enabled ciphers
- SSL records that were passed during the SSL handshake
- SSL failures detected by WebLogic Server (for example, trust and validity checks and the default host name verifier)
- I/O related information
Use the following command-line properties to enable SSL debugging:
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
The SSL debugging properties can be included in the start script of the SSL server, the SSL client, and the Node Manager. For a Managed Server started by the Node Manager, specify this command-line argument on the Remote Start page for the Managed Server.
SSL debugging dumps a stack trace whenever an ALERT is created in the SSL process. The types and severity of the ALERTS are defined by the TLS specification.
The stack trace dumps information into the log file where the ALERT originated. Therefore, when tracking an SSL problem, you may need to enable debugging on both sides of the SSL connection (on both the SSL client or the SSL server). The log file contains detailed information about where the failure occurred. To determine where the ALERT occurred, confirm whether there is a trace message after the ALERT. An ALERT received after the trace message indicates the failure occurred on the peer. To determine the problem, you need to enable SSL debugging on the peer in the SSL connection.
When tracking an SSL problem, review the information in the log file to ensure:
- The correct
config.xmlfile was loaded - The license (domestic or export) is correct
- The trusted certificate authority was valid and correct for this server.
- The host name check was successful
- The certificate validation was successful
Note: Sev 1 type 0 is a normal close ALERT, not a problem.
SSL Session Behavior
WebLogic Server allows SSL sessions to be cached. Those sessions live for the life of the server.
Clients that use SSL sockets directly can control the SSL session cache behavior. The SSL session cache is specific to each SSL context. All SSL sockets created by SSL socket factory instances returned by a particular SSL context can share the SSL sessions.
Clients default to resuming sessions at the same IP address and port. Multiple SSL sockets that use the same host and port share SSL sessions by default assuming the SSL sockets are using the same underlying SSL context.
Clients that do not want to use SSL sessions must call setEnableSessionCreation(false) on the SSL socket to ensure that no SSL sessions are cached. This setting only controls whether an SSL session is added to the cache, it does not stop an SSL socket from finding an SSL session that was already cached (for example, SSL socket 1 caches the session, SSL socket 2 sets setEnableSessionCreation to false but it can still reuse the SSL session from SSL socket 1 since that session was put in the cache.)
SSL sessions exist for the lifetime of the SSL context; they are not controlled by the lifetime of the SSL socket. Therefore, creating a new SSL socket and connecting to the same host and port can resume a previous session as long as the SSL socket is created using an SSL socket factory from the SSL context that has the SSL session in its cache.
By default, clients that use HTTPS URLs get a new SSL session for each URL because each URL uses a different SSL context and therefore SSL sessions can not be shared or reused. The SSL session can be retrieved using the weblogic.net.http.HttpsClient class or the weblogic.net.http.HttpsURLConnection class. Clients can also resume URLs by sharing a SSLSocket Factory between them.
Session caching is maintained by the SSL context, which can be shared by threads. A single thread has access to the entire session cache, not just one SSL session, so multiple SSL sessions can be used and shared in a single (or multiple) thread.
The following command-line arguments are ignored:
Configuring RMI over IIOP with SSL
Use SSL to protect Internet Interop-Orb-Protocol (IIOP) connections to Remote Method Invocation (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
host2iorutility to print the WebLogic Server IOR to the console. Thehost2iorutility prints two versions of the interoperable object reference (IOR), one for SSL connections and one for non-SSL connections. The header of the IOR specifies whether or not the IOR can be used for SSL connections.
- Use the
For more information about using RMI over IIOP, see Programming WebLogic RMI.
SSL Certificate Validation
WebLogic Server 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 section describes the command-line argument that controls the level of certificate validation.
Note: 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.
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
Table 11-1 describes the options for the command-line argument.
Table 11-1 Options for -Dweblogic.security.SSL.enforceConstraints
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. The following is the syntax for the ValidateCertChain command-line utility:
java utils.ValidateCertChain -filepemcertificatefilenamejava utils.ValidateCertChain -pempemcertificatefilenamejava utils.ValidateCertChain -pkcs12storepkcs12storefilenamejava utils.ValidateCertChain -pkcs12filepkcs12filenamepasswordjava utils.ValidateCertChain -jksaliasstorefilename[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
Troubleshooting Problems with Certificate Validation
If SSL communications were working properly in a previous release of WebLogic Server and start failing unexpectedly, the problem is mostly likely because the certificate chain used by WebLogic Server 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=trueThe following message indicates the SSL failure is due to 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 using one-way SSL, look for this error in the client log. When using two-way SSL, look for this error in the client and server logs.
Enabling SSL Debugging
SSL debugging provides more detailed information about the SSL events that occurred during an SSL handshake. The SSL debug trace displays information about:
- Trusted certificate authorities
- SSL server configuration information
- Server identity (private key and digital certificate)
- The encryption strength that is allowed by the license in use
- Enabled ciphers
- SSL records that were passed during the SSL handshake
- SSL failures detected by WebLogic Server (for example, trust and validity checks and the default host name verifier)
- I/O related information
Use the following command-line properties to enable SSL debugging:
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
The SSL debugging properties can be included in the start script of the SSL server, the SSL client, and the Node Manager. For a Managed Server started by the Node Manager, specify this command-line argument on the Remote Start page for the Managed Server.
SSL debugging dumps a stack trace whenever an ALERT is created in the SSL process. The types and severity of the ALERTS are defined by the TLS specification.
The stack trace dumps information into the log file where the ALERT originated. Therefore, when tracking an SSL problem, you may need to enable debugging on both sides of the SSL connection (on both the SSL client or the SSL server). The log file contains detailed information about where the failure occurred. To determine where the ALERT occurred, confirm whether there is a trace message after the ALERT. An ALERT received after the trace message indicates the failure occurred on the peer. To determine the problem, you need to enable SSL debugging on the peer in the SSL connection.
When tracking an SSL problem, review the information in the log file to ensure:
- The correct
config.xmlfile was loaded - The license (domestic or export) is correct
- The trusted certificate authority was valid and correct for this server.
- The host name check was successful
- The certificate validation was successful
Note: Sev 1 type 0 is a normal close ALERT, not a problem.
Using Certificate Lookup and Validation Providers
WebLogic Server SSL has built-in certificate validation, which given a set of trusted CAs:
- 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. In this release, WebLogic Server has added 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 providing 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. For more information, see the Configuring WebLogic Security Providers chapter.
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 over the administration port
- Connecting to an external LDAP server, such as the LDAPAuthenticator
Using the Administration Console or WLST, 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 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 has in previous releases plus do extra validation.
SSLMBeanin the WebLogic Server MBean Reference- "Set Up SSL" in the Administration Console Online Help
Using the nCipher JCE Provider with WebLogic Server
Note: Java Cryptography Extension (JCE) providers are written using the application programming interfaces (APIs) in the JCE available in JDK 5.0. This type of provider is different from the providers written using the WebLogic Security Service Provider Interfaces (SSPIs). WebLogic Server does not provide a JCE provider by default.
SSL is a key component in the protection of resources available in Web servers. However, heavy SSL traffic can cause bottlenecks that impact the performance of Web servers. JCE providers like nCipher which use a hardware card for encryption, offload SSL processing from Web servers freeing the servers to process more transactions. They also provide strong encryption and cryptographic processes to preserve the integrity and secrecy of keys.
WebLogic Server supports the use of the following JCE providers:
- The JDK JCE provider (
SunJCE) in the JDK 5.0. For more information about the features in the JDK JCE provider, see http://java.sun.com/products/jce.By default, the JCE provider in the JDK 5.0 has export strength jurisdiction policy files. After filling out the appropriate forms, the domestic strength jurisdiction policy files are downloadable from Sun Microsystems at http://java.sun.com/products/jce/javase.html#UnlimitedDownload.
The BEA license will continue to control the strength of the cryptography used by the WebLogic Server Application Programming Interfaces (APIs). Client code without the appropriate domestic strength cryptography license will only be able to use the J2SE export strength default cryptography. On the server, there will always be a BEA license that will enable either export or domestic strength cryptography.
- The nCipher JCE provider. For more information about the nCipher JCE provider, see http://www.ncipher.com/solutions/sslsecurity.html.
To install the nCipher JCE provider:
-
- Jurisdiction policy files—The JDK installs these files by default but they are of limited export strength.
- 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 JCE provider JAR files
- As an installed extension. Copy the files to one of the following locations:
- In the CLASSPATH of the server.
JAVA_HOME/jre/lib/security/java.securitySpecify the nCipher JCE provider as:
security.provider.n=com.ncipher.provider.km.mCipherKMnspecifies the preference order that 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
Specifying the Version of the SSL Protocol
WebLogic Server supports both the SSL V3.0 and TLS V1.0 protocols. When WebLogic Server is acting as an SSL server, it will agree to use whichever of these protocols the client specifies 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 is 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 lets you specify which 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:
2473
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
