Recently our certificates got expired and installed new TLS, MLS certificates.
After New certificates(TLS, MLS) installation SOAP to RFC scenario not working which was working earlier perfectly, where as AS2 scenarios are working perfectly for TLS and MLS with the same partner using these new certificates also AS2 working for other partners as well.
Partner is getting below error in soap to rfc scenario
This interface working fine before after our pi certificates tls & mls got expired we have installed new certificates also shared new certificates
to partner, then after we are getting this expection.
Is issuer CA trusted by PI? Is the certificate mapped to a valid user?
yes it is trusted, yes our partner certificate has mapped to the user and it has not changed we remained it same.
Is there a load balancer involved? If so, have you checked the configuration there?
What configuration need to be done here i am not sure, could you please tell
Regards
Pavan
Hi Pavan,
Which certificate is changed? PI SSL server certificate? or Sender Client Certificate?
You can check ICM trace to check details of SSL handshake, and xpi inspector / tshw trace for authentication on java server node.
A load balancer (e.g., WDP) may affect SSL scenario (e.g., SSL termination, etc).
Best regards,
Tom
Hi Tom,
Which certificate is changed? PI SSL server certificate? or Sender Client Certificate?
PI SSL certificate has changed and also mls certificate which has used for sign and decryption has changed
You can check ICM trace to check details of SSL handshake, and xpi inspector / tshw trace for authentication on java server node.
A load balancer (e.g., WDP) may affect SSL scenario (e.g., SSL termination, etc).
There is no load balancer involved, ICM traces are taken but couldn't identified exact issue based on that trace info and our xpi inpector not working while trying to collect traces it is starting, immediately stopping and generating 0 kb xpi trace file (tried undeploy and deploy) and our tshw also having some error below is the screen of the error in tshw.
[Thr 140171408381696] CCL[SSL]: Srv-0000816F: ServerHello: Negotiated cipher suite is TLS_RSA_WITH_AES128_GCM_SHA256 [ssl3_send_server_hello] [Thr 140171408381696] CCL[SSL]: Srv-0000816F: Sending own certificate [ssl3_output_cert_chain] [Thr 140171408381696] CCL[SSL]: Srv-0000816F: Own TLS certificate:
[Thr 140171408381696] CCL[SSL]: Srv-0000816F: Received message of type "Certificate" containing no certificates. [Thr 140171408381696] Renouncing client authentication: verification mode: 1
Please suggest
Hi Pavan,
Perhaps it's related to ssl/pse_provider parameter - default value should be ABAP.
Here Client is SAP ICH and Server is our SAP PI System. The VERIFY_CLIENT parameter was already set to '1', but this was working perfectly alright untill we renewed the certificates and installed the new set of certificates in STRUST.
The Certificates which you are talking about is the PI Server Certificate [CA <0>: CN=DigiCert Global Root CA, OU=
www.digicert.com
, O=DigiCert Inc, C=US] which we installed in STRUST and the client certificates of SAP ICH starts with m0128***.
Also one more point is that AS2 is working fine and no issues with the authentication after installing the new set of certificates.
Synchronous SOAP Scenarios:
Trigger Request from SAP ICH <-> SAP PI <-> Backend SAP System
please help.
Regards
Pavan
According to the ICM trace you attach to the incident, it seems ICM is only trust 1 CA, you can refer to below trace:
Offering 1 trusted CA(s) for client authentication:
CA <0>: CN=DigiCert Global Root CA, OU=
www.digicert.com
, O=DigiCert Inc, C=US
However, in your client certificate, the CA of root certificate (and intermediate certificates) are 2, they are "DigiCert SHA2 Secure Server CA", "DigiCert Global Root". The certificate of theses CAs should be imported to ICM_SSL_<instance_ID> view. If you can make sure the certificate is imported, you should also restart ICM. We are expecting to see ICM provides 2 trusted CAs for client authentication.
Besides, please check the VCLIENT profile parameter of ICM, according to ICM trace,
it seems that you have configured verification mode: 1
CCL[SSL]: Srv-000081A6:
Received message of type "Certificate" containing no certificates.
Renouncing client authentication: verification mode: 1
1: Means the server asks the client to transfer a certificate. If the client does not send a certificate, authentication is carried out by another method, for example, basic authentication (default setting).
In your case, client certificate is not sent to PI, and authentication is carried out by another method, for example, basic authentication (default setting). Hence I think, there might be issue with user password. You can check this point. Regarding why client is not sending the certificate, one possible reason is that ICM is not providing root certificate (and potentially all intermediate certificates) of the CA (Certification Authority) which has issued the X.509 Client Certificate.
Best regards,
Ray
Is issuer CA trusted by PI? Is the certificate mapped to a valid user?
Is there a load balancer involved? If so, have you checked the configuration there?
