Use of CA signed certificates with SAP Logon Tickets
[CA] [certificates] [mill certificates] [sap logon] [sap logon 640] [self] [signed]
Symptom
Discussion about the use of CA signed certificates (versus self signed certificates) with SAP Logon Tickets
Other terms
CA signed certificates, self signed certificates
Reason and Prerequisites
You want to configure your system for SSO using SAP Logon Tickets and did not yet consider whether to use CA signed certificates or self signed certificates.
Solution
The use of SAP Logon Tickets is based on digital signatures, which need public keys for the verification step.
There are two possible configurations that enable the verification of digital signatures, both of which relate on establishing “trust” between signer and verifier.
1. Trust can be achieved by making available the public key of the actual signer of the digital signature. This is public key will usually be made available in form of a self signed certificate, exported from the signer’s own key pair or PSE. The signer’s certificate does not need to be signed by a CA.2. Alternatively, trust can be achieved by signing the signer’s certificate by some CA. Of course, in this case the verifier needs to trust the CA, but it is not required to exchange the signer certificate itself.
The difference between these methods is rather obvious at this point. While for the CA based signatures, you need to apply for CA signed certificates regularly (usually, CA signed certificates are valid throughout one year) for each key pair involved in your SSO landscape, the self signed certificates are valid for a much longer time. Currently, the default validity of self signed certificates in ABAP based systems is until January 1st 2038, and should be set to the same date in Java based systems.
An example may help: let’s assume, you have one logon ticket issuing system, and n logon ticket receiving systems, then the use of self signed certificates will require to export one certificate, and import this certificate n times. This procedure needs repetition whenever you decide it to be necessary and created new key pairs.
In the same scenario, using CA signed certificates requires certificate requests to be issued for n+1 systems, sent to the CA of your choice, and upon receiving the certificate responses, importing n+1 certificatesinto their respective key pairs. This procedure repeats as soon as the CA signed certificates expire, that is usually once per year. Additionally, it must be stated that CA signed certificates may come at additional fee (depending on the chosen CA).
The direct comparison reveals at least double as much effort to be taken for the solution with CA signed certificates, at no immediate security advantage. Additionally, you need to keep in mind, that the logon ticket receiving system’s ACL(s) need to be maintained anyway. This step can easily be integrated with the distribution (import) of the signer’s certificate with the use of self signed certificates. Another difference between these two kinds of setup needs to be noted: when using CA signed certificates, you need to configure the logon ticket signer to send its certificate with the logon ticket, which further increases the network load (login/create_sso2_ticket = 1).
For these reasons, SAP recommends to use self signed certificates for SAP Logon Tickets. Exceptions may be required for strictly controlled security environments or for general security guidelines requiring CA signed certificates as a default.