Can't get SSL Authentication to work

[Former Member]

Our SAP server is supposed to call an external web service, which requires authentication via an SSL certificate. So in STRUST I have created a new client certificate, which has been imported on the external server. Also we have received the servers' certificate, which has been added to this new entry in STRUST.

In SOAMANAGER I have set this new STRUST entry to be used for authentication at the web service provider.

Now when our SAP machine calls the remote web service, authentication fails.

In the ICM logs the following error messages are given:

[Thr 140543812142848] SecuSSL_SessionStart: SSL_connnect() failed  (536875072/0x20001040)

[Thr 140543812142848]    => "SSL API error"

[Thr 140543812142848] >>            Begin of Secu-SSL Errorstack            >>

[Thr 140543812142848] 0x20001040   SAPCRYPTOLIB   SSL_connect

[Thr 140543812142848] SSL API error

[Thr 140543812142848] received a fatal SSLv3 handshake failure alert message from the peer

[Thr 140543812142848] 0xa0600266   SSL   ssl3_read_bytes

[Thr 140543812142848] received a fatal SSLv3 handshake failure alert message from the peer

[Thr 140543812142848] <<            End of Secu-SSL Errorstack

[Thr 140543812142848]   SSL_get_state()==0x21d0 "SSLv3 read finished A"

[Thr 140543812142848]   No certificate request received from Server

[Thr 140543812142848]   SSL NI-hdl 401: local=10.156.32.11:62224  peer=10.206.58.12:16101

[Thr 140543812142848] <<- ERROR: SapSSLSessionStart(sssl_hdl=0x7fd2d0099410)==SSSLERR_SSL_CONNECT

Any ideas what we might be missing here?

[former_member476865 · Accepted solution]

There are two issues that are not visible from the artificially truncated(!!) error details that you quoted initially.

(1) you originally had configured your client to use "SSL client Anonymous" (SAPSSLA.pse)

(2) you're talking to a defective TLS Server which is sending a malformed TLS Certificate Request handshake message with an empty certificate_authorities element, in violation of the TLS protocol specification, and you had not enabled the workaround to blindly send a client certificate in response to a malformed CertificateRequest handshake message.  See SAP Note 510007 section 7.(ssl/client_ciphersuites=208:HIGH:MEDIUM:+e3DES).

-Martin

PS: The amount and intensity of random guessing around here is disappointing.

[Former Member · Accepted solution]

Hello Martin, thanks for your reply. As response to your 2 points:

ad 0) Why truncated? I have c&p'd the whole error message block from the ICM log file here originally. After it has been requested, I also posted the level 3 trace here.

ad 1) True. But the behaviour did not change after switching to our own PSE / certificate.

ad 2) I will ask our Basis team to change that parameter and test again. But before I will have a word with the service provider team and ask them about what you said regarding the malformed TLS certificate request.

Also, frankly, I don't quite understand your PS. I mean, obviously there is guessing happening here. If I would know what the problem is, then I would not have asked here in the first place. I am not an SSL or certificate expert as apparently you are. But isn't that the reason for why one posts here at SCN?

In any case, thanks for your reply 🙂

[Former Member · Accepted solution]

Hey Martin,

Out of curiosity, how have you determined from the trace excerpt that Matthias initially posted that he was using the SAPSSLA and not SAPSSLC ?

Cheers,

Amerjit

[Former Member · Accepted solution]

Just for the records: Martin was right, now that the server sends the list of accepted certificates back to the SAP client, the SSL handshake and therefore the connection succeeds.

Thanks to all of you for your ideas and feedback 🙂

Have a nice weekend!

[former_member185954 · Accepted solution]

SAP Note 510007 is indeed fantastic, it makes a lot of difference when someone who knows the area well speaks up and helps. Have a great weekend Matthias.

Regards,

Siddhesh

[Former Member · Accepted solution]

Hey Matthias,

Glad it all got resolved in the end.

I don't know whether you missed it but this parameter change from note 510007 was already suggested to you back on May 06.

A great weekend to all who chipped in.

Cheers,

Amerjit

[jimguo]

Hello,

I suggest you check if the own certificate of the selected PSE in STRUST is trusted by the external server.

The problem is that the external server does not accept your client certificate.

Thanks.

Jim

[former_member185954]

Hello Matthias,

As per the scenario you described, you are doing the following:

- Setting up a Service Consumer Proxy to consume an external web service

As per the blog :

Check Step 6,7,8

