If you find yourself in a situation where Single Sign-On (SSO) between AS JAVA and AS ABAP (e.g. typical portal setup) no longer works, this document may be of help to you. Although this document is about a very specific situation, which hasn’t been covered on SCN until now, it also lists generic instructions which may prove helpful for your scenario.
Troubleshooting SSO Errors
You should always start by reading SAP note 1257108. Unless switched on permanently, start by dynamically switching on Security Audit in SM19, reproduce the problem, switch off Security Audit again in SM19 and troubleshoot the problem in SM20. If that doesn’t reveal anything besides one of the logon error codes listed in SAP note 320991, the next step as instructed by SAP note 1769367 is to enable tracing in SM50. If your AS ABAP system consists of multiple dialog instances, you will have to enable tracing on each dialog instance (SM51). Increase the level of tracing for the Security component from 1 to 3, reproduce the problem, restore the default tracing values and troubleshoot in ST11 by looking at the dev_w<xx> traces.
This document covers the
21 Syntax error in the received logon/assertion ticket
error. By using Security Audit you would find the following:
That helps you to understand what the error is but in order for you to understand why the error occurs and to come up with a corrective action, further steps are required. Once you have created the required dev_w<xx> traces according to the instructions given previously, it is best to download the dev_w<xx> traces to your local computer for further analysis. By <xx> I mean the dialog (DIA) work processes which are numbered from 0 to X where X is the amount of dialog processes – 1. No need to look at any other traces. Once you have downloaded the traces to your local computer, locate the correct trace files by searching for the common name stored in your AS JAVA certificate. Assuming the <SID> of AS JAVA is POR, the following Windows batch command (or UNIX alternative) can be used to locate the correct trace files:
C:\> find “CN=POR” dev_w*
Once you know in which trace files the error occurs, open the trace files and search for:
Got ticket (head)
You can also omit the CN=<SID> search and locate the correct trace files by directly searching for the specified string.
The sections following the search string include the dump of the Logon Ticket as well as the Content and Signature byte streams. Scroll down past all 3 sections to the section of the trace that has the actual reason for SSO failing.
In this particular case of error 21 the trace file contains:
N *** ERROR => SsfVerify failed (see note 1055856). [ssoxxsgn.c 144]
N SsfVerify returned 5 :: SSF_API_SIGNER_ERRORS :: Error during verify – signer error.
N MYSAPSSO2 ticket last error from SSF: ERROR in sec_decrypt_Digest: (12848) verification failed
N ERROR in ??: (8) DSA operation exceeds SAPSECU key size limit of 1024 bit
The error means that AS ABAP refused to accept the DSA certificate of AS JAVA because it contained a key size (2048) that AS ABAP didn’t support. In this case the solution was to upgrade the SAP Cryptographic Library used by AS ABAP. Notice that the version of SAP JVM used by AS JAVA affects the generation of the private key and certificate. In this particular case, updating AS JAVA updated also SAP JVM which in turn caused the incompatibility when the private key and certificate were regenerated.
Furthermore, If you keep scrolling down you will find additional technical details such as:
N *** ERROR => ValidateTicket failed with rc = 5 and ssf_rc = 27. [ssoxxapi.c 235]
Especially rc = 5 and ssf_rc = 27 are important and might be requested by SAP support.