Enforcing HTTPS for Secure SAP BusinessObjects BI4

Many organizations just deploy SAP BusinessObjects without a thought for securing HTTP traffic or intra-server communication. But what you probably didn’t realize is basic packet sniffing tools can allow nefarious individuals within your own walls to watch those little packets of bytes fly by with Windows AD, LDAP, or SAP Authentication tokens included within them. So what is the probability that other, mission critical applications within your organization use those same authentication tokens? High. Very high. So what is an administrator to do? Let’s dissect.

SSL certificates can be a little intimidating when you first adopt. The first challenge is the implementation varies by web server and app server. The other challenge is that they may be perceived to being cost-prohibitive within your environment. In this post, I’m going to begin by helping with both the request process for your SSL certs and how to implement for the HTTP layer. My example deals strictly in what is known as a self-signed cert. That means:

Oh no! OK maybe it’s not that big of a deal. We’ll reflect on this further towards the end of the post.

To get this process rolling, we need a little prerequisite action: OpenSSL and SAP BusinessObjects BI4 installed.

OpenSSL is a simple prerequisite that I like to start with as a freely distributed library that is largely available as a default package for Unix/Linux platforms. It has also been packaged and made available for redistribution on Windows systems as well. I started out by pulling down and installing the Win32 OpenSSL v1.0.0f installer for 64-bt since I am working with Windows Server 2008 64-bit R2.

To begin this process, we have to simply install the OpenSSL libraries to generate the certificate request. It’s important to note that whether on Windows or Unix/Linux, this process below does not vary wildly.

As you progress note the crazy long path in SAP BusinessObjects Enterprise BI4 to keytool, the utility used to create your keystore and import certificates into it. I’ve laid my “variables” out clearly here.

My path to keytool: E:\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\jdk\bin
My path to openssl: E:\openssl\bin
My path to my certs: E:\ssl
My cert and keystore password: mypass

Let’s start by creating the keystore. Giving it a few command line arguments which include the path to the generated file prompts us for a default password (mypass) and some other organizational attributes:

Step 1
keytool -genkey -alias tomcat -keyalg RSA -keystore e:\ssl\.keystore

Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: EV
What is the name of your organizational unit?
[Unknown]: EV
What is the name of your organization?
[Unknown]: EV
What is the name of your City or Locality?
[Unknown]: EV
What is the name of your State or Province?
[Unknown]: EV
What is the two-letter country code for this unit?
[Unknown]: EV
Is CN=EV, OU=EV, O=EV, L=EV, ST=EV, C=EV correct?
[no]: yes

Enter key password for
(RETURN if same as keystore password):
Re-enter new password: mypass

Alright. Now we have an encrypted keystore. Note: If not obvious, the stronger you make that keystore password, the better off you are.

Step 2
Next, we are going to hop over to OpenSSL to generate the infrastructure to build our self-signed certificate capability out by generating a server key.

openssl genrsa -des3 -out e:\ssl\server.key 4096

Loading ‘screen’ into random state – done
Generating RSA private key, 4096 bit long modulus
………………….++
……………..++
e is 65537 (0x10001)
Enter pass phrase for e:\ssl\server.key: mypass
Verifying – Enter pass phrase for e:\ssl\server.key: mypass

Step 3
With a server key in place, next a certificate request is generated based upon that original server.key.

openssl req -new -key e:\ssl\server.key -out e:\ssl\server.csr

Enter pass phrase for e:\ssl\server.key:
Loading ‘screen’ into random state – done
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:IL
Locality Name (eg, city) []:Troy
Organization Name (eg, company) [Internet Widgits Pty Ltd]:EVT
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:evtbobj6
Email Address []:[email protected]

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:mypass
An optional company name []:EVT

That was not so bad….I think.

Step 4
Next, with our certificate request and server key, we can digitally sign the ssl self-signed certificate to a file server.crt.

openssl x509 -req -days 999 -in e:\ssl\server.csr -signkey e:\ssl\server.key -out e:\ssl\server.crt

Loading ‘screen’ into random state – done
Signature ok
subject=/C=US/ST=IL/L=Troy/O=EVT/OU=IT/CN=evtbobj6/emailAddress=info@evtechnolog
ies.com
Getting Private key
Enter pass phrase for e:\ssl\server.key:

Step 5
Lastly, with the cert in hand, we can use keytool one last time to suck that guy into our keystore that we created in step 1.

Editorial note: it is at this point where perhaps you’ve sent that .csr file off to a real certificate authority to get a legit, signed cert. That’s great! Your users won’t get security warnings. You can import that .crt into your keystore and you are good go to.

keytool -import -alias root -keystore e:\ssl\.keystore -trustcacerts -file e:\ssl\server.crt

Enter keystore password:
Owner: [email protected], CN=evtbobj6, OU=IT, O=EVT, L=Troy,
ST=IL, C=US
Issuer: [email protected], CN=evtbobj6, OU=IT, O=EVT, L=Troy,
ST=IL, C=US
Serial number: bea54a54263b3f2e
Valid from: Mon Jan 23 19:00:55 PST 2012 until: Sat Oct 18 20:00:55 PDT 2014
Certificate fingerprints:
MD5: 6B:80:5E:F3:12:2E:BA:E4:70:4F:06:B3:CD:D4:B7:B1
SHA1: 0A:51:1F:FB:12:FD:2C:81:78:EA:C5:28:5D:91:95:53:CE:D8:E1:6B
Signature algorithm name: SHA1withRSA
Version: 1
Trust this certificate? [no]: yes
Certificate was added to keystore

Step 6
Tomcat needs one last tweak to care about that keystore now. Browse to your Tomcat6/conf folder and open server.xml.

There is an XML node for Connector port=”8443″ that must be uncommented and then pay particular note to the last line. Your file will not have this initially and should.

Restart Tomcat and note now that your web server is accessible via https on port 8443. Yes, we already know about the certificate error.

So reflecting, let’s think about the implications:

• HTTPS is good in all environments.
  
• Your users might REALLY appreciate it you change port 8443 to 443 in your server.xml to drop the requirement to specify a port (443 is the default SSL port).
  
• HTTP traffic is easy to encrypt, both via a self-signed certificate or a legitimate certificate built by a certificate authority.
  
• A certificate from a certificate authority builds a better user experience, but used internally may not be necessary.
• Self-signed certificates are ideal for lower environments like dev, test, sandboxes, etc.
  
• There are very affordable certificate authorities like ClickSSL.com that do not want your first born for a cert.
• You can educate users pretty easily to trust an internal site using a self-signed certificate to avoid acquiring a real certificate
• If your SAP BusinessObjects BI4 environment is an externally facing application or requires integration via mobile, web services, or other external interface, you WILL want to get a legit cert from a certificate authority. Many applications will not support the self-signed certificate.

To bring us to a close, let’s recap the steps at a high level here.

1. Create your keystore to hold your certs with keytool.
2. Use openssl to create your server key.
3. Generate your certificate request with openssl.
4. If generating a self-signed cert, using openssl to sign the certificate request to create a cert.
5. Import the cert into the keystore in step 1 using keytool.
6. Let Tomcat know htat it should watch for HTTP requests on the desired port and map to your keystore.

Next time we’re going to tackle applying SSL to the Server Intelligence Agent. Stay tuned.