Help with understanding SSL on Netweaver 7.1 and the relevant key stores.

[Former Member]

I am having a great difficulty in understanding how SAP manages and uses SSL certificates in Netweaver 7.1. More specifically, what the difference is between System, Server, and Client.

As I can see, there are three PSE key stores I see within STRUST.

1. SSL System PSE

2. SSL Server PSE

3. SSL Client PSE

The System PSE I believe is installed by default and enables the systems to communicate between each other, such as Application Servers and the Central Instance.

The Server PSE is the where I store the certificate I generated and had signed by a CA (certificate authority). It contains a root and intermediate certificate and both have been imported back into the Server PSE store. When partners connect to me and I agree to accept server only authentication, it is this cert that identifies my server as a trusted server the partner. Do I need to add the partneru2019s u201Crootu201D or u201Cintermediateu201D certs to my Server PSE in order to allow SSL login?

The Client PSE is where I store partneru2019s client certificates that I allow to login via u201Cclientu201D authentication. Without their key installed in this store, they will not be allowed to login via SSL.

When I wish to make connections to partners, I will take my Server key from the Server PSE, export the key, and send it to the partner so they can import it in their key store.

Does the above sounds right? Any clarification would be greatly appreciated.

Thanks,

Mike.

P.S. I also have questions about how and if certificates are synchronized from the ABAP stack (STRUST) to the JAVA stack (Netweaver Administrator), as keys can be stored in either direction. If not, does where you store the certificate depend if it is an ABAP or JAVA type connection?

[sebastian_broll]

hi michael,

<br />

please be careful - actually, there is NO SSL System PSE.<br />

There is only a so called "System PSE", which is not at all related to SSL.<br />

<br />

The PSEs actually available for SSL as default are:<br />

<br />

- the SSL Server PSE (which is a rather complicated construction ... see below) [mandatory]<br />

- the SSL Client PSE (standard) <br />

- the SSL Client PSE (anonymous)<br />

<br />

Looking at connections using HTTPS/SSL, you always have two communication partners: an entity issuing a request, named the "client", and another entity, to which the request is sent in order to be responded to, named the "server".

Since an SAP ABAP system can be either client or server in this setup, we have the chance to provide different security environments (= PSE) for these communication roles.<br />

<br />

When the SAP system initializes a HTTPS communication, it will make use of one of the SSL Client PSEs. These PSEs mainly serve the purpose of storing the CA certificates that are trusted. Only servers whose server certificate is signed by a CA where the CA root certificate is contained in the SSL Client PSE can be connected to. If the server's certificate is not trusted, the error message "verification of the server's certificate chain faile" will appear in the ICM trace (see note 1094342).<br />

<br />

The difference between SSl Client PSEs "standard" and "anonymous" is the actual certificate - the "anonymous" PSE always contains the distinguished name (DN) "CN=anonymous", which can not be used for client authentication. In contrast, the "standard" PSE's DN can be defined freely, so this PSE can be signed by a CA and furthermore used for client authentication.<br />

<br />

Now for the SSL Server PSE.<br />

As mentioned already, the SSL Server PSE can be a complicated thing ... actually, this PSE is only a container for more PSEs. There must be at least the "default" PSE (unfortunately also called "standard"), and there can be up to 1 PSE for each application server.<br />

In a standard setup, the default PSE is used only for those cases where no application server specific PSE applies. The application server specific PSEs are supposed to be the ones that are actually used by the ICM.<br />

<br />

What does "up to 1 per AS" mean? Well - as soon as two SSL Server PSEs use the same DN, these PSEs are no longer distinguished, and will be mapped to the same PSE data (key pair, certificate list). So, if you define the same DN for several application servers, only one PSE is created and used by both application servers.<br />

<br />

I hope this (lengthy) epistle anwers more question than opens new ones...<br />

<br />

regards,<br />

sebastian

Edited by: Sebastian Broll on Apr 8, 2010 8:07 AM (formatting)

[sebastian_broll]

As for the other questions...<br />

<br />

