Could not establish trust relationship with remote server

[AL]

Hi

I've got two web services both running on the same web server. Both web
services are accesses via https and the same root level domain.

I wrote the client application which post information to one of the web
services and depending on which method was invoked calls the second web
service for additional functionality.

I received the following error when I first wrote the client application:

The underlying connection was closed: Could not establish trust relationship
with remote server

To correct this I implemented the ICertificatePolicy interface and forced
the method to always return true. I then set the ServicePointManager's
CertificatePolicy property to an instance of the class which implements the
interface.

This resolved the problem from client perspective.

However, when the web service calls into the other web service, I get the
error as well. My resolution was to do the same from which in the primary web
service.

When I call the second web service (from the primary web service), I create
an instance of the same class and set the ServicePointManager's property.
This however does not solve the problem the same was that it does when the
client application encounters this error.

These web service are hosted within an ASP environment. I'm no expert here,
so it there some way the environment could be setup that some security
boundry is preventing the two web services from communicating correctly?

Many thanks

Al

 

[sonic]

ah... i spent weeks with this annoying message in the past!
i am sure you read all the standard causes of this issue already.
2 additional things to check for:
1.
One odd and interesting cause of this for me that took forever to
figure out, was that the user running the website had insufficient
rights to access the registry, which apparently is needed to retrieve
the trusted certificate, or something having to do with above process.
to troubleshoot you could make the user running the website application
that is throwing this exception ( aspnet or nt authority etc) admin,
and if that fixes it, remove the admin right, than go to
run>regedt32>edit>permissions, and add read rights for your iis user
there.
2.
another (non standard) problem that caused this for me in the past, was
that the server running behind a firewall, and the IIS user did not
attempt to go through the proxy server. the proxy settings can be
applied in registry, but to quickly test if this is the case perform
the following test:
- create a console app that consumes the remote https service
- open a website directly to that https service to ensure that you
can access it
- run the console app and see if it is successful.
- what is happening here, is that you are running that app as you, and
it is using the same proxy server you have setup in MSIE to make your
browser hit the proxy.
if you discovered that your app is working, hopefuly you have a skilled
systems group [as we did] that will apply apropriate proxy settings to
your internet user. this can be done in registry, or you can login as
that user ( you may need to change local logon policy so he's allowed
to logon ) and than change proxy settings in msie. this get's written
to registry current_user node and will be available for the furture for
that user.

hope that helps.
- Rafal

 

[AL]

Hi

Thanks for the feedback

In regard to point 1. The web service which make the call is impersonating
and the only user allowed is a "service user". I assume I will need to grant
this user rights in the registry. Can you provide me with detail on which
registry keys I need to give rights to?

Many thanks

Al

ah... i spent weeks with this annoying message in the past!
i am sure you read all the standard causes of this issue already.
2 additional things to check for:
1.
One odd and interesting cause of this for me that took forever to
figure out, was that the user running the website had insufficient
rights to access the registry, which apparently is needed to retrieve
the trusted certificate, or something having to do with above process.
to troubleshoot you could make the user running the website application
that is throwing this exception ( aspnet or nt authority etc) admin,
and if that fixes it, remove the admin right, than go to
run>regedt32>edit>permissions, and add read rights for your iis user
there.
2.
another (non standard) problem that caused this for me in the past, was
that the server running behind a firewall, and the IIS user did not
attempt to go through the proxy server. the proxy settings can be
applied in registry, but to quickly test if this is the case perform
the following test:
- create a console app that consumes the remote https service
- open a website directly to that https service to ensure that you
can access it
- run the console app and see if it is successful.
- what is happening here, is that you are running that app as you, and
it is using the same proxy server you have setup in MSIE to make your
browser hit the proxy.
if you discovered that your app is working, hopefuly you have a skilled
systems group [as we did] that will apply apropriate proxy settings to
your internet user. this can be done in registry, or you can login as
that user ( you may need to change local logon policy so he's allowed
to logon ) and than change proxy settings in msie. this get's written
to registry current_user node and will be available for the furture for
that user.

hope that helps.
- Rafal

Hi

I've got two web services both running on the same web server. Both web
services are accesses via https and the same root level domain.

I wrote the client application which post information to one of the web
services and depending on which method was invoked calls the second web
service for additional functionality.

I received the following error when I first wrote the client application:

The underlying connection was closed: Could not establish trust relationship
with remote server

To correct this I implemented the ICertificatePolicy interface and forced
the method to always return true. I then set the ServicePointManager's
CertificatePolicy property to an instance of the class which implements the
interface.

This resolved the problem from client perspective.

However, when the web service calls into the other web service, I get the
error as well. My resolution was to do the same from which in the primary web
service.

When I call the second web service (from the primary web service), I create
an instance of the same class and set the ServicePointManager's property.
This however does not solve the problem the same was that it does when the
client application encounters this error.

These web service are hosted within an ASP environment. I'm no expert here,
so it there some way the environment could be setup that some security
boundry is preventing the two web services from communicating correctly?

Many thanks

Al

 

[sonic]

hi,
to save your self some time, and if you are sure which user is running
the web service, make that user an administrator and see if that fixes
the problem.
if it does, than you can cnofigure his rights regarding to specific
registry nodes. i am not sure which node it was exactly right now, but
im pretty sure it was read access .
you can assign these rights by running regedt32

Hi

Thanks for the feedback

In regard to point 1. The web service which make the call is impersonating
and the only user allowed is a "service user". I assume I will need to grant
this user rights in the registry. Can you provide me with detail on which
registry keys I need to give rights to?

Many thanks

Al