- When you create a logical port in SOAMANAGER you potentially selected the options to authenticate with external server to use client X.509 certificates

if the above is applicable to you, then your SAP server is acting as a client in the communication workflow and hence your SSL Standard Client PSE will be used and not Server PSE as per help documentation below.

SSL Client PSEs - Network and Transport Layer Security - SAP Library

You will need to ask the external server provider to generate a client x.509 certificate for you and upload it to your SSL Standard Client PSE.

Regards,

Siddhesh

[Former Member]

So first I created a new SSL Client Identity in STRUST, that certificate has been sent to the service provider in advance, so that they can register it on their system. I also added the provider's server certificate to the list of certificates for that new Client Identity.

Then in SOAMANAGER I selected to use a X.509 certificate for authentication with the web service provider. And of course I selected the newly created Client Identity from STRUST.

Is that approach correct (in theory)?

[former_member185954]

Hello Matthias,

That seems to be correct, has the provider sent you a X.509 certificate which you can import into your client pse for authentication?

The provider may have provided a server certificate, which is fine, it helps establishing the provider's identity, but to login into the provider's server, they should provide you with a X.509 certificate, which you will import into your client PSE and enable your SAP server to present it to the provider at the time of handshake/logon.

Regards,

Siddhesh

[former_member185954]

For a typical scenario of SAP server (acting as Client) wants to consume Provider's web service

On SAP Server

Step 1  Start transaction STRUST

Step 2  Select the SSL Client Standard PSE (create an individual one if you need an individual one)

Step 3  Double click on SSL Client Standard PSE

Step 4 Click on Create CSR or Certificate Signing Request and export the CSR to a file on your desktop

Step 5 Send the file (CSR) to the CA or Certification Authority that the Provider trusts.

Step 6 The CA returns back a signed response in a file.

Step 7 Select the SSL Client Standard PSE again, Import the response into the PSE.

Step 8 Also, add the response to certificate list.

Step 9 Save all PSE / Distribute (in case you have app servers)

Step 10 You will now be able to use this in certificate in SOAMANAGER

So essentially, you are create a request to your Provider's CA to return you back with a response that can be sent to your provider for authentication.

If the provider doesn't have a CA it trusts, the provider should sign the request that you created in step 4 and send you back a certificate response, which can be used for calling the provider.

I tested this mechanism some time back, when I setup one sap system to act as client and one to act as provider.  I used SAP's test CA as the trusted CA for both client and provider.

When my provider was a SAP server, there was further configuration related to userid mapping. so in the provider server, I had to map the client certificate CN name to map to a SAP userid in order to ensure that the provider SAP Server knows which userid to use when the caller (client sap) calls a webservice.

Sorry, I do realize this explanation is a bit disorganized, but I hope it gives you few pointers.

Regards,

Siddhesh

[Former Member]

Hi Siddhesh, thanks for your feedback.

Yes the provider has sent me a certificate, but I think it's their server certificate (as you suggested). I will check that. But one more question: How does the X.509 certificate differ from the server certificate? What exactly do I need to ask them for?

Also, when I get such a X.509 authentication certificate from them, is it sufficient to add it to the list of certificates in the Client Identity (in STRUST) used for web service authentication? Or do I need to take another step?

Thanks!

[former_member185954]

Hello Matthias,

I think the way it works is, you have to send a certificate signing request from your client pse, so you pass information about your server to them.

