Encrypt & decrypt your way into WebLogic SSL
Published on: Author: Michel Schildmeijer Category: OracleThe title of this blog may seem a bit cryptic…. In this article I’d like explain some basics of the the SSL implementation in WebLogic. This blog is meant for people who are not familiar with SSL, especially in combination with WebLogic.
In my experience, SSL is usually a bit of a black box for many junior and medior administrators who work with middleware, so I will try to clarify some of it in special relation to WebLogic. To understand this, there are also some generic parts to discuss. SSL is a technique to secure a point-to-point socket connection, in the so-called transport layer which will be secured. It provides secure connections for interfaces or (web) applications to connect and authenticate each other’s identity, and by encrypting the data traffic between those interfaces or application back ends.
Authentication allows a server, and sometimes optionally, a client to verify the identity of the application on the other end of a network connection. SSL uses the public key encryption technology for this. With public key encryption, a public key and a private key can be generated for a back-end server. This key is used to encrypt data before sending. After the client has recieved the key, it can decrypt it using that same key. So data encrypted with the public key can only be decrypted using the corresponding private key and vice versa.
It’s is like sending a locked safe with some transportcompany along with a note which contains the unlock combination. The public key is embedded in a digital certificate with additional information about the initiator of the key. This information may consist of name, street address, email address, company information and some geographic information. A private key and a digital certificate provide an 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-known certificate authorities include Verisign and Entrust.net. The trusted certificate authority (CA) certificate establishes trust for a certificate. Below is an overview of a “happy SSL flow”:
In one-way SSL authentication, only the server should present its identity by presenting a digital certificate to the client, to prove its identity. The client verifies that the certificate is trusted from the trust-store. In two-way SSL authentication, both the client and the server must present digital certificates before the SSL connection is established. Both are supported by WebLogic Server.
To configure two-way SSL for a server instance, use the two-way Client Cert Behavior attribute. This is in general how a two-way SSL works, but how does this relate to the WebLogic platform? Where do you configure these things, where do you tell WebLogic to do one-way or mututal SSL, and how do you analyze and detect potential issues? WebLogic uses SSL based on its underlying JAVA software, by storing certificates and keys in so-called keystores. A keystore is datacontainer which stores public, private keys and certificates, protected by various passwords (key and storepasswords) There are some formats of keystores available, such as PKCS12 and Sun’s Java Keystore (JKS) format. WebLogic supports both, but JKS is commonly used and PKCS12 should be converted to the JKS format.
Truststore
Truststores usually contain a set of certificates provided by the “Certificate Authority” of a certain company. Certification authority certificates are certificates that are issued by a CA to itself or to a second CA for the purpose of creating a defined relationship (a so called trust) between them. A certificate which is issued by a CA to itself is referred to as a trusted root certificate, because it is intended to establish a point of ultimate trust in a CA hierarchy. Once the trusted root has been established, it can be used to authorize underlying CA’s to issue certificates on its behalf. The relationship between CAs is most commonly hierarchical. However, CA certificates can also be used to establish trust relationships between CA’s between two different public key infrastructure (PKI) environments. In all of these cases, the CA certificate is critical for defining the certificate path and usage restrictions for all end entity certificates issued for use in the PKI. In most cases, a company owns a set of root certificates which contain the most common certificates from well-known certificate companies such as Verisign (Symantec) or Thawte.
These root certificates will be stored in a so-called truststore. A truststore is a keystore that is used when making decisions about what to trust. If you receive some data from an entity that you already trust, and this can be verified, then you can assume that the data really came from that entity. An entry should only be added to a truststore if you want to trust that entity. By either generating a key pair or by importing a certificate, you have given trust to that entry, so each entry in the keystore is considered a trusted entry. A file named ‘cacerts’ resides in the JVM runtime’s security properties directory, jre/lib/security.
The cacerts file represents a system-wide JKS keystore with CA certificates. System administrators can configure and manage that file by using Keytool. The cacerts keystore file ships with several common root CA certificates, each with an alias and a X.500 owner distinguished name. The truststore should contain certificates of only those certificate authorities that your company has identified to be trusted. By default, a WebLogic Server installation comes with a demo trust but any respectable enterprise never uses that of course :). Because the trust, and also private keystores are based on Java, this can be manipulated, altered or created using the keytool command line. I won’t discuss all possible options of this keytool, but here are some hints and tips:
- Beware if you use the keytool, set your PATH environment to your runtime Java environment (the one WebLogic is running with). Otherwise you might use a system Java version that comes with the operating system, which might lead to unexpected results.
- When using multiple managed servers in a cluster, use a shared filesystem to store your trust and private keystores.
- Demonstration keystores with digital certificates, private keys, and trusted CA certificates are found in the WebLogic Server home /server/lib directory. As your common sense will tell you, change this for live production.
How does SSL Fit in into WebLogic Server /domain ?
WebLogic makes uses SSL from its own Java implementation. Hence, there are three parts to identify in a typical WebLogic SSL configuration:
- The “physical” part as referred to earlier: public and private java keystores, certficates etc.
- Domain configuration: Tell WebLogic domain-wide how SSL must be used after keystores are installed and configured, you will have to tell WebLogic somehow where they are, from where the configurations can be loaded, which aliases to be used.First of all you will have to know if one, or two-way SSL is required. Within a managed server, only one option is possible, so if you need both, you have to configure another application and managed server to use two-way SSL. A typical scenario of one-way SSL could be that your company must meet a certain level of security by using SSL communication between infrastructural components. In this case between managed servers and the AdminServer and nodemanagers. SSL doesn’t touch any application specific components. What you need in here is:
- A trustore to load a set of the companies’ Root Certificates
- A private keystore for Admin and Managed Servers containing server information to use as identity information
- In case of using Virtual hostnames for managed servers as listen adress (for example to use with Whole Server Migration) also create separate keystore for the nodemanager. Because of the difference in host identity connection between nodemanager and managed server with VIP, listen adress will fail (Hostname verification). Configure the trust and private keystores including aliases, key and storepasswords which you specified creating the keystore per server instance. They refer to the configuration in the keystore.
- Application configuration: specify extra parameters within an application or application suite to point to the private keystore. For example, we have an OSB flow which we will use as a so-called service key provider where OSB will act as a client configured with two-way SSL and message level encryption. Regarding this, but also for other applications you first need to create a mapping in WebLogic to make it accessible. This can be done in the security realm, tab providers, tab Credential Mapping.
Below is an example screen of such a service key provider. When you click on browse, all keystores aliases known in the configuration are shown.
Some debug hints and tips
As in many cases, debugging demands a lot of your analytical skills, as it is very challenging! There is no ‘right’ method to act on errors or issues. You can use all kinds of little tools, but since this blog is about WebLogic I will stay on that topic. To debug, You can get more details about the error by enabling debugging using the following WLST command: System.setProperty("ssl.debug","true") If you just want do debug a specific application in a specific managed server, it’s better to specify it through Java command line, which you specify in the server startup parameters. Some of these parameters are:
- DebugSecuritySSL: Extra info about SSL library and channels, SSL ciphers, detailed loading and metadata of identity and trust keystores entries. And also detailed info about SSL handshake and data communications. To be set in the startup paramaters of the managed server: -DebugSecuritySSL=true
- DebugSecuritySSLEaten: Catches exception which pass WebLogic logging
- DebugSecurityKeyStore: See detailed information of a certain keystore
All these parameters can also be set on the debug tab of a managed server, or using a WLST command. For this you don’t need to restart, setting it as java option requires a restart of the server instance. In the logs you will find some SSL trace, like information about handshakes between clients and server. When sending encrypted data, SSL encrypts using a cryptographic hash. A cryptographic hash function is designed to detect alterations. When data is processed by a cryptographic hash function, a small string of bits, known as a hash, is generated. The slightest change to the message typically makes a large change in the resulting hash. A cryptographic hash function does not require a cryptographic key.
Often used hashes with SSL are Message Digest 5 (MD5) and Secure Hash Algorithm (SHA). A message authentication code (MAC) is similar to a cryptographic hash, except that it is based on a secret key. SSL debugging dumps a stack trace whenever an alert is raised in the SSL communication process. These alerts are defined and picked up by the Transport Layer Security (TLS) specification. There are many different alerts, but some common ones are:
- Validation problems (issues regarding keystores) in outbound and two-way SSL, like when a trust can’t be established
- Hostnames do not match (stored in the CN attribute)
- Certificate chain errors
- Wrong cipher formats (PEM, RSA, X509). A cipher is some sort of signature which has a specific format. These formats must follow the defaults shipped with WebLogic which are commonly used, provided within a Cryptographic Service Provider (CSP, a software library which holds these formats).
This was some very basic information about SSL and how it works within WebLogic. There is a lot more advanced stuff to talk about, which I will do in another blog. Keep following me!
Publicatiedatum: 4 september 2014
