AS ABAP as a ticket-issuing and a ticket-accepting system issue

[gpeterson]

I am trying to setup SSO so that I can have the same AS ABAP system issue and receive a logon ticket. I have set the profile parameters login/create_sso2_ticket and login/accept_sso2_ticket both equal to 1. The way I test this is to run the CREATE_RFC_REENTRANCE_TICKET function module with SE37 and copy/paste the resulting ticket into a .NET program that uses the SAP .NET connector and it tries to connect to the system using this ticket in the MYSAPSSO2 property. The error I receive is “Cannot check issuer of SSO ticket”.

In transaction STRUSTSSO2 in client 000 I started from scratch by creating a new system PSE which generates its own self signed certificate. I have added the certificate to the list as well as to the ACL. The client I chose when adding to the ACL is the client that I am testing in which is 800. In transaction SSFA there is one application specific item for Logon Ticket using SAPSECULIB. When I run SSO2 without populating anything a destination is automatically created with the host and instance number. Then running SSO2 again and selecting that destination all lights are green.

I ran a trace in SM19 and the log in SM20 shows an RFC logon error of type T (Logon Ticket) and code 22 (Check of logon ticket digital signature failed). The work process trace shows the following:

ACTIVE TRACE LEVEL 2

*  ACTIVE TRACE COMPONENTS      all, N

*

N Tue Nov 17 08:17:26 2015

N  dy_signi_ext: LOGON TICKET logon (client 800)

N  mySAPUnwrapTicket: was called.

N HmskiFindTicketInCache: Trying to find logon ticket in ticket cache.

N HmskiFindTicketInCache: Try to find ticket with cache key: 800:16D6C23C8C948DC549BA7441D2B11083 .

N HmskiFindTicketInCache: Couldn't find ticket in ticket cache.

N  mySAP: Got the following SSF Params:

N         DN =CN=DM1, OU=I00********, OU=SAP Web AS, O=SAP Trust Community, C=DE

N         EncrAlg =DES-CBC

N         Format  =PKCS7

N         Toolkit =SAPSECULIB

N         HashAlg =SHA1

N         Profile =/usr/sap/DM1/DVEBMGS00/sec/SAPSYS.pse

N         PAB     =/usr/sap/DM1/DVEBMGS00/sec/SAPSYS.pse

N  Got the codepage 4103.

N  Got ticket (head) AjQxMDMBABhHAFAARQBUAEUAUgBTAE8ATgAgACAA. Length = 200.

N  *** ERROR => SsfVerify failed (see note 1055856). [ssoxxsgn.c   144]

N {root-id=36344232424235353634423242423535}_{conn-id=00000000000000000000000000000000}_0

N   SsfVerify returned 12 :: SSF_API_DECODE_FAILED :: Could not decode input.

N  MYSAPSSO2 ticket SSF error description: SsfDecode operation failed .

N   SsfVerify returned null for SignerList.

N  *** ERROR => ValidateTicket failed with rc = 20 and ssf_rc = 12. [ssoxxapi.c   235]

N  *** ERROR => Ticket validation failed with rc = 20 and ssf_rc = 12. [ssoxxkrn.c   958]

N  dy_signi_ext: ticket issuer not verified

M SecAudit(check_daily_file): audit file opened /usr/sap/DM1/DVEBMGS00/log/audit_20151117

N Tue Nov 17 08:18:46 2015

Note: I put the **** in the OU value.

I looked at note 1055856 but could not make head nor tail of it. I have also tried exporting the self-signed certificate to the database and the address book. It seems to me that the system either cannot decode the ticket so perhaps I cannot just copy and paste the ticket or it does not like its own certificate?

I am a functional consultant trying to work my way through this one so please feel free to point out the obvious that I must be missing!

Thanks in advance,

Grant

[Former Member]

Hi Grant,

first, this is not related to the SAP NW SSO product but related to the security features of the ABAP system, so you might get better answers when asking this question security forum.

For being able to create assertion tickets, login/create_sso2_ticket needs to be set to 2 (they are usually being used for the scenario you did describe). Please check the documentation on this. Also I would suggest you check the config in client 800, as the config partially is client dependant. As far as I did understand your post, you did run tx SSO2 only in 000 but not in 800.

