SAP Network Blog: Encryption everywhere -- Securing your Duet landscape

This blog grew and grew in size. So instead of creating multiple blogs I am trying to structure eveything in a table of content:

In a Duet landscape you have three main server components that interact: the ABAP backend, the J2EE Engine and the Internet Information Server (IIS). Usually you start with a non-SSL configuration and get the system going in a non-secure way. At most customers I have been with, this is fine but sometimes you want to / have to make it more secure.

In the following paragraphs I will outline the basic steps on what settings have to be done. For all of these components there are already great individual documents / blogs / sites available, so after each section I will list some links as reference and further reading.

(General information regarding security in a NetWeaver landscape can be found here: SAP NetWeaver Application Server Security Guide and Network Security for SAP Web AS ABAP)

Preparing J2EE Engine

Before we can secure any communication to the J2EE we have to enable SSL on it. In order to do that you have to go to the Visual admin. In the Key Storage -> service_ssl you can see the SSL certificates that are available. If you have an official signed certificate you can add this certificate via Entry -> Load. By default there is a self signed certificate valid for the localhost.

Once you have the certificate in the Key Storage you can go to Dispatcher -> Services -> SSL Provider and select this certificate from the Server Identity tab. If the SSL provider is stopped, activate it by right-clicking -> Start.

In the upper part you can see the SSL port that is used for your J2EE Engine (the default port for SSL on the J2EE is 5<SystemNumber>01). With this information you can access the J2EE Engine by calling https://duetserver:50001/. Depending on the certificate you have, you might get a certificate warning. Let’s take a closer look, because we can use this knowledge for the ABAP certificate as well:

