I am trying to use SSL and certificates with a web service (IIS 7, Windows 2008, .NET framework 3.5 SP1). I followed the basic instructions (http://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis-7/) and was able to get the site running soon. However, I can only connect to it from a client if the client has the web server's certificate in its Trusted Root Certification Authorities/Certificates store. If I don't add the certificate on the client site, I get the error "Could not establish trust relationship for the SSL/TLS secure channel with authority" on trying to connect to the service from client.
That's the correct behavior if you're just using self-signed test certificates. In a public/production environment, your server's certificate would be issued by a common CA like GoDaddy or VeriSign, which you have to pay to obtain.
Most (client) machines already have a large list of updated CA in their trusted root such as GoDaddy, and so a server certificate signed by them for your site will validate as a valid certificate on most* machines (without you needing to provide your cert as a trusted root).
*Most, meaning that there are browsers & operating systems which may be missing (or need updates) on common certificate authorities in their trusted root store.
Where did you get this certificate? If it's not a child of one of the certificates in the root authority already I sure hope you didn't pay money for it. If you're generating them yourself this isn't surprising because nobody trusts your CA server.
Related
I have an ASP.Net app that requires SSL certification in order to connect to a Dynamics NAV instance via SOAP.
I've created a self signed SSL certificate using the New-SelfSignedCertificateEx.ps1 script. The exact command used was:
New-SelfSignedCertificateEx -Subject "CN=<computerHostname>" -IsCA $true -Exportable -StoreLocation LocalMachine -NotAfter $([datetime]::now.AddYears(5))
Afterwards I copied the certificate to Trusted Root Certificates and added the thumbprint in the NAV instance settings, yet every time I try to connect my app to said NAV instance I receive an error stating:
System.ServiceModel.Security.SecurityNegotiationException: Could not establish trust relationship for the SSL/TLS secure channel with authority '<computerHostname>:<NavInstanceSOAPPort>'
A self signed certificate is not a trusted certificate, you need to provide one from a trusted authority
Try Let's Encrypt, ZeroSSL, FreeSSL or any party you like, they will offer you free 90-day certificate good enough for your tests
We have a web service (service A) that calls another intranet service (service B) using HttpWebRequest via HTTP. When we have tried to upgrade that intranet service (service B) to HTTPS, we have started to see The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel exception.
Can this be related to not having the certificate in Server Certificates on the server where service A is located?
I have found the following article, but it seems to be more related to the same issue on the desktop, not on the server.
Could not establish trust relationship for SSL/TLS secure channel -- SOAP
#mason's comment to my question helped resolve the problem. Indeed CA's certificate was not amongst trusted root certificates.
It's not in IIS. It would be in Windows certificate store. Start > Manage Computer Certificates. The CA probably needs to be in the Trusted Root Certification Authorities > Certificates folder.
I am facing the following issue.
1 - I have deployed WCF service with SSL enabled on remote IIS machine and trying to use it from my web client.The problem is my browser is not allowing this service to be called.Before using my web client i have to hit the service url from my browser directly and then allow the certificate.
2- Got suggestion from somewhere to export the certificate on the machine where WCF is deployed and include that certificate file in Trusted certificates group on my machine.After I did that I got same problem when tried to access web service from web client.So I hit the service url from browser and got the same page which needs me to trust the certificate with a different message that "You attempted to reach 111.121.196.226(ip address of the WCF machine), but instead you actually reached a server identifying itself as "WMSvc-domain" where "WMSvc-domain" is the value of "Issued To" field in the certificate.
I hope I have made myself clear.Waiting for suggestions.Thank you.
WMSvc-machinename is the IIS Windows Management Service which runs by default on 8172/tcp and is used for remotely managing iis. When installed the default is to create a self-signed certificate. That wouldn't trusted. It could be replaced with a "proper" CA signed cert through the Management Service icon in IIS Manager.
There are many versions of this question on stackoverflow. I have tried a lot of the solutions suggested there - but none of these work for me.
I have a VB ASP.NET application running on IIS on Windows Server 2008. It calls a webservice. The Server running the Web Service has a self signed certificate. I have imported the Cert into the Trust Store of the IIS machine. I can see the certificate in IE->Options->Content->Certificates->Trusted Root Certification Authorities.
When the webservice is called, an exception is thrown
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The same IIS VB ASP.NET Application runs fine on another machine with a similar setup.
These are the different basic things I have checked
The URL used to call the webservice is the same as the CN on the Cert imported into the Trusted Root CA.
Time is synced between the calling machine and the webservice host
The Cert isn't expired.
The IIS machine has Proxy settings in IIS, but Webservice Host machine as added to list of exceptions where Proxy should not be used.
I wrote a small command line test program in VB.NET calling the same webservice which runs fine.
After importing the Cert into the Trusted CA store, I have done a iisreset.
Only thing I haven't tried yet is rebooting the IIS machine - this is production machine & I cannot reboot it for at least a couple of days.
What else can I try?
Internet Explorer certificate settings apply only to the current user. It's highly unlikely that the same user you're logged in as when operating IE is the same as the one being used to host the IIS application. You could add the certificate to the trusted certs for the appropriate service account, but a simpler approach would be to add it to the "Local Computer" trusted certs.
Run Microsoft Management Console (type "mmc" in run dialog) File > Add / Remove Snap-Ins > Certificates, chose "Computer account" for the certificates to manage. This way, any user or service account on the server will see the certificate as trusted.
Alternatively, depending on how you're accessing the web-service, you could add an exception within the application itself. I would recommend code that checks the thumbprint / hash of the certificate though, as opposed to allowing it to connect to any un-trusted certificate.
I am developing a WCF service and Windows forms client and using message security (authenticate with user name, password, and certificate (public and private key) at server, server public key at client). Verified with temporary certificate using makecert.
Now I need to publish my application in GoDaddy.
Can I use the SSL Certificate from GoDaddy for WCF message security (WS-Security) or do we need to buy a different type of certificate?
It is possible, but it means you would have to have the GoDaddy SSL certificate installed on every client. Normally you would not expect the SSL certificate itself to be installed on a client, instead you would have a certificate from somewhere higher in the certificate issuer chain installed and verify the GoDaddy SSL certificate by chaining.
However, if you are able to distribute the GoDaddy cert (minus the private key, obviously) with your client application then you should be able to do it. Certificates generally have Purpose, which is the intended use of them. I imagine your GoDaddy certificate would have an intended use of SSL only, but I don't think that really matters.