Converting SSL certificate generated by a 3rd party to an Oracle Wallet

     

     Recently a customer asked me how to import his private key and certificate into an Oracle HTTP Server Wallet.

The customer generated a CSR outside the OHS Wallet Manager, using Open SSL, and sent it to a CA to get his certificates issued by them.

Unfortunately, the Wallet Manager only allows you to import certificates which were created for a CSR generated by the Wallet itself.

Despite this minor limitation, there is a workaround to get your private key, certificate and CA trusted certificates chain into Oracle Wallet.

This post explains the simple steps to achieve this, with a little help from Open SSL.

Deploying OAM 11g Correctly Part 2 – Logins and SSL

This is another post in our OAM 11g Academy series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html

A couple months ago Chris wrote a good post about the best way to deploy OAM from a web server / network architecture point of view.

Today, I’d like to touch on a very important but overlooked aspect of OAM deployments which is whether or not to use SSL between the web server and OAM. The product documentation and broader OAM writings out there in the community do a good job of describing the webgate to OAM server communication (OAP) security modes of open vs. simple vs. cert mode. However, what is completely neglected is the discussion of whether or not to use SSL between the web server and OAM.

SSL offloading and WebLogic server redux - client x.509 certificates

I recently had to revisit the subject of SSL offloading and WebLogic server to include the ability to do client certificate authentication. I was specifically doing this for use with Oracle Access Manager 11g, but the configuration steps are identical whether you are using OAM or just WebLogic.

Just to redraw the diagram so we're all on the same page, this is what a real environment with OAM in it might look like:

Note that I put "Apache" in front of the OAM server. That could be Apache, IIS, OHS or indeed any web server. In my case I happened to use Apache but the configuration is the same for Apache or OHS.

The first thing I had to do was configure Apache to support SSL. I'll leave that step up to you - just follow the normal instructions for your web server. Then I created a new VirtualHost for :443 that looks like this:

<VirtualHost *:443>  
  ServerName linux.ktest.oracleateam.com

  SSLEngine on  
  SSLProtocol all -SSLv2  
  SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW  
  SSLCertificateFile /home/oracle/simpleCA/linux.ktest.oracleateam.com.crt
  SSLCertificateKeyFile /home/oracle/simpleCA/linux.ktest.oracleateam.com.key
  
  <LocationMatch ^/oam/server/.*>
    SetHandler weblogic-handler
  </LocationMatch>
  
  <LocationMatch ^/oam/CredCollectServlet/X509.*>
    SSLVerifyClient require
    SSLVerifyDepth 1
    SSLCACertificateFile /home/oracle/simpleCA/ca.crt
    SSLOptions +StdEnvVars +ExportCertData
  </LocationMatch>
  
</VirtualHost>

There are a couple of interesting things in there.

1. The LocationMatch for "^/oam/server/.*" which routes any requests that match that regular expression on to the WebLogic plug-in so they can be sent to the OAM server
2. The LocationMatch for "^/oam/CredCollectServlet/X509.*" In OAM 11g the only URL that actually needs to require client certificate authentication is the x.509 credential collector. By putting "SSLVerifyClient require" on that Location we are telling Apache that unless the user presents a client certificate it should not process the request but instead demand a certificate from the user
3. The last item is the one that caused me grief - unless you add "SSLOptions +StdEnvVars +ExportCertData" mod_wl will not send the client certificate information down to the WebLogic server

That's all the configuration you need to do in Apache (or OHS). Now you need need to do a couple of steps inside WebLogic.

1. Check the "WebLogic Plugin Enabled" checkbox as we did in the previous blog post.
2. On the same page check the "Client Cert Proxy Enabled"

