Establishing Trust 
To be able to use the security functions provided by SSL and SNC, you must establish trust between the components involved in the communications. Although the basic concepts used here are similar, there are several factors to take into account when establishing these trust relationships, for example, which security product and which technology is used for securing the connections.
Example
For example, establishing the trust relationship between server components when using the SAP Cryptographic Library for SNC is likely to be different than when establishing trust between end-user client components and server components. For these connections, SSL is used to secure the connections.
For more information about the factors to take into account, see the sections below.
Security Technology Used by the Security Product / Public-Key Technology
The first factor to take into account when determining how to set up the trust relationships is the security technology used by the security product. Both of the products provided by SAP (the SAP Cryptographic Library and the SAP Java Cryptographic Toolkit) use public-key technology. In this case, each component is issued a pair of keys that consists of a private and a public key. The private key is to be kept safe on the server and the public key is to be distributed to communication partners in the form of a public-key certificate. Trust is established by verifying the communication partner's public key provided with the public-key certificate.
Note
Other products may use other technologies, for example, Kerberos.
The following sections describe the factors involved when using public-key technology, and in particular, when using the products provided by SAP.
Obtaining the Key Pair
When using public-key technology, each communication partner must possess a public and private key pair.
Both the Key Storage service on the AS Java and the trust manager on the AS ABAP provide functions for generating the key pair. These tools are available when using the cryptographic products provided by SAP.
Establishing Trust by Exchanging Public-Key Certificates
To establish trust between the communication partners when using public-key technology, each communication partner must be able to verify the other's public key. This is accomplished by exchanging public keys using public-key certificates. Once the certificates have been exchanged, the communication partners can verify the identity of the other component at the time of the connection.
Note
There may be cases where a component does not need to verify the identity of the other component that is accessing it. This is the case, for example, when a server component is being accessed by many clients, and the identity of the server is necessary, but not for the client. This is referred to as server-side authentication. In this case, the clients need access to the server's public-key, but not vice versa. If both components need to be verified, both need access to the other's public-key. This is referred to as mutual authentication.
Using a Public-Key Certificate that is Signed by a Certification Authority
If the communication partners are set for a given communication, then the manual effort involved to exchange the public-key certificates is reasonable for establishing trust. However, for cases where there is a large number communication partners, or they are dynamic, then manually exchanging public-key certificates in advance is tedious. A typical scenario for this case is server-side authentication using SSL where many clients access the server using a Web browser.
In such cases, it is typical to have the server's public-key certificate signed by a Certification Authority (CA). The CA verifies the identity of the person or component that is requesting the certificate, in this case, the server, and digitally signs the certificate. When establishing the communication, the communication partner has to trust the CA, and therefore, verifies the public-key certificate belonging to the CA instead of trusting and verifying the certificate for each individual server. The CA's certificate is referred to as the CA root certificate.
Many CAs are well-known and their root certificates are distributed in advance (for example, many are provided with the standard Web browsers). Therefore, establishing trust for such cases is easier by trusting the CA that issued the component's public-key certificate.
Sharing a Key Pair Between Components
There may also be cases where you can use the same key pair for both communication partners. In this case, copy the key pair from the one server component to the other. Trust is automatically established in this case because the key pair is the same for both components.
Recommendation
Only use this option if the communication partners are closely linked to each other and can automatically trust each other, for example, an AS Java and an AS ABAP as part of a dual-stack system. If trust is not automatic, we recommend using separate key pairs for each communication partner.
Note
Although the initial configuration is easier, transparency decreases because all of the components use the same key pair and other identifying attributes (for example, the Distinguished Name). It is therefore more difficult to determine which key pair is actually referred to in error messages or in trace information.
Sample Scenarios for Establishing Trust
To illustrate which method to use for establishing trust for the various cases, see the following topics:
This list is not considered to be a complete list of all options, but it should give you an overview of the methods to use to establish trust for the most common cases.