cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot import certificate response in STRUST

Former Member
0 Kudos

we are communicating to a third party via HTTPS from ABAP. They have provided a client digital certificate for us to use when connecting to there server.

I've created a new client PSE in STRUST with the DN the same as the Distinguished name in the certificate.

e.g. CN=WINESOCIETY Development API Interface, OU=I.T., O=The Wine Society, L=Sydney, SP=NSW, C=AU, EMAIL=natalie.livingston@c-p.com.au

I then create the certifcate request for the new client PSE. I then import the digital certificate file provided by the 3rd party as the response. <b>Is this the correct mechanism as the response is not directly generated from the request. It has previously been supplied by the third party before the request was created</b>

On the first attempt . The import response failed as I did not have the ROOT certificate installed. I imported the Root Certificate into the certificate database and tried to import the response file again. This is when I get the error:

Cannot import certificate response .

On debugging the response file is decoded correctly. The error lies in function module

CALL FUNCTION 'SSFC_PUTCERTIFICATERESPONSE'

the function calls C program

call 'SSF_ABAP_SERVICE'

id 'OPCODE' field ssf_opcodes-SSFV2_PUTCERTIFICATERESPONSE

id 'PROFILE' field profile

id 'PROFILEPW' field profilepw

id 'CERTRESPONSE' field certresponse-SYS

id 'CERTRESPONSEL' field certresponse_len.

Sy-SUBRC = 256 is returned which cause the error Cannot import certificate response .

I've seen an OSS note that implies that some of the DN names are different in SAPCRYPTOLAB compared to standard naming conventions e.g EMAIL is actually EmailAddress. Wondering if that may the reason why the response is failing.

Thanks,

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Hi,

The normal process of sso.

!) create the new certificates in visual admin under the key storage from system --> services.

2) a. Logon to Portal

b. Go to System Administration -> SystemConfiguration -> Keystore Administration

c. Choose Content

d. Scroll to the bottom of the screen

e. Choose Download verify.der File

3) 1) In the SAP System, start transaction STRUSTSSO2

2) Create PSE if you are working firsttime on Trust Manager

3) In the PSE status frame on the left, choose the system PSE.

4) In the certificate section, choose Import Certificate.

5) The Import Certificate screen appears.

6) Choose the File tab.

7) In the File path field, enter the path of the portal’s verify.der file.

8) Set the file format to DER coded or Binary and confirm.

9) In the Trust Manager, choose Add to PSE.

10) Choose Add to ACL, to add the Portal Server to the ACL list.

11) In the dialog box that appears, enter the portal’s system ID ( SID) and client (000)

12) Save your entry

Provide the points if my answer solve your issue.

Regards,

Rohit Mehta

Former Member
0 Kudos

Hi,

Why are you talking about the Portal ? There is no Portal involved in the question...

Regards,

Olivier

Former Member
0 Kudos

Hi Graham,

I am facing the same problem.

I guees you have resolved the problem since the discussion has not been updated. If not here are my thoughts :

- You want to use two ways SSL with the server, that's why you cannot use the anonymous PSE client -> the server you want to access needs to verify you identity with your own certificate (that he has provided to you)

I think this is not the right procedure since the certificate the server has given cannot correspond to the csr generated by SAP. You need to :

- create you PSE client with the DN

- generate the CSR from SAP

- send the CSR to a CA (Verisign, ...)

- make sure your CA is recognised by the server (you need to ask the server administrator to be sure about that point)

- import the CA root certificate + import the CA intermediate certificate in the certificate database

- import the CA response to validate you PSE client

Then it should work fine !

Unfortunately I am not able to do that -> the CA response is not accepted by SAP (my CA is Verisign).

Does anyone has successed to import Verisign certificates ?

Former Member
0 Kudos

Hi,

Did you try to import the Verisign response by reading the file from STRUST ?

If yes, I've already had a bug where the file (Base 64) could not be read because of CR LF end of line characters. STRUST seems to like only LF end of line characters ( à la unix).

You can either convert the file from CRLF to LF with sappad or just copy and paste the content of the file.

There is also an other potential problem if Verisign uses an intermdiar CA.

In that case you need to open the certificate file with windows (double click) and export in 3 base 64 files the server certificate, the intermediate CA certificate and the root CA certificate.

Then you have to recreate a new certificate file by appending the 3 files in one.

So I mean a text file containing 3 times "Begin certificate".

You will be able to import this file in STRUST....

Hope this helps.

Olivier

former_member185954
Active Contributor
0 Kudos

Olivier,

You seem to know lots of stuff about STRUST and certificates, i suggest that you collect your post and put them together in the SDN Wiki or something.

It would be really a treat for anyone who has problems on certificates.

Even a blog with title troubleshooting certificate issues would be great.

Regards,

Siddhesh

Former Member
0 Kudos

Siddesh,

Why not a WIKI but the problem is currently time that I don't have, being on a ramp up CRM 2007 project which is real hot !

Regards,

Olivier

former_member185954
Active Contributor
0 Kudos

great.. on the hottest product.. i heard its creating lots of wave..

Former Member
0 Kudos

Thanks for the reply Siddesh.

I think the problem may lie in my basic lack of understanding of certificates.

What you have suggested is what I originally attempted to do.

I created the standard client SSL .

Created Request

Sent Request to SAP CA.

Imported Response from SAP CA.

This all worked fine.

I then imported the certificate from the 3rd party into the certificate list for the standard client SSL and certificate database.

This also worked fine.

When I tried to connect to the 3rd party HTTPS URL I recieved the HTTP Response - Forbidden your client is not allowed to access the requested object.

The 3rd party response to this was to make sure that I had loaded the certificate as a CLIENT certificate and not a TRUSTED certificate. This led me to believe that this approach was incorrect as I was only loading the certificate as A trusted certificate and not a Client certificate. This is why I started the procedure outlined in my original question. Could you clarify the difference between Trusted and client certificates?

The fact that I got the response - Forbidden your client is not allowed to access the requested object.

Could this be related to the fact that the third party needs to Trust the SAP CA root certificate as well. So they would have to upload it on there system .

Many thanks,

Graham

former_member185954
Active Contributor
0 Kudos

Hi Graham,

On second thoughts, you may have to create a Anonymous SSL Client PSE and import the client certificate and the servers' root certificate in that PSE.

http://help.sap.com/saphelp_erp2005vp/helpdata/en/e6/d7343c9688a96de10000000a114084/frameset.htm

Suggest that you clean up the existing config and start again.

Regards,

Siddhesh

Message was edited by:

Siddhesh Ghag

former_member185954
Active Contributor
0 Kudos

Hi,

I think there is something not correct with the process you are following.

From the description you have given, it looks like you just want to import a 3rd party public key certificate into your Web AS , so that the 3rd party can trust your Web AS.

So for this , you should not create a certificate request, instead you just need to import the certificate in the database.

Check this link:

http://help.sap.com/saphelp_47x200/helpdata/en/54/d94e3c719d1742e10000000a11405a/frameset.htm

Follow the procedure and see if things work out okay.

Regards,

Siddhesh