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.<\/p>\n\n\n\n
Other articles in this series include:<\/p>\n\n\n\n
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 Server<\/strong>had 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. <\/p>\n\n\n\n With this configuration, the SLS is not operating its own Root CA but instead is part of the certificate chain<\/strong>up 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.<\/p>\n\n\n\n The problem arose that (after Secure Login Client certificate enrollment succeeded) every Windows and SAP user now had at leasttwo possible matching certificates<\/strong>of 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.<\/p>\n\n\n\n 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. 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 CA<\/strong>especially for this application and is automatically distributed to all users. <\/p>\n\n\n\n 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 RFC 5246, Section 7.4.4 describes client-side authentication in TLS. There is also an extension certificate_authorities<\/strong>described, with which the server can show certificates of CAs that can be used for the authentication. <\/p>\n\n\n\n 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:<\/p>\n\n\n\n Now, none, one or more certificates can meet these requirements. What does the browser do in which case? <\/p>\n\n\n\n Due to various reasons, we could not implement some possible solutions – these are briefly shown and described below.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019t 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. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n It is possible to assign permissions to private keys located in the MY store of the machine (not the user). Thus, certain \u201cprocesses\u201d 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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. <\/p>\n\n\n\nMission Objective<\/strong><\/h2>\n\n\n\n
<\/strong><\/p>\n\n\n\nSituation<\/strong><\/h2>\n\n\n\n
SAP SLS Sub CA<\/strong>and the Company Enterprise Sub CA<\/strong>is the Company Group Root CA <\/strong>(in between there was also a Policy CA).<\/p>\n\n\n\nFor 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 \u201cbasic authentication\u201d dialog<\/em><\/pre>\n\n\n\n
Technical basics of certificate selection and selection dialog<\/strong><\/h2>\n\n\n\n
Excluded Solutions<\/strong><\/h2>\n\n\n\n
Remove CA trust<\/strong><\/h3>\n\n\n\n
Use friendly names for user certificates<\/strong><\/h3>\n\n\n\n
Client-side filtering<\/strong><\/h3>\n\n\n\n
Private Key Permissions<\/strong><\/strong><\/h3>\n\n\n\n
Different certificate properties<\/strong><\/h3>\n\n\n\n
TLS 1.3<\/strong><\/h3>\n\n\n\n