To reiterate where those are - go to the WebLogic Console (http://localhost:port/console), click on the domain name inside the left hand navigation tree, then click the Web Applications tab. You should find both of those settings towards the bottom of the screen.

That should be all you need to do.

5 minutes or less: User/Role API and SSL

This short post follows up Couple of things you need to know about the User/Role API. Now imagine that your LDAP identity provider is SSL enabled in 1-way mode (the server authenticates to the client, but the client does not authenticate to the server).

Now you need to tell Weblogic server how to validate the LDAP server certificate. And this is accomplished by adding the LDAP server CA certificate to the configured Weblogic trust store. If we’re talking about a self-signed certificate, simply add the certificate itself to the trust store. And there are a couple of options for the trust key store: Command Line, Custom Trust, Java Standard Trust or the OOTB Demo Trust. So far, so good. By adding the certificate to one of these options, Weblogic is all good to talk to the identity provider in SSL mode.

However, the User/Role API is not directly tied to Weblogic, so don’t expect it to take whatever is configured for the server. By default, as a standard Java-based client, the User/Role API looks for the standard Java $JDK_HOME/jre/lib/security/cacerts file, unless you tell it to look elsewhere, by informing the java system properties

javax.net.ssl.trustStore=<path_to_trust_store_file>
javax.net.ssl.trustStorePassword=<trust_store_password>

Relying on the original cacerts file may be dangerous in case you upgrade your JDK. If you need to leverage the existing certificates there, make a copy of the file and use the copy. Then simply tell the User/Role API where to read it from using the properties mentioned above.

Using the nsstools to manage SSL stores for curl

While working on today's research project I also needed to test with curl. Sadly in my environment curl was built with NSS support which caused me some grief. I had never used NSS-enabled apps before and didn't know how to deal with their certificate and private key database.

I do now.

SSL/TLS fun with client certificate authentication

Today's adventure was a question about limiting SSL connections.

The customer's problem statement was along the lines of

I want to make SSL connections, using client certificate auth (i.e. two-way ssl) and have the server accept only one certificate. Can I put the one cert I want in the "trusted CA list" to do that?

I thought the answer was "no, that's not how you do that" but I wasn't 100% sure so off I went on a research project...

Updated dead simple certificate authority

Back in April I posted a shell script I wrote to implement a dead simple Certificate Authority for testing purposes. I recently revisited that script because I needed JKS files in addition to the PEM format files it created.

Without further ado my new and improved script is available right after the break.

SSL offloading and WebLogic server

A couple of weeks ago I wrote about using Apache to simulate an SSL load balancer and showed this diagram:

One of the important things to note is that by default in this architecture WebLogic and any J2EE applications won't know that the user is using SSL to access the server because any calls to HttpServletRequest.isSecure() will return false!

There is a solution though - two configuration directives in the Weblogic web server plug-ins (mod_wl in Apache and OHS) allow you to tweak the behavior. Those directives are WLProxySSL and WLProxySSLPassThrough.

Using Apache to simulate an SSL Load balancer

Last week I needed to duplicate a customer's OAM 11g environment to help understand and resolve a problem they were having and needed to simulate a config that looks like this:

The numbers indicate the TCP port used on the server side. All of the red lines are HTTP. The green line (from OHS to the OAM Server) is the OAM NAP protocol.

Unfortunately I don't have a load balancer (an F5 in this particular case) handy so I needed to be a bit creative. Apache, mod_proxy and a little elbow grease can do much the same thing for simple testing purposes. In case you ever need to do the same thing here's a quick setup you can copy/paste to get you going.

SSLProxyEngine on
<Proxy *>
   Order deny,allow
   Allow from all
</Proxy>

RewriteEngine on
ProxyPreserveHost on

NameVirtualHost *:443

<VirtualHost *:443>
  ServerName login.oracledemo.com

  SSLEngine on
  SSLProtocol all -SSLv2
  SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
  SSLCertificateFile /home/oracle/simpleCA/login.oracledemo.com.crt
  SSLCertificateKeyFile /home/oracle/simpleCA/login.oracledemo.com.key

  ProxyPass / http://localhost:14100/
  ProxyPassReverse / http://localhost:14100/
</VirtualHost>

<VirtualHost *:443>
  ServerName idm11g.oracledemo.com

  SSLEngine on
  SSLProtocol all -SSLv2
  SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
  SSLCertificateFile /home/oracle/simpleCA/idm11g.oracledemo.com.crt
  SSLCertificateKeyFile /home/oracle/simpleCA/idm11g.oracledemo.com.key

  RequestHeader set IS_SSL ssl

  ProxyPass / http://localhost:7777/
  ProxyPassReverse / http://localhost:7777/
</VirtualHost>

There are a couple of interesting bits in that configuration...

First is that when you use mod_proxy Apache will use the host name in the URL specified in ProxyPass when it talks to the back end server. In this case that means that the OHS server would see a request with a host header that said "localhost:7777". Which can confuse the application and isn't at all what a conventional load balancer would do. Adding "ProxyPreserveHost on" to the configuration makes mod_proxy use the same name when it talks to the backend server (again OHS in my case) as the browser sent in the original request.

The other interesting thing there is that fact that I'm using NameVirtualHosts over SSL. Yeah, wait, wuh?! I can hear you now - I didn't think you could do that!

I thought the same thing until a few months ago when I stumbled across something called Server Name Indication. When SSL was first created IP addresses were freely available and nobody had invented name-based virtual hosting. As a result the initial SSL design didn't have the client send the requested host name as part of the initial handshake, and as a result the server had no way to know which certificate to send to the client.

Fast forward a few years and the situation has changed quite a bit. We're basically out of IPv4 addresses and name-based virtual hosting is practically the norm. The smart folks in charge of protocols and standards decided it was high time to fix that little oversight. RFC 3546 from June of 2003 documents the details.

Anyway, the only reason I go into all of that is to offer a warning: SSL protected Name-based virtual hosts **DO NOT** work with Internet Explorer on Windows XP. I know XP is on the downswing, but it still has something like 50% of the browser market share according to the first few hits I found a quick Google search.

Hope this helps someone else!

A dead simple certificate authority for testing purposes

I don't know about you, but I know I'd rather spend an hour writing a script to automate something than 30 minutes figuring out how to use an existing but annoying/terrible tool. I do that not because I am a glutton for punishment, but because I know I'll have to use that terrible tool again in the future and I won't remember how to use it anyway.

So when I needed certificates for a test environment I checked out OpenSSL's built in CA tool, quickly decided against using it, and then wrote my own simpler tool.

Enjoy!

Update: There's a new version of this script available in a new post

T3S -T3 over SSL

T3 is the protocol used for RMI communication with WebLogic server. T3S is the version of the protocol over SSL when secure communication is required.

I was going to write up a post about doing T3 over SSL as it seems to be something that people get hung up on.

However, Markus Eisele seems to have beaten me to it with an excellent and fairly comprehensive post.

I’d just like to add:

When you import the trusted CA into the default JVM cacert store make sure it is on the CLIENT JVM (and as the blog points out the correct JVM).

Also, rather than importing the trusted CA into the default JVM cacert store, you can create your own keystore and specify to the client SSL stack to use that store instead.

If you are using a standard J2SE stack for the client then you do this by starting the client with the following flags:

-Djavax.net.ssl.trustStore=**trustStore file path**
-Djavax.net.ssl.trustStorePassword=**trustStorePassword**

However, if you are using the WLS stack for the client you would do this with these flags:

-Dweblogic.security.TrustKeyStore=CustomTrust
-Dweblogic.security.CustomTrustKeyStoreFileName=**trust store file path**
-Dweblogic.security.CustomTrustKeyStorePassPhrase=**keystore pass phrase**