I have an asp.net web app deployed on IIS7. I call the webapp AOps and When I try accessing the web app over https it just crashes saying "Security sertificate required to access this resource is invalid" (first image).
When I try over http the download works fine.
When I access the default IIS app over both http and https it works fine - except that it complains that the address is mismatched.
I have added a .pfx certificate in the certificate store with the same host name as my host, so the certificate should be fine. Any idea where to start reviewing my configuration?
I am used to apache and tomcat but IIS is a different animal. I looked in the IIS log but it's pretty much a black box. Any help would be greatly appreciated.
The certificate error is generated by your browser not the server. There are 3 things the browser cares about.
The name on the certificate needs to match the url you are using. So in your case, the browser wants a certificate issued to "localhost"
The certificate has to be issued by a trusted certificate authority (not self-signed)
The certificate cannot be expired
To solve 1, use a host entry in /etc/hosts. To solve 2, you need to add the certificate to trusted CA store on your local machine. And 3 is pretty obvious.
Related
I installed an ASP.net application on a windows Azure VM (IIS 7). SSL certificate is installed, configured and the application works correctly. I have removed Http binding and http endpoints.
The issue I am having is that if I use the cloudapp.net link (using https), the application still opens with a mismatched certificate.
What can I do to deny any user from opening my application using https://xx.cloudapp.net/x?
It seems really silly that people are saying this isn't the right place for this question, since some of the solutions could be code related. ie: In your application, check the host and if it's cloudapp.net, do a URL redirect.
There's a few different options here but it sounds like what you're looking for is just the ability to prevent someone from viewing the application using that URL.
What I would do is set up a site in IIS that uses Host Header resolution to look for xx.cloudapp.net. If that URL is recognized, do a redirect using the HTTP redirect settings to the https version of your app. Don't bind the SSL port to this site or you'll run into SSL errors like you showed above.
The other option is to leave it out entirely and simply use the Host Header resolution to filter out requests for your site. I suspect what you've done is assign all incoming requests to the only IP address on the system, which is why the xx.cloudapp.net is showing your app and the cert is failing.
This would cause xx.cloudapp.net to fail to show any site at all but I think that might be what you want to do anyway.
I have deployed a WCF service on IIS and enabled SSL for it. I created a self signed certificate on the server and exported into a pfx file. I also brought the pfx to my machine and installed it under Trusted Root Certification Authorities.
When I hit the service URL, I get following warning which I need to avoid:
You attempted to reach 172.150.170.226, but instead you actually
reached a server identifying itself as something.something.local.
Please suggest. Thank You.
The host name on the certificate has to match the host name in the URL you are using. So you need to be hitting something.something.local. If that doesn't work, then maybe it needs to be set up in your hosts file so that the IP resolution works.
The problem was I was unable to name the self signed certificate according to my preference.I was accessing the service through the ip address of the server , so i needed to set the common name of the certificate as that ip.
I was able to do this using SelfSSL.exe which comes with IIS 6.0 Resource kit.Using this tool from command line I was able to name the certificate as i like.
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.
I hosted an ASP.NET Web API project in my Windows 7(IIS7) developer machine on HTTPS(443) and SSL Required ticked with Require Option true.
For testing I give its host header value : www.certtest.com, and the same I add in host file of local machine.
Also we have a W2k3 machine where we've configured the CA and obtain test certificates from it.
We import same certificate in IIS7.0 for client authentication.
When we try access site, the first time it asks me for certificate and after that certificate get installed with root certificate in my local store but i see 403.7 Forbidden error immediately.
Also, I tried with self signed certificate.
Same problem with that too.
Do we require a valid trial certificate for client authentication by Thwate type CA to accomplish this?
Yes this is a case where we don't have valid certificates, for testing you can set SSL Settings as Accept and see if things work fine for you.
However you will need valid certificates for the same.
I have an ASP.NET website that is contacting a webservice. Everything works fine connecting via http but when I try https:// it can't connect. I don't seem to get any error from the website and the webservice logs show nothing, meaning nothing has connected to it.
I can connect to my https:// webservice from a site like soapclient.com and request information, so the webservice and ports are working.
Is there anything special I should be doing in order to connect to a https:// webservice over a normal http:// one in .NET? All I am doing at the moment is changing the URL it is connecting to to my secure one instead.
I am using
ASP.NET 2, IIS7
Thanks in advance.
EDIT: Just found the actual error message: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel - Which in my eyes tells me I haven't added my self signed certificate to the installed certs on the server ... but I have ...
You need to add your self-signed certificate under Trusted Root Certificate Authorities in the Local Computer store of the server running the ASP.NET website.
Export the certificate from the webservice server as a .cer file, and copy it to the server running the ASP.NET website. Then, on that server:
Double-click the .cer file and Install Certificate
In the wizard, choose the store as the Local Computer folder under Trusted Root Certificate Authorities.
You might have to restart IIS, or the server
There are some good instructions towards the bottom of this page, under "Installing the self-signed certificate on client computers": http://webhelp.esri.com/arcgisserver/9.3/dotNET/index.htm#setting_up_ssl.htm
It looks like your client encounters a certificate validation error, because your server certificate is self-signed.
Try including the following line (C#) in your web site code, before calling the web service. This will tell .NET to ignore all certificate validation errors:
ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) => { return true; };
This should obviously not be used in a production environment :)