They have to send you a response that is signed and enclosed in a X.509 certificate either by themselves (in case they don't have a CA) or by a Certification Authority that they trust.

On help.sap.com, there was a niece piece of documentation explaining how this works. I'll pass it on if I can find it again.

Regards,

Siddhesh

[former_member185954]

Here is the link:

SSL Scenario 2: Establishing Trust for Mutual Authentication - SAP NetWeaver by Key Capability - SAP...

Replace the browser in the picture with your SAP server and replace the SAP server in the picture with your Provider and you will start seeing what you need

Good luck.

Regards,

Siddhesh

[Former Member]

So I think I did what you suggested, even tried it with a officially signed certificate. However, it doesn't work. What bugs me most is that the error messages on both systems (SAP as consumer and the external service provider) are always the same.

The SAP machine says (in ICM logs):

No certificate request received from Server

And the web service provider says:

peer did not send a certificate

These errors happen regardless of what certificate I use, even if I setup user/password authentication for the consumer via SOAMANGER. So maybe the error is not related to the certificate used, but to something else?

Unfortunately I am out of ideas a the moment 😞

[former_member185954]

Hello Matthias,

I suppose the issue lies in SAP not forwarding your client certificate to the provider.

Configuring HTTPS at Transport Level with X.509 Certificate Authentication - Recommended WS Security...

Can you please confirm if you have configured the logical port security settings as per - Configure a WS Port for Consuming a Web Service

Regards,

Siddhesh

[former_member185954]

Hello Matthias,

Also to resolve this issue, you might want to take a step back and ask your provider if they support authentication via userid/password and make sure that works correctly.

Regards,

Siddhesh

[Former Member]

Well, I did this via SOAMANAGER. In the logical port configuration I selected to use authentication via X.509 certificate and then selected the PSE I have set up via STRUST before.

Maybe the certificate itself is not for X.509 authentication?

Do I need a special kind of certificate to be used for such authentication?

[former_member185954]

Hello Matthias,

Don't think there is, has the error message changed at the service provider end ? Does he now get a certificate from your SAP instance ?

Regards,

Siddhesh

[former_member185954]

Hello Matthias,

To be honest, I am out of ideas too.

I would recommend you ask the moderator to move this thread into SSO space, there are people there who I consider more experienced than I personally am in this area, since we are not getting anywhere with this.

They should be able to help you better, also, I get to learn if there is something that I may have missed.

Sorry.

Regards,

Siddhesh

[Former Member]

Ok I will, thanks for all your feedback.

[Benny]

Your wish is my command....

[Johan_sapbasis]

Hi,

Maybe look at this recently resolved thread as well.

J

[Former Member]

Hello Matthias,

Can you please confirm what version of the CRYPTOLIB you are using ?

KR,

Amerjit

[Former Member]

Would you please tell me what is the easiest way for me to find out the CRYPTOLIB we are using?

Thanks!

[Former Member]

STRUSTSSO2 => Environment => Display SSF Version.

[Johan_sapbasis]

Hi Matthias,

Check note 800240 SAP OSS Note - FAQ: SAP Cryptographic Library error analysis (App. Server).

Also in when SAP is started in the dev_w* trace files you will see section that list secude/snc versions as well if your snc is running.

SNC Messages on AS ABAP - Network and Transport Layer Security - SAP Library

executing command sapgenpse -h

should also list the version.

Note 455033 - SAPCRYPTOLIB versions, bugs and fixes

Regards,

J

[Former Member]

Thanks. Here is a screenshot:

[Former Member]

Hello Matthias,

Thank you for that. I'll try and preempt some of questions you may be asked in this thread.

Q) Does the external site support SSLv3 ?

A) You have confirmed this earlier.

Q) Are you using a proxy server to get to the outside world ?

A)

Q) Are you able to download and read the server certificate with your browser ?

A)

Q) Please post the values of the following parameters.

ssl/client_ciphersuites

ssl/ciphersuites

A)

KR,

Amerjit

[Former Member]

Here are the answers to your questions:

Q) Does the external site support SSLv3 ?

A) You have confirmed this earlier.

Q) Are you using a proxy server to get to the outside world ?

A) Nope, no proxy server. The web service provider server is located in the same local network as the SAP system.

Q) Are you able to download and read the server certificate with your browser ?

A) Unfortunately not, I cannot access the web service directly from my workstation (because of a firewall).

Q) Please post the values of the following parameters.

ssl/client_ciphersuites --> 192:HIGH:MEDIUM:+e3DES

ssl/ciphersuites --> 193:HIGH:MEDIUM:+e3DES

Thanks for your help!

[Former Member]

Hi Matthias,

I see there has been a lot of feedback. Joining in again after that thing called the "day job" got in the way 🙂

Q) Are you the Basis Admin for this system and are permitted to restart if necessary ?

A)

Q) Do you have o/s access on the SAP server ?

A)

Q) Your Web Service Server is what ?

A)

1. I would like you to have a look at OSS  #510007 noting point #7 (optional) and the setting of ssl/client_ciphersuites to 208.

2. If you have o/s access on the SAP system, are you able to telnet to the web service server.

eg: telnet <server ip> <ssl port>

I just want to confirm that nothing is blocking communication between your SAP system and your Web Service system.

3. Please increase the trace level of ICM before you try your next test and then upload the ICM trace file after your test.

4. On your SAP system, please try connecting to the web service server with openssl to get certificate and protocol information. The following command will give you certificate, certificate chain and protocol information.

eg: openssl s_client -showcerts -connect sap.com:443

Please upload the info from the above as well.

mfg,

Amerjit