The SSL server PSE used by ICM should be CA signed (create certificate request ... import certificate response) as described by note 510007.<br />

The certificates of the clients never need to be imported into the SSL Server PSE.<br />

<br />

Only if you want to enable the system to authenticate the clients, you need to import into the SSL Server PSE the CA certificate that has been used to sign (issue) the client certificates.<br />

<br />

The SSL client PSE is not related to authenticating external clients to your SAP server.<br />

<br />

As for the synchronization between ABAP and Java stack - no, there is no synchronization as such. The certificate stores of ABAP stack and Java stack are maintained seperately. Only since release 7.10, you can determine in a dual stack system which of the certificate stores is to be used for ICM. See note 1304687 for the related discussion.<br />

[Former Member]

Okay, let me seeu2026

SSL Server PSE: Is only used to accept/receive u201Cclientu201D connections. The key that I install here is the one that I generated via the CSR (request) and CSR (response) from the CA. If I just want u201CServer Authentication this is enough. If I want to also enable u201CClient Authenticationu201D I also need to import their CA certificate, Root or Intermediate, into the Server PSE.

SSL Client PSE (standard): Is used when I as a client, wish to connect to another u201Cserveru201D. The key that is installed here is either the u201CRootu201D Certificate or Intermediate Certificate of the server I wish to connect to. This is not the key from the SSL Server Store, but the one from the server I am connecting to. It provides a list of Certificate Servers I am u201Cauthorizedu201D to connect to.

Does the above sound correct?

If so, next question:

1. As a server, for u201CServer Authentication I simply install my CA certificate in my SSL Server PSE and allow clients to connect to me and they decide if they trust me. Additionally I can use u201CClient Authenticationu201D by installing their CA Root or Intermediate Certificate in the Server PSE. Does this u201Cforceu201D Client Authentication for all incoming connections?

2. Also, there is a way to tie the clientu2019s certificate to a user using EXTID_DN (ABAP) or NWA (JAVA). Where does this come in? Is this to allow permissions to conduct specific transactions? Do I need a user for each partner, or is it a general user for all partners (i.e. can I create a SOAP user and just tie all partners that are using SOAP to the same user)?

Sebastian, thanks.

Mike

[sebastian_broll]

Next questions ..., ;-)<br/>

<br/>

As for 1.)<br/>

No.<br/>

You use the profile parameter icm/HTTPS/verify_client to configure the system wide requirements concerning X.509 client certificates.<br/>

Values --> Meaning<br/>

0 --> X.509 client certificates are not used<br/>

1 --> X.509 client certificates may be used (default)<br/>

2 --> X.509 client certificates are mandatory<br/>

<br/>

For service specific requirements, you may modify the security settings in transaction SICF according to your needs.<br/>

<br/>

As for 2.)<br/>

The user mapping for X.509 client certificates is provided in the view VUSREXTID. Please search the online help for that view name for further information - sorry, but currently I cannot provide the direct links (networking problems). <br/>

I never tried to map multiple certificates to a single SAP-internal user, so I cannot comment on this.<br/>

<br/>

Cheers,<br/>

Sebastian<br/>

Edited by: Sebastian Broll on Apr 9, 2010 9:22 AM

[Former Member]

Sebastian,

I think I may have made a mistake. When I created the CSR and imported the response, I only did so for the SSL Server PSE store. However, I believe this must also be done for the "SSL Client PSE (standard)" store as well. Initially all I thought I had to do was install the partner's key in my Client PSE store, and only my Server PSE needed CA signatures (inbound transactions). If I attempt to connect to an SSL Sever, it it requires a Client Certificate, the one that will be sent from my system is the CA Signed Client Certificate. Currently the only one in there is the default "Self-Signed" certificate and this is being rejected by the remote partner. Does this make sense?

Also, depending on the type of transaction, I will have to do this from both STRUST (ABAP) and NWA (JAVA). It appears only the Server PSE can be managed by a single SSL Admin tool.

Thanks.

[sebastian_broll]

Hi Michael,<br/>

<br/>