Also you might want to have a look at this thread on the differences of assertion tickets, logon tickets and re-entrance tickets. Last but not least, there is the note 1257108 - Collective Note: Analyzing issues with Single Sign On (SSO) giving some advice on how to trace SSO issues.

Kind regards,

Patrick

[gpeterson]

Thanks Patrick.

I did try login/create_sso2_ticket = 2 and 3 with the same result. I did run SSO2 in client 800 and all lights are green. I have been through the links you mentioned previously with no joy unfortunately. Can I reassign this to the security forum or do I simply recreate the question there?

Regards,

Grant

[Former Member]

Hi Grant,

the most common reason for this error is, that the public key of the ticket creating system is either expired or does not exist in the PAB of the receiver. Accodring to the trace, you are using the SAPSYS.PSE.

I guess you did already compare the entries in the PAB of SAPSYS.PSE in client 800 with the contents of the PSE you created?

Kind regards,

Patrick

[gpeterson]

Hi Patrick,

In STRUSTSSO2 I have the system PSE selected and I double click on the own certificate to show the certificate details. I then click on Certificate>Address Book and in there I have one entry. The SHA-1 value and Decimal serial numbers match as well as the Issuer (although I notice a space in the issuer field on the certificate details screen after each , separator). The end date is 01.01.2038.

The subject key identifier of certificate field in the address book is all zeros.The MD5 public key check sum in the address book differs from the certificate details MD5 check sum. Is this what you may be referring to?

Kind regards,

Grant

[Former Member]

Hi Grant,

with MD5 check sums you are referring to the MD5 fingerprint for the key in the ticket creating system used to create the tickets and key in the certifcate list of the the ticket accepting system? If they are different, than these are public keys which are similiar but not equal. However in this case the SHA-1 value (which is the checksum of the key at least on my systems) would usually be different as well.

Kind regards,

Patrick

[gpeterson]

Hi Patrick,

It would make sense to me that the values of another system's certificate (e.g. a portal) in the address book of the ticket receiving system and the ticket receiving system's PSE certificate would be different but in the case where I have just exported the system PSE certificate to the same system's address book seems odd that the MD5 value is different. Perhaps this is not an issue though.

But as I have exported the system PSE's own certificate to the same system's address book it should meet the requirement you mentioned earlier about a common issue being the public key of the ticket creating system not existing in the PAB of the receiver? Perhaps the certificate needs to be verified? See below.

Perhaps I misunderstand "I guess you did already compare the entries in the PAB of SAPSYS.PSE in client 800 with the contents of the PSE you created?", should I be checking something else to what I looked at above?

Wondering if I need to get the self signed certificate verified by a CA perhaps? I would have thought that the same issuing and receiving system could trust its own certificate? Just thinking out aloud as it is complaining about failing to check logon ticket digital signature?

Kind regards,

Grant

[Former Member]

Hi Grant,

the certificate in the Own certificate section of the pse used for ticket creation in the ticket creating system needs to be identical to a certificate in the certificate list of the pse used for ticket verification of the ticket receiving system. Otherwise the system will not be able to verify the ticket and you get the error mentioned by you. In addition, the ticket creating system needs to be listed in the ACL, which you usually do by clicking on the 'Add to ACL Button' on this certificate. So if you did regenerate the PSE of the ticket creating system at some point in time, even if the names are identical, SSO will not work, as the keys used for ticket creation and verification are not.

Kind regards,

Patrick

[gpeterson]

Thanks Patrick,

That makes sense to me and is what I think I have done. I have redone from scratch and recorded the exact steps I take below.

1. In client 800. Right click on system PSE folder and click Delete to delete existing PSEs

2. Select only certificate in certificate list and click delete selected certificates

3. Select only item in ACL and click delete selected entries

4. Click save

5. Restart STRUSTSSO2 transaction and receive message maintain PSE for SSO with logon ticket only in client 000

6. Log in to client 000 and run STRUSTSSO2

7. Delete 2 ACL entries

8. Right click system PSE and delete and save

9. Restart STRUSTSSO2 and see that all items have x and confirm no items in own certificate, or certificate list or ACL

10. Right click system PSE and click create

11. Accept defaults, data saved successfully

12. Double click System PSE folder and own certificate subject field populates with (self-signed) below

13. Double click own certificate subject and certificate details display in certificate section

14. Click Add to Certificate List and confirm item now shows in certificate list

15. Click Add to ACL

