Practical guidelines for SAP components
We wrote earlier about what general approach to take when implementing HTTPS in an SAP environment to enhance SAP security, see that previous blog here. When it comes to the actual implementation, we sometimes come across questions concerning certificates, like what choices to make for generation and implementation. In this blog, we go through some practical points to consider. We assume some basic knowledge of certificates and Certificate Authorities (CA).
First, whenever a component is supposed to deliver a public service with multiple (3rd party) users or customers connecting to it, it is obvious that this requires an HTTPS setup with a certificate that is signed by a public CA. With a public CA we mean a well-established CA that is generally accepted by clients because its root and intermediate certificates are distributed and updated globally. Public websites are a clear example of such services off course but for SAP components the same applies when used publicly. Think of an SAP Web Dispatcher for end user connectivity or perhaps a webservice or API. Note that as a provider, you do not control the clients or applications that use the services, so the only reasonable option to establish a trusted connection is to set this up with such a certificate. Most companies have preferred CA’s that are contracted for these purposes.
A next distinction of services are those that are used within a customer domain and for the greatest part only by clients or components of the organization itself. A common approach here, is that organizations use internal CA’s instead of public CA’s for signing certificates. Since the intended client devices and components are under control of the organization, these can be updated with the internal CA’s root or intermediary certificates so that trust is established.
In our experience, the majority of components (and it subparts) in an SAP environment are not used publicly and for signing certificates for these components, an internal CA is the most likely choice.
An important aspect to think off here, is that for a HTTPS configuration of an SAP system, multiple components are involved which in turn can be distributed on several hosts. Think of different application servers but also the message server component, an internal web dispatcher etc. If separate certificates are used for these components, the number of certificates expands quickly and the setup can become unmanageable quickly as well. Also the process to renew certificates becomes problematic if multiple certificates are involved in a single system setup.
A pragmatic approach is to setup components that belong to the same system with the same certificate with extra subject alternative names (SAN’s) for those components that run on separate hosts. When this certificate is due for renewal, the scope to consider is that of the same system at once. This creates oversight and a more manageable setup.
Another option is not to use signed certificates, but to (partly) use so-called self-signed certificates. These are certificates that are generated by the component itself as part of an initial HTTPS setup but that are not (yet) signed by a CA. Many organizations don’t allow the usage of self-signed certificates but in practice, self-signed certificates are not uncommon to be found, perhaps more than one would expect. Especially in configurations where no direct end-user connectivity is involved (like usage of a browser) but only connectivity between systems or components of the same system. Think of an ABAP based system that connects to a SAP Content Server, but there are many possible examples.
The claim is sometimes heard that self-signed certificates are by definition less secure than signed certificates, but from a technical standpoint that is inaccurate. Self-signed certificates can be generated with the same characteristics and if properly distributed and secured, a secure setup between components can in principal be established. There can be particular situations that using a self-signed certificate is sufficient but in our experience there are certainly objections that deserve consideration (apart from company policies). To name a few:
- Self-signed certificates are often created with long validity which is often seen as an advantage compared to signed certificates that require regular renewal and involvement of other departments. However, this causes the certificates to get easily ‘out of sight’ of those responsible. When these certificates eventually do expire, this results in errors or unavailability of service. In practice, this ‘advantage’ proves to be a ‘disadvantage’.
- Self-signed certificates can be generated with the same characteristics (like key size etcetera) but without signing by a CA, standards are not enforced. It is up to the responsible persons / departments to keep track off this which can be a particular challenge, especially in case of long validity.
- Trust is based on a 1-1 relationship where the calling application has to store the self-signed certificate in its own trust store to work. With multiple connections, the number of certificates to distribute and maintain in several systems becomes quickly unclear and a burden to manage. Also, adding self-signed certificates ‘pollutes’ trust stores because actual CA certificates and self-signed certificates are stored together. It is much more transparent and easy to maintain a small number of CA certificates.
- Self-signed certificates cannot be revoked because there is no CA involved to provide this feature. So if a certificate gets compromised, it is the sole responsibility of application / service owners to deal with this. Note: the ability to check for revoked certificates depends on the application involved. On an SAP ABAP system, this is not an easy out-of-the box feature, see the following blog.
As said before, managing certificates in an SAP environment can be a challenging task. We hope the above guidelines helps in in how to approach this.
For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!
Try out our Protect4S Vulnerability Management solution for 1 month for free or request a demo!
