Link to home
Start Free TrialLog in
Avatar of Angel02
Angel02

asked on

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

I have a website that uses SSL certificate. The website sends a request to an external website and receives a response that it has to process. All this was working fine until we renewed the SSL certificate on the server. Now after we send the request to the external website, it does not send a response but throws the error

The underlying connection was closed: Could not establish trust relationship with remote server.at System.Net.HttpWebRequest.CheckFinalStatus() at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult) at System.Net.HttpWebRequest.GetRequestStream()

I made changes in the code by implementing System.Net.ICertificatePolicy but it still does not work. I have attached my code. Please advise.
EE-SSL.txt
Avatar of becraig
becraig
Flag of United States of America image

Can you compare the cert chain of the new cert and the old one.

It is possible that the chain of the certificate might have been changed, also have any changes been made to the name / friendly name of the certificate ?

Compare the expired cert to the new one for :
1. certificate chain
2. Subject
3. Friendly Name
ASKER CERTIFIED SOLUTION
Avatar of Member_2_7083154
Member_2_7083154

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Angel02
Angel02

ASKER

@becraig
Where will I find these details (certificate name, subject, friendly name)? I saw the ones in IIS for the current certificate and they look fine. I don'f have the details of the older/expired certificate.
Does it matter if they are different?

@xaichen
How can I check the website's binding settings on the web server?

I checked the IIS and clicked on View Certificate. I certificate listed was the right one as it had the correct expiry date. But it said
"The integrity of this certificate cannot be guaranteed. The certificate may be corrupted or may have been altered"

Can this be a reason? The website however loads fine and everything is normal except accepting responses from external website.

Will it help if I remove the current certificate and add the same one back? Or will it create more problems?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi Angel,

Do you know what version of IIS or Windows Server the website is running on? If is is Server 2003 / IIS6 it is possible the new certificate is using a hashing method that the older IIS6 version can't understand. See more info in MS article KB938397.

In IIS7 you can check the binding if you select the website in the left hand tree and then select Bindings... in the right hand actions pane. You can then edit the binding to see what certificate is being used for that site.

In IIS6 you can right click the site to get to Properties > Directory Security tab > View  Certificate

Best regards.
Avatar of Angel02

ASKER

Thank you Xaichen. The issue was actually hashing algorithm. We reinstalled the SSL certificate with SHA-1 and it started working. We are able to receive response from the external website now.

Other than the response from the external website everything was working fine with SHA-2 before. Does this mean the external website was not compatible with SHA-2 afterall?

I would like to know this to know if I need to do something on my end so we can use SHA-2. Please advise. Thanks!
Hi Angel,

I'm glad to hear it is working. In respect to the SHA-2 working before. I've read up a bit since my last post and it appears there are 4 or more flavours of SHA-2. It is possible you were using one type that was compatible and then the renewal process selected a different type that could not be supported. I'm not entirely sure where you see what type of SHA-2 is in use, or how to go about changing it, but the different versions are called SHA-224, SHA-256, SHA-384, SHA-512.

In terms of continuing to use SHA-1, it is possibly easier to exploit it, though these days everything seem to have weaknesses. But if you has working SHA-2 solution before it would be worth some effort to try to return to that. But you may find SHA-1is the only workable solution to maintain backwards compatibility in some scenarios. For some real world comparison, I checked out the SSL certificate that Gmail's web interface uses when I make a connection and it is SHA-1.

I hope that helps.