"Is all that we see or seem but a dream within a dream"

[Former Member]

Hi Amerjit, here are the answers to your questions:

Q) Are you the Basis Admin for this system and are permitted to restart if necessary ?

A) Nope, I am a developing the ABAP code for the web service consumer.

Q) Do you have o/s access on the SAP server ?

A) Nope, but I can ask the server admin to run OS commands for me (see below).

Q) Your Web Service Server is what ?

A) It's an IBM DataPower machine. I will need to ask if you need more information (like version).

1. I would like you to have a look at OSS  #510007 noting point #7 (optional) and the setting of ssl/client_ciphersuites to 208.

--> I have asked the basis team to change that, not done yet though.

2. If you have o/s access on the SAP system, are you able to telnet to the web service server.

eg: telnet <server ip> <ssl port>

--> Yes, that's working, the remote server is reachable:

rorzesek@af7lq001:~> telnet 10.206.58.12 16101

Trying 10.206.58.12...

Connected to 10.206.58.12.

Escape character is '^]'.

3. Please increase the trace level of ICM before you try your next test and then upload the ICM trace file after your test.

The Trace (level 3) can be found here: ICM Trace - Pastebin.com

4. On your SAP system, please try connecting to the web service server with openssl to get certificate and protocol information. The following command will give you certificate, certificate chain and protocol information.

rorzesek@af7lq001:~> openssl s_client -showcerts -connect HOSTNAME:16101

CONNECTED(00000003)          

depth=0 /DC=de/DC=[hidden]/DC=SecPort/OU=Special Applications/OU=Websphere MQ/OU=TIMB/O=TIMB/OU=DEV/CN=HOSTNAME

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 /DC=de/DC=[hidden]/DC=SecPort/OU=Special Applications/OU=Websphere MQ/OU=TIMB/O=TIMB/OU=DEV/CN=HOSTNAME

verify error:num=27:certificate not trusted

verify return:1

depth=0 /DC=de/DC=[hidden]/DC=SecPort/OU=Special Applications/OU=Websphere MQ/OU=TIMB/O=TIMB/OU=DEV/CN=HOSTNAME

verify error:num=21:unable to verify the first certificate

verify return:1

28889:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1098:SSL alert number 40

28889:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

[Former Member]

Hi Matthias,

Perfect .... Your error is coming from the Websphere server and NOT SAP.

You can see from the openssl command I asked to be executed that the Websphere server is the one throwing the SSL handshake error.

It looks to me that either you are using self signed certificates on this server or you don't have the complete certificate chain on this server. Can you get the admin of this server to confirm this.

Kindest Regards,

Amerjit

[former_member185954]

Hello Amerjit,

do you mean to suggest that his service provider has an untrusted certificate installed or doesn't have the certificate chain complete?

Regards,

Siddhesh

[Former Member]

Hi Siddhesh,

As I don't see "self signed certificate" in the trace I would lean towards the fact that on the Websphere side the certificate chain is incomplete or the CA attributes are incomplete.

I would look at the Websphere truststore/keystore.

At least we have proved that the SAP side is not the problem at the moment. 🙂

I still have the battle scars and grey hair when from we had these type of issues for NFE and Mexican Digitally signed invoices 😞

Cheers,

A.

[Former Member]

Matthias Brandstetter wrote:

rorzesek@af7lq001:~> openssl s_client -showcerts -connect HOSTNAME:16101
CONNECTED(00000003)           
depth=0 /DC=de/DC=[hidden]/DC=SecPort/OU=Special Applications/OU=Websphere MQ/OU=TIMB/O=TIMB/OU=DEV/CN=HOSTNAME
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /DC=de/DC=[hidden]/DC=SecPort/OU=Special Applications/OU=Websphere MQ/OU=TIMB/O=TIMB/OU=DEV/CN=HOSTNAME
verify error:num=27:certificate not trusted
verify return:1
depth=0 /DC=de/DC=[hidden]/DC=SecPort/OU=Special Applications/OU=Websphere MQ/OU=TIMB/O=TIMB/OU=DEV/CN=HOSTNAME
verify error:num=21:unable to verify the first certificate
verify return:1
28889:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1098:SSL alert number 40
28889:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

Is this a full output from the command? If not please provide full output. At the end add -msg option.

[Former Member]

That is indeed very interesting and helpful.

Thanks a lot. I will ask the Service Provider Admin to have a look at that issue.

Will get back to you then as soon as I got response.

[Former Member]

