SAP Single Sign-On Insider Tips – Volume #5

Welcome to volume #5 of our “SSO Insider Tips” blog series. This blog is written in the documentation style and is about a topic that occurs now and then. It exemplifies the systematically excluded possible solutions for our customer and ends with a conclusion, taking the existing customer environment and requirements into account.

Other articles in this series include:

• SAP Single Sign-On Insider Tips – Volume #4
• SAP Single Sign-On Insider Tips – Volume #3
• SAP Single Sign-On Insider Tips – Volume #2
• SAP Single Sign-On Insider Tips – Volume #1

The Mission

Recently, we had an exciting challenge to master. Our customer had an existing PKI and was already using certificates for Non-SAP applications. The intended implementation of SAP Single Sign-On 3.0 should be based on X.509 certificates and the component SAP Secure Login Serverhad to be operated as a subordinated issuing certification authority (CA) – limited to issue user certificates from type client authentication for the use case SAP SSO. It was not allowed for the SLS to issue other types of certificates. 

With this configuration, the SLS is not operating its own Root CA but instead is part of the certificate chainup to the existing company root CA. While from a security perspective we totally agreed on this decision, it has brought with it some implications that became apparent on a later stage. At this point in time, the PKI and Security staff had given security specifications but did not inform us that client authentication certificates already being used elsewhere.

The problem arose that (after Secure Login Client certificate enrollment succeeded) every Windows and SAP user now had at leasttwo possible matching certificatesof type Client Authentication in the certificate store. Thus, both could be used to mutually authenticate to appropriately configured SAP or non-SAP systems. As a result, a selection dialog is displayed on the client browser in which the SAP user had to manually select and confirm the correct certificate for SAP SSO.

Mission Objective

Avoid selection dialog at all costs. Evaluation of the technical possibilities to reach the mission goal. Decision of the measures to be implemented in the context of a conclusion. 

Situation

The users of the company should log in to SAP with a TLS client certificate. In the future, a ten-hour valid user certificate will be used for this, which is issued by the SAP Secure Login Server (SLS) Sub CAespecially for this application and is automatically distributed to all users. 

Users also have another certificate issued from the Company Enterprise Sub CA. Due to its requirements, this certificate contains all the required properties for a TLS client authentication, in particular, the Extended Key Usage (EKU) “Client Authentication”. The issuer of both the 
SAP SLS Sub CAand the Company Enterprise Sub CAis the Company Group Root CA  (in between there was also a Policy CA).

For the client, this situation results in a usability problem. From the Browsers perspective, both certificates are considered as valid TLS client authentication certificates. Therefore, a selection dialog appears. To make matters worse, the two certificates in the selection dialog are difficult to distinguish. If the user selects the wrong certificate the authentication will not succeed and ends up with a normal “basic authentication” dialog

Technical basics of certificate selection and selection dialog

RFC 5246, Section 7.4.4 describes client-side authentication in TLS. There is also an extension certificate_authoritiesdescribed, with which the server can show certificates of CAs that can be used for the authentication. 

These can be both, root CAs and sub-CAs. On the server side, SAP has a store of trusted certificates. It must have the full certificate chain of the client certificate in order for it to be accepted. This list is sent to the client in the certificate_authorities extension. On the client side, the browser (here Internet Explorer) checks which certificates are suitable for authentication. These are the certificates in the user’s MY store with the following properties:

• The private key is available
• The certificate 
  • is trusted
  • has not expired
  • is not revoked 
  • has been signed by a trusted CA or is in the list of trusted root CAs.
• The certificate has the Extended Key Usage “Client Authentication” or “All Purposes” or no Extended Key Usage
• One of the valid certificate chains contains one of the certificates proposed by the server

Now, none, one or more certificates can meet these requirements. What does the browser do in which case? 

1. With no valid certificate, he does not send any to the server. This can suggest another authentication method.
2. If the certificate is valid, the browser authenticates itself to this certificate without further request if it is configured accordingly.
3. For several valid certificates, a selection dialog always appears for the user – which in fact was the issue we are talking about.

Excluded Solutions

Due to various reasons, we could not implement some possible solutions – these are briefly shown and described below.

Remove CA trust

The Company Group Root CA should be removed from SAP. This was not accepted by SAP on the server side. Even a setting with which SAP does not send the DN of the root CA certificate in the TLS handshake is not supported by SAP.

There are ways to get rid of unwanted Root or Sub CAs or even the trust to the own PKI (deselect the checkbox “Trust issuer certificate”) however, here other use cases required the existing configuration and thus we weren’t able to modify the trust settings. In addition, it should be mentioned, there are significant SAP release-related differences in the area of trust and certificate management. 

Use friendly names for user certificates

Friendly Names, such as “SAP Authentication” and “Network Authentication,”  can be assigned to certificates to make the user’s choice easier. Nevertheless, the users would have to click on numerous selection dialogs, the actual problem itself will not be solved.

Client-side filtering

The browser (here Internet Explorer) could check with a list which certificate is appropriate for which URL. However, Internet Explorer does not support settings to somehow filter the certificates. 

Apparently, Internet Explorer offers no settings in this environment, while some other browsers do. If one can provide a solution for this, we would be very grateful for hints.

Private Key Permissions

It is possible to assign permissions to private keys located in the MY store of the machine (not the user). Thus, certain “processes” can be excluded from using the key. You could also transfer the certificates to the machine store and grant the user rights to the private key. That does not help as the Internet Explorer runs in the context of the user and so the same rights must be assigned for both certificates.

Different certificate properties

The existing certificate from the Company Enterprise Sub CA could be changed so that it is no longer usable for TLS client authentication. However, the certificate requirements for the main application use-case regarding filtering were identical to TLS client authentication. In addition, this is often not feasible since initially, all previously distributed certificates would have to be replaced with the new, under certain circumstances, a fairly large and often unmanageable effort. So this option was out of the game too.

TLS 1.3

The TLS 1.3 standard was released in August 2018. In RFC 8446, Section 4.2.5, it specifies a method for accurately selecting a client certificate. Using OID filters would be a very elegant solution to the problem. Many implementations already support TLS 1.3, but it was unclear whether SAP was one of them. Even so, it is unlikely that every SAP NetWeaver release (ICM) already supports those new extensions. Besides the web server, the browser would also need to support TLS 1.3. 

At the time of writing this blog article and according to SAP Note 2765639, currently NetWeaver AS ABAP does not implement TLS v1.3.

Conclusion

While in other situations, we were able to solve similar issues by removing the trust directly on certain SAP systems (STRUST), we were unable to implement this in the specific case. 

For these reasons, setting up another Root CA for SAP – in parallel to the existing one – seemed to be the best solution, which was finally implemented after consultation with the IT security department and the PKI team of the customer.