ah... i spent weeks with this annoying message in the past!
i am sure you read all the standard causes of this issue already.
2 additional things to check for:
1.
One odd and interesting cause of this for me that took forever to
figure out, was that the user running the website had insufficient
rights to access the registry, which apparently is needed to retrieve
the trusted certificate, or something having to do with above process.
to troubleshoot you could make the user running the website application
that is throwing this exception ( aspnet or nt authority etc) admin,
and if that fixes it, remove the admin right, than go to
run>regedt32>edit>permissions, and add read rights for your iis user
there.
2.
another (non standard) problem that caused this for me in the past, was
that the server running behind a firewall, and the IIS user did not
attempt to go through the proxy server. the proxy settings can be
applied in registry, but to quickly test if this is the case perform
the following test:
- create a console app that consumes the remote https service
- open a website directly to that https service to ensure that you
can access it
- run the console app and see if it is successful.
- what is happening here, is that you are running that app as you, and
it is using the same proxy server you have setup in MSIE to make your
browser hit the proxy.
if you discovered that your app is working, hopefuly you have a skilled
systems group [as we did] that will apply apropriate proxy settings to
your internet user. this can be done in registry, or you can login as
that user ( you may need to change local logon policy so he's allowed
to logon ) and than change proxy settings in msie. this get's written
to registry current_user node and will be available for the furture for
that user.

hope that helps.
- Rafal

Hi

I've got two web services both running on the same web server. Both web
services are accesses via https and the same root level domain.

I wrote the client application which post information to one of the web
services and depending on which method was invoked calls the second web
service for additional functionality.

I received the following error when I first wrote the client application:

The underlying connection was closed: Could not establish trust relationship
with remote server

To correct this I implemented the ICertificatePolicy interface and forced
the method to always return true. I then set the ServicePointManager's
CertificatePolicy property to an instance of the class which implements the
interface.

This resolved the problem from client perspective.

However, when the web service calls into the other web service, I get the
error as well. My resolution was to do the same from which in the primary web
service.

When I call the second web service (from the primary web service), I create
an instance of the same class and set the ServicePointManager's property.
This however does not solve the problem the same was that it does when the
client application encounters this error.

These web service are hosted within an ASP environment. I'm no expert here,
so it there some way the environment could be setup that some security
boundry is preventing the two web services from communicating correctly?

Many thanks

Al

 

[AL]

Hi

The administrators on the ASP (application service provider) managed to fix
the problem.

It related to the DNS entries for the secure site being registered
externally only. Once the internal entries were made the problem was resolved.

Thanks for the pointers

Al

hi,
to save your self some time, and if you are sure which user is running
the web service, make that user an administrator and see if that fixes
the problem.
if it does, than you can cnofigure his rights regarding to specific
registry nodes. i am not sure which node it was exactly right now, but
im pretty sure it was read access .
you can assign these rights by running regedt32

Hi

Thanks for the feedback

In regard to point 1. The web service which make the call is impersonating
and the only user allowed is a "service user". I assume I will need to grant
this user rights in the registry. Can you provide me with detail on which
registry keys I need to give rights to?

Many thanks

Al

ah... i spent weeks with this annoying message in the past!
i am sure you read all the standard causes of this issue already.
2 additional things to check for:
1.
One odd and interesting cause of this for me that took forever to
figure out, was that the user running the website had insufficient
rights to access the registry, which apparently is needed to retrieve
the trusted certificate, or something having to do with above process.
to troubleshoot you could make the user running the website application
that is throwing this exception ( aspnet or nt authority etc) admin,
and if that fixes it, remove the admin right, than go to
run>regedt32>edit>permissions, and add read rights for your iis user
there.
2.
another (non standard) problem that caused this for me in the past, was
that the server running behind a firewall, and the IIS user did not
attempt to go through the proxy server. the proxy settings can be
applied in registry, but to quickly test if this is the case perform
the following test:
- create a console app that consumes the remote https service
- open a website directly to that https service to ensure that you
can access it
- run the console app and see if it is successful.
- what is happening here, is that you are running that app as you, and
it is using the same proxy server you have setup in MSIE to make your
browser hit the proxy.
if you discovered that your app is working, hopefuly you have a skilled
systems group [as we did] that will apply apropriate proxy settings to
your internet user. this can be done in registry, or you can login as
that user ( you may need to change local logon policy so he's allowed
to logon ) and than change proxy settings in msie. this get's written
to registry current_user node and will be available for the furture for
that user.

hope that helps.
- Rafal


AL wrote:
Hi

I've got two web services both running on the same web server. Both web
services are accesses via https and the same root level domain.

I wrote the client application which post information to one of the web
services and depending on which method was invoked calls the second web
service for additional functionality.

I received the following error when I first wrote the client application:

The underlying connection was closed: Could not establish trust relationship
with remote server

To correct this I implemented the ICertificatePolicy interface and forced
the method to always return true. I then set the ServicePointManager's
CertificatePolicy property to an instance of the class which implements the
interface.

This resolved the problem from client perspective.

However, when the web service calls into the other web service, I get the
error as well. My resolution was to do the same from which in the primary web
service.

When I call the second web service (from the primary web service), I create
an instance of the same class and set the ServicePointManager's property.
This however does not solve the problem the same was that it does when the
client application encounters this error.

These web service are hosted within an ASP environment. I'm no expert here,
so it there some way the environment could be setup that some security
boundry is preventing the two web services from communicating correctly?

Many thanks

Al

 

[sonic]

The administrators on the ASP (application service provider) managed to fix

the problem.

It related to the DNS entries for the secure site being registered
externally only. Once the internal entries were made the problem was resolved.

argh.. i assumed you tried going directly to the service url in a
browser and that worked. that is always good to check first.