So we did some more testing with the openssl command line tool. It turned out that when we provide the root certificate used by the web service provider, and also pass our SAP machine's public and private SSL keys, then the openssl connection handshake does indeed work:

af7lq001:dcsadm 63> openssl s_client -ssl3 -showcerts -connect HOSTNAME:16101 -CAfile SECPORT_ROOTCA.cer -cert dcs.cert -key dcs.priv

CONNECTED(00000003)

depth=1 /DC=de/DC=T-Com/DC=SecPort/CN=SecPort-IT

verify return:1

depth=0 /DC=de/DC=t-com/DC=SecPort/OU=Special Applications/OU=Websphere MQ/OU=TIMB/O=TIMB/OU=DEV/CN=HOSTNAME

verify return:1

---

Certificate chain

0 s:/DC=de/DC=t-com/DC=SecPort/OU=Special Applications/OU=Websphere MQ/OU=TIMB/O=TIMB/OU=DEV/CN=HOSTNAME

   i:/DC=de/DC=T-Com/DC=SecPort/CN=SecPort-IT

-----BEGIN CERTIFICATE-----

... snip ...

-----END CERTIFICATE-----

---

Server certificate

subject=/DC=de/DC=t-com/DC=SecPort/OU=Special Applications/OU=Websphere MQ/OU=TIMB/O=TIMB/OU=DEV/CN=HOSTNAME

issuer=/DC=de/DC=T-Com/DC=SecPort/CN=SecPort-IT

---

No client certificate CA names sent

---

SSL handshake has read 1697 bytes and written 1574 bytes

---

New, TLSv1/SSLv3, Cipher is AES256-SHA

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : SSLv3

    Cipher    : AES256-SHA

    Session-ID: 625FEEC74C9293353C36E259D329F2C59CC3B6D879E1159BBDB2034B37C9F3E1

    Session-ID-ctx:

    Master-Key: 2EC248471595DB912D090D5C6011B5535A6C4D5322B63F0E0608C686664CF583366168124C2CFFFC3381824C34AD25AC

    Key-Arg   : None

    Start Time: 1431509123

    Timeout   : 7200 (sec)

    Verify return code: 0 (ok)

---

Thus it seems to me it is indeed a SAP problem, not an issue with the service provider. Or what do you guys think?

[former_member185954]

Hello Matthias,

I still think you need to ensure your SAP's client PSE has a certificate that is signed by a CA that your provider trusts.

When SAP will present such a certificate which is recognised by your provider, it should work. I was referring to the following steps I mentioned earlier.

Step 3  Double click on SSL Client Standard PSE
Step 4 Click on Create CSR or Certificate Signing Request and export the CSR to a file on your desktop
Step 5 Send the file (CSR) to the CA or Certification Authority that the Provider trusts.
Step 6 The CA returns back a signed response in a file.

let us also wait for Amerjit to provide his inputs or anyone else.

Regards,

Siddhesh

[Former Member]

Have you imported root certificate used by web service provider in SAP? You must have the full chain of certificates.

[former_member185954]

Hello Roman,

Will that be required when SAP makes a call to web service provider ? I thought, the root certificate chain within SAP PSE will be needed to validate incoming certificates.

Regards,

Siddhesh

[Former Member]

Yes, we did that.

[Former Member]

Well, we have sent our certificate to the service provider and they have added it to their list of trusted certificates. Isn't that what it needs?

[Former Member]

Hello Matthias,

Thank you for that. You have gone on to the next step of validation yourself so that's great. So we see the provider server is able to and willing to talk as long as you provide the certificate path explicitly.

That does indeed bring us back to SAP as you have said.

So if I recap as I'm slightly losing track.

1. You sent your client cert to the provider.

2. Your provider imported your client cert into their trusted store.

3. Both you and the provider have the full CA chain for each others certificates.

4. Your basis people evaluated/implemented the ssl/client_ciphersuite change that was suggested to you.

Have I missed/misunderstood something ?

Amerjit

[Johan_sapbasis]

Hi Matthias,

Two silly questions:

1. Did you restart your ICM after importing cert?

2. Run the command to vie if the certificate is on PSE cryptolib as required.

sapgenpse maintain_pk -l -p <file name of the PSE>

Kind Regards,

Johan

[Former Member]

Check if external site supports SSLv3 protocol. Try the same with TLSv1 or higher. Read SAP note 2086818 - Fixing POODLE SSLv3.0 (CVE-2014-3566) Vulnerability.

[Former Member]

We just checked, the server does support SSLv3.