Kevin Kempf's Blog

July 23, 2010

Securing EM 11g with your own SSL cert

Filed under: Enterprise Manager, Oracle — kkempf @ 6:24 pm

A bit of a teaser

I recently had a miserable SR with Oracle regarding how to replace their “canned” certificate (part of the 11g install) with my own, real domain certificate.  In the end, I was told that unless I was using SSO, it was not supported.

This answer didn’t sit right with me, but I would never call SSL and certificates one of my strengths.  When my sysadmin/Linux counterpart heard this answer, he spent the day trying to prove Oracle wrong.. I sat shotgun for the ride.

The Short Answer

I’m sure it’s completely unsupported, but it’s not an external product; it’s only used within IT so it felt safe enough to “play” in.  In the end, he figured out how to get our certificate and key into a p12 wallet file via a pki tool and landed them on the server (.sso and .p12 file) where the existing (Oracle HTTP server) files were.  Yeah, that’s right.  EM 11g runs on Weblogic, which only serves as a container for the old Oracle HTTP Server.  In other words, it’s iAS running inside Weblogic.  The actual certificates are under an OHS directory.  Once replaced, the main website was using “our” certificate (https://hostname:1159/em).  Then the agents stopped communicating with the OMS; the temporary fix was to go do an emctl unsecure agent on all the servers.  Not ideal, we’ll work more on that later.  Consider this a “post in progress”.  Am I the only one who finds it ridiculous that Oracle “doesn’t support” using a real cert for EM?

The Messages I no longer see

Chrome:
The site’s security certificate is not trusted!
You attempted to reach hostname.com, but the server presented a certificate issued by an entity that is not trusted by your computer’s operating system. This may mean that the server has generated its own security credentials, which Google Chrome cannot rely on for identity information, or an attacker may be trying to intercept your communications. You should not proceed, especially if you have never seen this warning before for this site.

IE:
There is a problem with this website’s security certificate.

The security certificate presented by this website was not issued by a trusted certificate authority.

Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage and do not continue to this website.
Click here to close this webpage.
Continue to this website (not recommended).

Overview of the solution

If you can find a way to get your certificate, key and any intermediate certificates into a standard keystore, you’re in good shape.  We had a problem because apparently Oracle doesn’t like wildcards in the certificate name (*.domainname.com).  So the admin used the pki tool to create a p12, then imported it into Oracle Wallet Manager.  From here, you can select the Wallet menu option, then “Auto Logon”.  Now when you save it, you get the .sso file as well.  Land the cwallet.sso and the ewallet.p12 file in gc_inst/WebTierIH1/config/OHS/ohs1/keystores/upload and restart services.  Remember to unsecure your agents; I’ll update the post if we figure out what’s messing those up.

Follow Up

It appears that the fix which we stumbled upon can be mostly accomplished (except never in the case of wildcard certificates) from the command line with emctl.

To secure the console, use emctl secure console and point it to your own certificate wallet directory.

To secure the oms, use emctl secure oms and point it to your wallet and trusted cert location.  There is a catch to this, however.  You cannot use a *.domainname.com (wildcard) cert for this, as the agents pull this certificate and attempt to connect to *.domainname.com (instead of a real server name).  In our case, if we had a certificate with the exact server EM is running on, this would have worked as well.

Another oddity is the number of ports opened and said to be in use (which may or may not be the case).  In any case, I recommend typing emctl status oms -details to determine what ports are actually available for login.  They may or may not correspond to what WebLogic says.  In our case, https for our own certificate changed to 4444 by default.  We over-rode ssl.conf to change it to 8443, but it’s still a bit of conFUSION as to why Weblogic rarely agrees with EM on what is running where.

Advertisements

2 Comments

  1. Wow! Last October I attempted to replace the default certificae with our own internally issued cert as described in your note. Time being a rare commodity, I quickly gave up and posted on OTN…to no avail. Today I decided to try again. Then I stumbled on your blog. You’ve convinced me to unlock oms. Thanks sparing me from yet another SR rabbit hole!

    Comment by Pat — February 27, 2011 @ 9:25 am

  2. Securing Grid Control 11g with our own certificates is done at two layers – weblogic layer and OHS layer. Check http://pirabid.blogspot.com/2011/03/securing-ohs-layer-and-disabling-non.html for OHS layer

    Hope this is of help to others, and Kevin, to you too

    -cheers
    Abid

    Comment by Abid — May 11, 2011 @ 2:49 am


RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Create a free website or blog at WordPress.com.