How Certificate Management contributes to SAP security

Scope of the article: In this article, we offer practical guidelines for managing certificates in SAP environments and explore HTTPS implementation. Additionally, we discuss the selection of Certificate Authorities (CA) and share best practices for effectively securing SAP systems. 

Practical guidelines for SAP components   

When it comes to the actual implementation, we sometimes come across questions concerning certificates, especially around what choices to make for generation, renewal, and deployment within complex SAP landscapes. In this blog, we go through some practical points to consider. We assume some basic knowledge of certificates and Certificate Authorities (CA).   

Public-facing Services 

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. In plain terms, this means that every user’s browser or application can automatically “trust” your system because the CA is already recognized globally.  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 of course, but for SAP components, the same applies when used publicly. Think of an SAP Web Dispatcher for end-user connectivity or perhaps a web service 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 organizations already maintain a preferred list of contracted CA partners to simplify procurement and ensure consistent policy enforcement.

Internal-only services 

The next distinction of services focuses on those that are used within the customer’s own domain, primarily by the organization’s internal clients and system components.

A common approach here is that organizations use internal CA’s instead of public CA’s for signing certificates. An internal CA functions as the company’s own digital “notary,” issuing trust credentials only for systems it controls.  Since the intended client devices and components are under the 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 their subparts) in an SAP environment are not used publicly.  For these, using an internal CA is not only cost-efficient but also helps maintain compliance and visibility across system landscapes.

Managing multi-component systems 

An important aspect to think of 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. From a business perspective, this means each of these sub-systems may present its own “doorway” into your SAP landscape — each requiring a valid key (certificate) to prove its identity. 

 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 of renewing certificates becomes problematic if multiple certificates are involved in a single system setup.   

 A pragmatic approach is to set up components that belong to the same system with the same certificate, with extra subject alternative names (SANs) for those components that run on separate hosts. SANs act like adding multiple addresses to one passport—it’s still one document, but it works in several locations.  When this certificate is due for renewal, the scope to consider is that of the same system at once. This reduces operational complexity and improves visibility across the full renewal cycle.

Making the case for Self-Signed Certificates 

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.  In simple terms, the system vouches for its own identity without any independent verification. 

 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 an 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 principle, be established.  

 There can be situations where 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: 

• Visibility and renewal risk:  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. What first seems convenient can later translate into downtime risk.  Business impact: expired certificates can suddenly block critical integrations or user logins, triggering unplanned outages. 
• Lack of enforced standards:  Self-signed certificates can be generated with the same characteristics (like key size. etc.) but without signing by a CA, standards are not enforced. It is up to the responsible persons/departments to keep track of this, which can be a particular challenge,  — especially in case of long validity.  Without enforced renewal and policy control, technical debt builds up quietly across systems. 
• No revocation capability:  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 that on an SAP ABAP system, revocation checking is not an out-of-the-box feature and often requires manual handling or custom logic. From a governance view, this weakens incident response: there’s no central authority to invalidate a breached certificate immediately.
• Trust distribution overhead:  Trust is based on a one-to-one relationship where the calling application has to store the self-signed certificate in its 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 easier to maintain a small number of CA certificates.  
• No revocation capability:  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 that on an SAP ABAP system, revocation checking is not an out-of-the-box feature and often requires manual handling or custom logic. From a governance view, this weakens incident response: there’s no central authority to invalidate a breached certificate immediately. See the following blog. 
• Pulling it together 

  As said before, managing certificates in an SAP environment can be a challenging task. A systematic approach — based on clear ownership, defined CA policy, and predictable renewal windows — keeps this task manageable and transparent across teams. For business stakeholders, it’s worth viewing certificate management, not merely as a technical control, but as a reliability measure: certificates underpin the trust fabric of every digital transaction your SAP system processes.

   

  Enhanced the security of your SAP systems by implementing SecurityBridge! For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn.