I have a website hosted on IIS which can accessed across the Local Area Network by using the IP address of the Server computer. But I can only access the website on client computers using http, when I use https I get security alert on the browsers as shown in the image below,
I even got a self signed certificate on the server computer and in the server computer I can use https without any security alert but I can't do the same on client computers on LAN. Is it possible to achieve that? If so please let me know. Thanks in advance :)
Your certificate is not trusted by other computers, because they don't recognize you as a trusted authority, the solution is easy, even if you ask google it will respond with steps to do this (for chrome in this example):
Go to Chrome Settings.
Click on "advanced settings"
Under HTTPS/SSL click to "Manage Certificates"
Go to "Trusted Root Certificate Authorities"
Click to "Import"
There will be a pop-up window that will ask you if you want to install this certificate. Click "yes".
Better idea maybe, instead of making them trust your self-signed certificate would be to generate a certificate by some verified authority.
I have recently generated a free certificate by the https://letsencrypt.org/ portal (and no, I do not have any interest in promoting it) except it's free and it simply works fine.
Related
I develop a website with Symfony2 and I put it in HTTPS.
I have several questions:
The only way to don't have an error message on my browser when I go to my website is to have an SSL certificate?
How the installation of the SSL certificate on a website works?
Verisign offers SSL certificates from 450€/year ( http://www.symantec.com/fr/fr/page.jsp?id=compare-ssl-certificates ). It's quite expensive. Is there other good solutions to have a cheaper certificate?
If your site is not shop or something commercial, you can get free cert at startssl.com
See awesome tutorail
(Installing certificate in nginx is almost the same with apache)
UPD
Now use letsencrypt :)
Certificates tell the client you can be trusted. Web browsers come loaded with trusted keys from third parties. Your browser checks the key of the cert coming in and if it is in the list it allows SSL connection (if the IP address in the cert etc is correct). This is why it costs as no doubt the cert providers have their own expenses to be added to browsers and to turn a profit etc.
You can of course produce you own certificate but they won't be recognised by your clients machine. The user then has to explicitly accept the cert - some browsers like chrome make this hard as it is a security risk.
Google should help you find the best cert deals from trusted providers.
Your hosting provider should be able to help you set up your cert. If your self hosting that should be its own question as it could have different answers depending on your set up.
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.
We have deployed our website to the live webserver, Windows Server, IIS 7.5. Website asp.net, .NET 4.5
I have configured the website bindings to allow https requests for this website.
Asked the hosting provider to open up the port 443.
I can access the website over internet with port 80, no issues at all. (http://mysite.com)
But I can not access via https, (https://mysite.com).
But I can access the site via SSL from the server itself, that means SSL configurations are fine.(https - localhost)
But I can telnet (telnet mysite.com 443), it responds to GET request via telnet.
I have rechecked the certificate and changed it to a self-signed certificate, issue is still there.
These requests not being tracked in IIS logs as well, seems like the request is not reaching IIS. Hopefully something goes wrong before it reaches the server.
But, when I access the website as http://mysite.com:443, it works.
I m bit confused with this behaviour. Obviously the port 443 is open by the hosting company. But something is wrong with requests over HTTPS, which is supposed to send a request to port 443. Please help.
Because your site is working when you access http://mysite.com:443, I am almost sure that you created wrong binding on IIS. Instead of selecting https from combo box you selected default http.
There is a tutorial on how to do this on youtube: Changing IIS 7.5 Bindings by David Johnson
You've establish that the port is open and the hostname binding is there, otherwise http://mysite.com:443 would not work. Its the SSL part that's not working, hence you can connect directly by port and telnet (port 443 but not SSL) but not a browser via https. It's only a browser connecting to a https url that will expect SSL.. I'm pretty sure I've had the same issue, but cannot recall the exact cause but it was definitely related to an invalid SSL configuration or SSL binding.. The behaviour was like there is no connection, nothing, which is unusual, its the bad config causes the browser to abort the connection. If I remember what, I'll update or comment below.
So you can access the site using https://localhost? Your question is not quite clear on this point... what is the exact URL you are using? If it's https://localhost, that is actually an indication that your certificate is configured incorrectly. You seem to be interpreting this as an indicator that it's working OK and that is not the case. The domain name is tied to the certificate and SSL will work only when accessing the site using that domain name. So if it works for "localhost", something is wrong.
Finally I found the solution. Issue was a setting in the load balancer of the hosting provider. I have asked the question from them and they have figured out the issue. Anyways it was a good learning curve for me. And this knowledge is going to help others.
The firewall was already allowing both HTTP/HTTPS, which is why we could telnet through and run a GET / and still pull down content from the 404 page of the IP address.
It appears there was a certain profile applied to the HTTPS configuration in the load balancer which would only work for HTTP, so they have disabled that.
When they set this up for HTTP and HTTPS they were not able to test HTTPS, because to do so would require an SSL certificate in IIS - which it appears we have already provided.
Thanks everyone for your help on this!
I'm setting up a (ASP.NET) website to be used internally at my company. In IIS, I've turned on Integrated Windows authentication and turned off anonymous access. Once I've done this, the website pops up the "enter your username/password" box whenever you visit the site, but won't log you in even if the username/password are correct. This happens even if you're logged in to your computer with a domain account as opposed to a local account.
However, if I enter the IP of the site in my hosts file, the site works perfectly (logs the user in without the additional challenge).
I guess I have two questions.
1) Why does the hosts entry have this affect?
2) How can I get the site to succeed without a) forcing everyone to edit their hosts file or b) the site challenging them and failing to log them in?
EDIT: I checked, and we do have our DNS server set up to point those URLs to the correct servers. That's why pinging the URL displays the right IP. However, it appears that in addition to having that DNS entry, we also have to have the hosts file entry for the site to work.
You probably are having an issue with Kerberos authentication.
Since you're using a url of Site.DomainName.com, I'm assuming DomainName.com is your AD's name also.
On the server that's running IIS, copy SetSPN.EXE from the resource kit tools and run the following:
setspn -A http/site.domainname.com IISServerName
Where SITE is your URL and IISServerName is the name of the server.
This sure sounds like a dns problem. Does the dns server know about the hostname you are using? Sounds like the dns server does not know the forward lookup (hostname to ip) for the host you are trying to connect to.
We recently set up an intranet site with windows authentication here. The network guys setup a group policy and pushed changed to IE and Firefox.
For IE, it added the site to "Intranet Sites" and for Firefox it modified the configuration file so that our intranet..com would be trusted.
So... we got it to work. Here's what happened.
While looking around at the DNS Manager on test.DOMAINNAME.com, my coworker noticed that a different site on the same server was set up as a "Host (A)" entry, whereas the site we were working on was set up as an "Alias (CNAME)" entry. Several other sites on that computer were also set up as Alias entries, and he mentioned that the one site with the Host entry was "rock-solid", and he'd had sporadic issues with at least one other site that was set up as an Alias.
We talked to the AD/DNS admin, and as a test, he switched our entries from Alias to Host, and once we cleared our local DNS caches, it worked perfectly (without requiring entries in our .hosts file).
So the question still sorta stands. This was a Win2k3 box serving as one of three internal DNS servers, and making this modification fixed our problem. If anyone can add any additional information, we'd be very grateful, but in the meantime, we're debating going back and fixing all our other sites.
In my project I need to connect to an intra-net web service but we need SSL connection between the two machines.
Because this is an intra-net site the certificate of the web service might be a self-signed certificate.
The web service and the web page that loads my Flex application resides on the same web server (tomcat) so when I load the web page of the application with HTTPS I been asked to confirm the certificate, I confirm it but this confirmation does not apply on the Flex application (on Internet Explorer and Firefox).
I tried Google's Chrome and it actually asked me twice for confirmation, one for the web page and one for the connection to the web service so it worked great.
Is there a way to tell Flash player to accept also self-signed certificates of is it entirely concern the browser and Adobe guys can't do nothing about it?
In other words, is there a way to connect to a self-signed certificates HTTPS web services from Adobe Flex???
Thanks.
When I put on my security hat the answer would be I hope not. I don't want browser plugins to bypass my browser security settings. I'd consider that a vulnerability.
There might be a way for standalone Air applications, but in browser Flash should honor browser settings.
In your company, you could create your own root CA, add its certificate to all machines that will access the intranet, and then have the CA issue your web service a certificate. The certificate will no longer be self-signed. The two main issues are: (1) managing the private key of your CA, (2) distributing the CA's root certificate to client PCs.
You need to download the cert and install it on both IE and Firefox.
To install a cert on IE:
http://www.markwilson.co.uk/blog/2008/11/trusting-a-self-signed-certificate-in-windows.htm
To install a cert on FF:
Go to Tools->Options and click on the Encryption tab. Click "View Certificates", then "Import".
In my experience, the cert has to be either verified or installed in the browser in order to get Flash to work properly. The cert also needs to have a valid hostname, but you can just edit your client's hostfile if you need to do this for testing.
Well, the flash player should just use the browser to make the connection and be done with it. We have a similar setup here. We use self-made certs, and communicate with the an AMF channel over HTTPS. My guess is though that our setup is different in that we load the flash application itself over an HTTPS channel, so it's talking from HTTPS to the same HTTPS server. Maybe you could try that? This is the setup for our Tomcat server:
Tomcat Server/Client Self-Signed SSL Certificate