16. Enter system ID and client 800 and confirm item now appears in the ACL in the logon ticket section and click save

17. Click certificate>address book and delete previous certificate details so that address book is empty

18. Double click own certificate to ensure it is selected and details shown in certificate section

19. Click certificate>export and choose address book tab. Message certificate included in address book received

20. Check address book now has 1 entry. SHA-1 agrees to values on first screen, MD5 does not.

21. Log back into client 800 and run STRUSTSSO2 and get message about maintaining PSE in client 000

22. Notice own certificate is there as well as one item in the certificate list and the entry in the address book but no entry in the ACL

23. Double click own certificate subject and certificate details display in certificate section

24. Click Add to ACL

25. Enter system ID and client 800 and confirm item now appears in the ACL in the logon ticket section and click save

26. Run SSO2 leaving all entries blank and just hit execute

27. Only one traffic light shown and is green

28. Go back and run SSO2 again but this time enter NONE in destination, all traffic lights green

29. click the activate button, data saved

30. Go back and run SSO2 again but this time select created RFC destination (host_instance number) in destination, all traffic lights green

31. click the activate button, data saved

32. Run function module CREATE_RFC_REENTRANCE_TICKET

33. Copy/paste ticket into test .NET program

34. Receive same error, cannot check issuer of SSO ticket error

Does anything stand out as missing or incorrect in the way I am doing it?

Just wanted to say thank you for your input so far!

Kind regards,

Grant

[Former Member]

Hi Grant,

what I can't find in your list is where you did export the certificate from client 000 and then did the import in the system PSE of client 800 and then add this to the ACL. Did I overlook this step?

Also in the ACL, the source system will be client 000 for this ACL entry.

Kind regards,

Patrick

[gpeterson]

You didn't miss anything, I didn't do that assuming (always dangerous :-)) the certificate I was seeing in client 800 in the own certificate section was the same as in 000 as it was there straight after logging in to 800.

35. Log in to client 000, STRUSTSSO2 and double click own certificate

36. Click export certificate and select file on desktop with file format Binary

37. Log in to client 800, STRUSTSSO2 and click import certificate selecting file on desktop

38. Click add to ACL and enter system id and client 000 this time and click Save

39. Run SSO2 choosing destination NONE. One red light under own system data referring to client 000, "This is the certificate of the issuing system for the logon ticket, but not the corresponding system"

40. Click activate (I see this button says enter certificate in ACL and if necessary in certificate list)

41. Create new ticket with FM CREATE_RFC_REENTRANCE_TICKET

42. Same error in test program and in work process log

Should I change the create log on ticket profile parameter to 2 instead of 1 as I had it before to see if that makes a difference?

Kind regards,

Grant

[Former Member]

Yes, please set the profile parameter login/create_sso2_ticket to 2, see my first post to this. With 1 it can not work.

BTW: when importing the certificate, you had the system pse selected. Right?

You then should see one more entry in this list which is identical to the entry in 000.

Regards,

Patrick

[gpeterson]

43. Change profile parameter login/create_sso2_ticket = 2

44. Restart SAP

45. Confirm in RZ11 current value for login/create_sso2_ticket = 2

46. In STRUTSSO2 double click system PSE and then click import certificate and select same certificate off desktop

47. Click save

48. Still only 1 certificate in the certificate list?

49. click add to certificate list gives error importing certificate? Maybe I must delete the certificate I previously added to the list when I was in client 800 and only add this imported certificate from client 000?

50. Create new ticket with FM CREATE_RFC_REENTRANCE_TICKET

51.  Same error, cannot check issuer of SSO ticket

Kind regards,

Grant

[Former Member]

Hi Grant,

in this case, please open a message with support. To me it sounds, as what you did should work.

Kind regards,

Patrick

[gpeterson]

Hi Patrick,

Will do and thanks for all your input. It is at least comforting for a functional consultant muddling through this to know that I am at least on the right track.

Kind regards,

Grant

[gpeterson]

Hi Patrick,

I finally found the issue. It was to do with the way that I was copy/pasting the Ticket itself out of the SE37 function module into the test program. The full ticket is not displayed in the FM. Surprisingly it did not complain about the ticket validity. I was sure it was valid because if I changed a single character it did complain about the ticket itself rather than the ticket issuer certificate. Thanks again for your help.

Kind regards,

Grant