for SSL Server PSE creation - you always create both the default SSL Server PSE and the application server specific SSL Server PSEs in the same step. It depends on the DNs you specify what will be the outcome of this step.<br/>

You can also change (add, remove) application server specific SSL Server PSEs at a later point in time, but not the default SSL Server PSE.<br/>

<br/>

The certificate from a self signed SSL Client PSE (standard) will be rejected by a peer server - that's correct according to the related RFCs (RFC = request for comments), as client authentication is supposed to be based on V3 certificates. Self signed certificates typically are V1, so you'll need to have it signed by a CA to make it V3.<br/>

<br/>

See note 1304687, too.<br/>

<br/>

Hope this helps ...<br/>

regards,<br/>

sebastian

[Former Member]

Um....

I do have multiple Application Servers, however only one server can accept Inbound SSL (Server) connections, which is the Central Instance. Does this mean I currently do not need Server PSEs on the Application Servers?

There are plans to implement Web Dispatcher in the near future, when that happens I assume the Server PSEs for the application servers will become necessary. One note, the Web Dispatcher is not planned to terminate the SSL, they want to do that at the AS or CI, which again is confusing because the Server PSE Certificate will not match the Web Dispatcher's FQDN which I think will result in mismatch errors by external partners.

As for the Client PSEs, it makes sense to have one for each Application Server as they make independent connections for outbound data and would in turn issue their own specific Certificate when queried for it.

Sebastian, you have been very helpful to me in understanding this whole setup, thank you so much.

[sebastian_broll]

Hello Michael,<br/>

<br/>

I do have multiple Application Servers, however only one server can accept Inbound SSL (Server) connections, which is the Central Instance. Does this mean I currently do not need Server PSEs on the Application Servers?<br/>

<br/>

At least one SSL Server PSE (either the default or also the application server specific one) is mandatory to activate HTTPS/SSL. Since these PSEs do not cost you any extra effort, just leave them there. As long as you do not receive requests on these application servers, the PSEs can remain self signed. <br/>

<br/>

There are plans to implement Web Dispatcher in the near future, when that happens I assume the Server PSEs for the application servers will become necessary. One note, the Web Dispatcher is not planned to terminate the SSL, they want to do that at the AS or CI, which again is confusing because the Server PSE Certificate will not match the Web Dispatcher's FQDN which I think will result in mismatch errors by external partners.<br/>

<br/>

Actually not. The CN attribute of the PSE's DN needs to match the URL to be used on the client side (= on the browser), which does NOT need to be the same as the local fully qualified hostname. You need to consider the DNS setup to choose the correct DN for your server.<br/>

Additionally, keep in mind that you will use the same PSE on all application servers, if they all server the same URL!<br/>

<br/>

As for the Client PSEs, it makes sense to have one for each Application Server as they make independent connections for outbound data and would in turn issue their own specific Certificate when queried for it.<br/>

<br/>

No, actually not. SSL Client PSEs are not application server specific.<br/>

There is no limitation for the use in different connections, as you can define additional client identities (STRUST, menu "Environment --> Additional Client Identities"), which are then related to unique PSEs. These PSEs, in turn, can be used from all application servers. Keep in mind, that the client PSEs are bound to the destinations in SM59.<br/>

<br/>

Cheers,<br/>

sebastian

[Former Member]

Sebastian,

Here goes:

I now have a signed SSL Server PSE. Inbound transactions now work.

I have successfully changed the CN name of the SSL Server PSE to a different server than local hostname (matches Virtual Hostname) on a sandbox server. So now it will match the URL that is used by partners.

I now understand how the SSL Client PSEs work with the AS servers, thanks to you; they are distributed to all AS servers.

1. What do you mean by, u201CKeep in mind, that the client PSEs are bound to the destinations in SM59.u201D

2. What do you mean by, u201C(STRUST, menu "Environment --> Additional Client Identities")? I only see u201CSTRUST, menu "Environment --> SSL Client Identitiesu201D I only see two, ANONYM (SSL Client) and DFAULT (SSL Client) STANDARD. When I click on SSL Client Identities should I see all the AS server identities listed here?

Thank you,

Michael.