Establishing Trust
To be able to use the security functions provided by SSL and SNC, 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.
Establishing the trust relationship between server components when using the SAP Cryptographic Library for SNC is likely to be different from when establishing trust between end-user client components and server components. For these connections, SSL is used to secure the connections.
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.
Other products may use other technologies, for example, Kerberos.
When using public-key technology, each communication partner must possess a public and private key pair.
SAP NetWeaver AS provides functions for generating the key pair. These tools are available when using the cryptographic products provided by SAP.
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.
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 public-key of the server, but the server does not need access to the public key of the clients. If both components need to be verified, both need access to the public key of the other. This is referred to as mutual authentication.
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 are many 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 public-key certificate of the server 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 certificate of the CA 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 public-key certificate of the component.
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.
Only use this option if the communication partners are closely linked to each other and can automatically trust each other. If trust is not automatic, we recommend using separate key pairs for each communication partner.
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.
To illustrate which method to use for establishing trust, we provide a number of example cases. 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.