In my example I am getting all three warnings:
the certificate is issued by a company you have not chosen to trust (which just means that my browser does not yet know the certificate and it is not signed by a so called root certificate that is trusted)
the security has expired or is not yet valid (well, I guess this is self explaining; each certificate is valid only for a certain amount of time – mine is already expired)
The name of the security certificate is invalid or does not match the name of the site (here the most common problem is “does not match the name of the site”. I have accessed the J2EE Engine via http://DuetServer:50001. This is the hostname of the J2EE Engine, but the certificate was issued for localhost [as you can see in the next screenshot]. When creating the certificate make sure that it matches the URL you are going to use for calls from the Client and the ABAP server)

OK, now after getting these three warnings, I have requested a correct certificate and I have installed it on the J2EE. When I call the URL now, and take a look at the certificate everything is fine.

Links for securing J2EE Engine

Preparing the ABAP system

The J2EE Engine can access the ABAP system in two ways: via WebService calls and RFCs. For both we have to make sure that they are encrypted.

HTTP -> HTTPS

The WebService-calls use ICM to connect. If you go to transaction SICM you can select Goto -> Parameters -> Display which will show you the current configuration:

Here you can see that HTTPS is not yet enabled (if you can already see an entry like icm/server_port_2 = PROT=HTTPS, PORT=8081 then your system is already configured for HTTPS using port 8081). Instead of listing all the steps here in the blog I strongly recommend to take a look at the links mentioned below. The information in the Note, on help.sap.com and the blogs are already great! You basically just have to set some parameters in RZ10 and create a SSL server Standard certificate.
After following all these steps you should see at least two green lights in STRUST:

If you go back to SMICM and select Goto -> Services. You should also see the entry for HTTPS:

With this information open a browser window and just call https://%3Cabap%3E/sap/bc/bsp/sap/it00/default.htm You will be prompted for username & password, but that is fine. The important thing is that you either get a Certificate warning again (like before with the J2EE Engine) or that you see the small Security lock in the bottom of your Internet Explorer (indicating that you have accessed a secure web site). If you double click there than you should see the valid certificate.

Links for securing ABAP HTTP

RFC -> SNC

As you probably know Duet makes some calls from the J2EE Engine to the ABAP system via RFC / JCo calls. In order to have a secure communication there we have to use Secure Network Communications (SNC).
Again please follow the links mentioned below. This time it is a little more complicated because you have to follow some steps in ABAP and on the J2EE.
On the ABAP side it is important that the SNC SAPCryptolib is active in STRUST. You might also consider to set the parameters like snc/accept_insecure_gui, snc/accept_insecure_cpic, snc/accept_insecure_rfc, snc/accept_insecure_r3int_rfc, snc/enable, (see here for details) to enable also non-secure connections in parallel.
If that is done, check the SNC Status via SM51 -> GOTO -> SNC Status (Ctrl – F10)

On the J2EE Engine we also have to create a PSE first. In short you have to download / install the SAP Cryptographic Library on the J2EE (don’t forget to set the Environment variable SECUDIR). Then you have to create a new PSE file. In my example I have put all the files in D:\usr\sap\SAPCryptolib:

D:\usr\sap\SAPCryptolib>sapgenpse gen_pse -p SP2-ASJava.pse

Please enter PIN:

Please reenter PIN:

get_pse: Distinguished name of PSE owner: CN=ASJAVA, O=RIG, C=DE

PKCS#10 certificate request for "D:\usr\sap\SAPCryptolib\sec\SP2-ASJava.pse":

-----BEGIN CERTIFICATE REQUEST-----

xxx

-----END CERTIFICATE REQUEST-----

Now export the client certificate for later:

D:\usr\sap\SAPCryptolib>sapgenpse export_own_cert -v -p SP2-ASJava.pse -o SP2-ASJava.crt

Opening PSE "D:\usr\sap\SAPCryptolib\sec\SP2-ASJava.pse"...

No SSO credentials found for this PSE.

Please enter PIN:

PSE (v2) open ok.

Retrieving my certificate... ok.

Writing to file (PEM-framed base64-encoded)... ok.

SP2-ASJava.crt is created.

Then import the CRT via STRUST in the SNC store of the ABAP system:

Before we export the ABAP SNC server certificate we can set the ACL for this J2EE certificate (SM30 -> table SNCSYSACL, view VSNCSYSACL, type=E):

Next export the SNC server certificate:

Then import this certificate to the Client PSE:

D:\usr\sap\SAPCryptolib>sapgenpse maintain_pk -v -a E05-SNC.crt -p SP2-ASJava.pse

Opening PSE "D:\usr\sap\SAPCryptolib\sec\SP2-ASJava.pse"...

No SSO credentials found for this PSE.

Please enter PIN:

PSE (v2) open ok.

retrieving PKList

Adding new certificate from file "E05-SNC.crt"

----------

Subject : CN=E05, OU=ISAP-INTERN, OU=SAP Web AS, O=SAP Trust Community, C=DE

Issuer : CN=E05, OU=ISAP-INTERN, OU=SAP Web AS, O=SAP Trust Community, C=DE

Serialno: 00

KeyInfo : RSA, 1024-bit

Validity - NotBefore: Sun Aug 16 09:41:04 2009 (090816084104Z)

NotAfter: Fri Jan 1 01:00:01 2038 (380101000001Z)

----------------------------------------------------------------------------

PKList updated (1 entries total, 1 newly added)

Then create a cred_v2 file:

D:\usr\sap\SAPCryptolib>sapgenpse seclogin -p SP2-ASJava.pse -O devwdf16\SAPServiceSP2

running seclogin with USER="SAPServiceSP2"

creating credentials for user "DEVWDF16\SAPServiceSP2"...

Please enter PIN:

Adjusting credentials and PSE ACLs to include "DEVWDF16\SAPServiceSP2"...

Oh, you supplied your own name explicitly ... ok.

D:\usr\sap\SAPCryptolib\sec\cred_v2 ... ok.

D:\usr\sap\SAPCryptolib\sec\SP2-ASJava.pse ... ok.

Added SSO-credentials for PSE "D:\usr\sap\SAPCryptolib\sec\SP2-ASJava.pse"

"CN=ASJAVA, O=RIG, C=DE"

That should be it.

Links for securing JCo

Preparing the IIS

In order to enable the IIS for SSL you have to create a certificate request first which you then have to sign by a certificate authority. The steps are all outlined in “How to implement SSL in IIS” mentioned below.
For my test I was using a self signed certificate which I created with the help of SSLDiag.exe which is part of the IIS Diagnostics Toolkit / http://www.microsoft.com/downloads/details.aspx?familyid=9bfa49bc-376b-4a54-95aa-73c9156706e7&displaylang=en.
For this I just ran
SSLDiag.exe /s:X /selfssl /n:CN=myduet.server.com
Where X is the number of the WebSite that is used by the Duet components (1 to 4 in my case)

After that make sure that you set a SSL port in each web Site property

Now restart the IIS and you should be able to access all MSFT Duet WebServices on the IIS via HTTPS.
https://IIS-Server:1081/RequestHandler/RequestHandler.asmx
https://vmw2626.wdf.sap.corp:8091/DuetReadService.asmx
https://vmw2626:8092/DuetServiceProvider.asmx
https://vmw2626:8093/DuetAzManService.asmx

Links for securing IIS

How to implement SSL in IIS

Now all components should be ready for a secure connection. Since we did not configure the components to only accept secure calls you can still run the landscape in “non-ssl mode”. So I would always recommend to start with a non-secure setup and only once that is working continue with the following steps in which we connect the components.

J2EE to ABAP

HTTP Connection

Like previously mentioned the J2EE Engine uses HTTP and JCo to connect to the ABAP system. So let’s start with HTTP.
With Duet 1.5 SP3, configuring HTTPS is quite simple. At first you have to exchange the certificates.
For this go to STRUST on the ABAP system and export the SSL server Standard certificate (you do not have to do this if the certificate is signed and the J2EE engine already trusts the signer)

Then go to the J2EE -> Visual Admin and import the certificate as a trustedCA

Now the SSL connection should work.

If you want, you can verify these settings by performing the following steps (they are not required for setting up a secure Deut landscape, but show that SSL is working now): Go to Destinations in the Visual Admin and create a dummy HTTP conection under HTTP and enter the URL http://%3Cabap-sever%3E/sap/bc/bsp/sap/it00/default.htm

After entering a username and password, a "Save and Test" should work fine.
Now change the URL to HTTPS and don’t forget to adjust the port to the SSL port on the ABAP system (that’s the one that was visible in SMICM before). A test should still work.

As a final step you have to tell Duet to use SSL now. To do that go to System Environment -> Landscape -> SAP Systems and select the backend system that you want to connect to via SSL.

The SSL port should be fetched automatically and it should be displayed under Port.
As a final test, lets call the Web Service navigator and call a simple URL: http://J2EE-Engine:50000/wsnavigator. In my case I have Leave Management deployed, so I select the LeaveManagementFacadeWS -> Test -> getLeaveInfo

After entering end-users credentials you should get a valid response.

If you want to be very thourough you can also monitor the call with a HTTP tracer like YaTT. Here the SSL port has to be used and you should not be able to see anything (in contrast to a HTTP call where you would see the clear response & reply):

Links for HTTP Connection

Configuration of the Web Service SSL Connection

JCO -> Calls

We have already exchanged the certificates on the J2EE and the ABAP System. So the final step is to change the configuration:

If the configuration for SNC as mentioned before is done, then this step is fairly simple: Go to Visual Admin -> Server -> Services -> Destinations -> RFC -> (Select your System you want to connect to)

When you go to the SNC tab select “Active” and enter the data for My SNC name, SNC partner name and SNC Library Path.

Click on “Save and Test” and you should be done.

Links for JCO -> Calls

ABAP to J2EE

This way should be fairly simple again. During your Duet configuration you have setup at least one RFC destination via SM59 that points to the J2EE Engine. Right now it probably points to the default HTTP port 50000. All we have to do is change this to the SSL port defined earlier.
So go to Visual Admin and export the certificate (the one that you chose in Server Identity tab when preparing J2EE Engine) by clicking on Export:

On the ABAP side go to STRUST and add this certificate to SSL Client (Standard)

Then go to SM59, select the RFC destination, click on the tab „Technical Settings” and change the port. Then go to Logon & Security and under Status of Secure Protocol click on Active. Since we exchanged the SSL Certificates under Standard, select this entry in the drop down

Now you should test the connection. If you get an ICM error, go to SMICM -> Goto -> Trace File -> Display End. Here you will see more details, e.g.

In this example I have not imported the J2EE certificate to the ABAP system. So something must have gone wrong when using STRUST. Go back and make sure that the J2EE certificate is really under SSL client SSL Client (Standard) like mentioned before. You might also want to restart ICM via SMICM -> Administration -> ICM -> Exit Soft -> Global to check if this has any effect.

Links for ABAP to J2EE

J2EE to IIS

The J2EE connects to the IIS via three web sites: the Request Handler, the Service Provider and the AzMan service. We already enabled SSL for all of them so we just have to trust the certificate of the IIS and change the configuration of these services from the Duet Admin page.

For the trusting part, just export the certificate used by the IIS and import it to the Key Store via Visual admin (same as before with the J2EE to ABAP HTTP connection).

To change the configuration go to /duet -> System Environment -> Landscape -> Microsoft Components -> Request Handler. Here select Use SSL and change the port to the SSL port.

Currently we do have an issue with configuring the Metadata service via SSL to the IIS via the UI. So you have to go to the Visual Admin and change the corresponding destinations manually:
Go to Server -> Services -> Destinations -> WebServices and select sap.com/xapps~osp~fw~wsproxies/com.sap.xapps.osp.fw.wsproxies.azman.AzmanService/DuetAZManServiceProviderSoap
Now in the URL change the protocol to HTTPs and the port to the SSL-Port

Click on Save and Test to make sure the settings are correct.
Do the same for sap.com/xapps~osp~fw~wsproxies/com.sap.xapps.osp.fw.wsproxies.msft.ServiceProvider/ServiceProviderServiceSoap

Again click Save and Test to make sure the settings are correct.

Clients To J2EE

In the Duet Administration go to System Environment -> Landscape and enter the settings for HTTPS Port for Duet Server and Duet Server AddOn.

Then go to General Settings and Tools and under General -> Authentication select the Authentication method: Kerberos with SSL

That should be it. The next time the client fetches new metadata it will then retrieve the data via HTTPS from the J2EE Engine.

There are only very few items left: the connection from the J2EE to the Active Directory and the connection from the Request Handler to the Exchange.

I have not covered the part where the Client gets the data from the Read Service via SSL. Ideally you should only have to configure the IIS on the ReadService to use SSL and then change the URL in the Group Policies for the ReadService to SSL -- unfortunately we have currently an issue here which will be fixed with the next patch. If you still want/have to use this, there is a workaround in place.

J2EE to ADS

To finish your secure Duet landscape you should also encrypt the communication from the J2EE Engine to the ADS. This is again quite well documented (and simple), so I am just referring to the links mentioned below.
Basically you just have to exchange certificates again and then via Config Tool change the port and enable SSL:

Links J2EE to ADS

RequestHandler to Exchange

Once you have installed the Request Handler (if you have not yet installed with SSL from the beginning) you can open and edit the file C:\Inetpub\RequestHandlerRoot\RequestHandler\web.config. There you just have to change the configuration in two or three places:

The first two parameters (Exchange Server & Protocol) are mandatory for SSL. You have to adjust them. The third parameter “Trusted” can be set to 1 if the client on the Exchange is not a 100% valid certificate (e.g. when you access the Exchange server with a name that is not mentioned in the certificate).
In order to easily test the request handler I would recommend to execute the following Java Script file. It will just connect to the RequestHandler and send a dummy controlmessage to the client. This controlmessages will of course not be processed, but if you see it in the OBAControlMessage folder you know that the connection from Request Handler to the Exchange is working (if you sent it to a non-Duet client, you will see the ControlMessage in the Inbox)
Copy the context in the text box below in a file, adjust some strings (

http://localhost:1080/ -- Server/Port of the Request Handler
full.domain.name\\SAPAgentUser -- SAPAgent user
PasswordOfSAPAentUser -- Password of SAPAgent user
SAPAgentUser@EmailAdress -- SAPAgent user email address
ReceiverName@EmailAdress -- Adress who should get the test email)

and add the extension .JS (for JavaScript), then just execute it.

function sendControlMessage(body){ var req = new ActiveXObject("Microsoft.XMLHTTP"); req.open("POST","http://localhost:1080/RequestHandler/RequestHandler.asmx",false,"full.domain.name\\SAPAgentUser","PasswordOfSAPAentUser"); req.setRequestHeader("Content-type","text/xml"); req.setRequestHeader("SOAPAction","Microsoft.OBA.Formatter/Create"); req.send('<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body>' + '<Create xmlns="Microsoft.OBA.Formatter"><createRequest><FolderPath>Inbox</FolderPath><Sender Email="SAPAgentUser@EmailAdress"><BindingInfo BoundItemType="urn:sap:office:mySAP:ReportingManagementReports" BoundItemId="{B50A2970-AD10-4AB2-9821-5EED76D0AFA4}" CorrelationId="32042938420948234"></BindingInfo><Recipients><User Email="ReceiverName@EmailAdress"></User></Recipients><BoundData><XmlData><foo><foobar id="342"/></foo></XmlData></BoundData><Presentation Subject="Test Control Message"><Body>' + body + '</Body><Attachments></Attachments></Presentation></createRequest></Create>' + '</soap:Body></soap:Envelope>'); WScript.Echo(req.status + '\n' + req.responseXML.xml); } sendControlMessage("Test Control Message");

I hope I have covered all (except one) security related aspects of a Duet landscape. I will continue to update / work on these topics in related Wiki pages in the Duet area.

Holger Bruchelt is part of the Solution Management team for Duet Enterprise. Before that he has been working in the Regional Implementation Group for Duet and Duet Enterprise and was a technical NetWeaver consultant since 2002.

Encryption everywhere -- Securing your Duet landscape Holger Bruchelt Business Card Company: SAP AG Posted on Oct. 03, 2009 09:44 AM in Duet, SAP NetWeaver Platform, Security, SAP xApps

Preparing J2EE Engine

Links for securing J2EE Engine

Preparing the ABAP system

HTTP -> HTTPS

Links for securing ABAP HTTP

RFC -> SNC

Links for securing JCo

Preparing the IIS

Links for securing IIS

J2EE to ABAP

HTTP Connection

Links for HTTP Connection

JCO -> Calls

Links for JCO -> Calls

ABAP to J2EE

Links for ABAP to J2EE

J2EE to IIS

Clients To J2EE

J2EE to ADS

Links J2EE to ADS

RequestHandler to Exchange

Encryption everywhere -- Securing your Duet landscape
Holger Bruchelt
Business Card
Company: SAP AG
Posted on Oct. 03, 2009 09:44 AM in Duet, SAP NetWeaver Platform, Security, SAP xApps