Showing results for 
Search instead for 
Did you mean: 

"Could not establish trust relationship for the SSL/TLS secure channel"

Former Member
0 Kudos

During the configuration of DUET_E , when calling the DUET Application from SharePoint, the following error is shown :

"Could not establish trust relationship for the SSL/TLS secure channel with authority 'MYSAPNW702SERVER:8001'"

I have already seen the Post :

This mentions the error, but does not provide any answers on resolution.

The DUET_E troublshooting guide suggests that the SAP Standard SSL Certificate is added to SharePoint Central Admin > Security > Manage Trusts

This has also been done.

We are using the Standard SAP SSL Self signed certificate - not one signed by an external CA.

Can anyone provide any guidance ?

Thanks in advance.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Minesh,

we faced that exact same error message in our Duet Enterprise environment, also with a self-signed certificate without a root authority. In our case it had worked before, but suddenly this problem emerged.

Within the SharePoint ULS Log the following exception was logged: System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure

The cause appeared to be that the SSL imported certificate was no longer trusted on SharePoint side. You can check whether this is also your issue by inspecting the current state of the imported SCL certificate on the SharePoint side (SharePoint Central Admin -> Security -> Manage Trust).

We did a new export of the SCL's certificate, re-import it into SharePoint, followed by an IISReset, and next it worked again.

We did not take the SSL Certificate that was handed-over, but we called the HTTPS URL of the SCL server (taken from the Account.xml model). Then we exported the SSL certificate from the browser and imported this certificate to the SharePoint.

Unclear why the certificate became untrusted in the first place. We had done a reboot of the SAP SCL server just before; it might be that this invalidated the earlier self-signed certificate and issued a new self-signed certificate...

Best regards, William.

Former Member
0 Kudos

Hi William

Thanks very much for this information.

We've already checked the state of the Certificate in SharePoint and it is showing as being trusted.

I've deleted and re-added it.

When calling SAP Abap HTTP service (i.e. Webgui or the DUET_E Web Service), HTTPS works - IE throws a warning, but this is because the certificate is self-signed.

I've even exported the certificate out of IE and added this to SharePoint Trust.

IISRESET has been done on all occasions.

Any further thoughts would be welcomed.

Thanks again.


Former Member
0 Kudos

Hi Min,

reading through your first post the problem might be the CN of the certificate. If you used the Wizard or the default way to create a self signed certicate, it is probably created with the CN server.domain (the fully qualified name of the server).

However, when you created the BDC models the URLs pointing to the WSDL is probably only the servername (at least that is what I would assume after seeing your error message).

Because of that SharePoint calls the SAP Duet server with the severname, but the certificate presented by the SAP system is not the servername, but the fully qualified servername. Because of that -- although SharePoint trusts the certificate -- the URL and certificate do not match and you get the error "Could not establish trust relationship for the SSL/TLS secure channel with authority 'MYSAPNW702SERVER:8001"

If that is the case you have two options:

1) you go to STRUST and create a new SSL certificate that has a CN of only the servername. Then you export this certificate and trust it in SharePoint

2) or -- and this is the way I would recommend -- you try to adjust the URL used in the BDC model. Usually you get only the servername (and not the fully qualified DNS name) when you have not specified the profile parameter icm/host_name_full. Which URL is currently used when you start transaction SAML2 or SOAMANAGER? If you have not yet set icm/host_name_full, then give this a try.



Former Member
0 Kudos

Excellent, thanks very much.

We have been careful to use FQDN through out our installation, however as you have correctly pointed out the SAP SSL Server was created by default using the "Short Server Name".

Recreating the SAP SSL Certificate as *, and re-importing into SharePoint resolved the issue.

Thanks once again.


Answers (0)