I have moved a client website across to a subdomain of my companies website for development.
The client website has a working SSL certificate. Successfully redirects to https:// - everything works like a charm.
I have straight copied the code to the development folder and gone to load the page and receive the error:
This site can’t provide a secure connection
Site sent an invalid response.
ERR_SSL_PROTOCOL_ERROR
I go to the security tab within Chrome and can see the certificate is valid and trusted. The resources are all served securely. However I am unable to access the site as 'This page is not secure.':
This page is not secure.
Certificate - valid and trusted
The connection to this site is using a valid, trusted server certificate issued by unknown name.
Resources - all served securely
All resources on this page are served securely.
As this is only a development site I am happy for it to not be secure - so long as the live site stays secure and my clients are able to view the development site.
Related
Recently we switched from self-signed certificates to certificates from Let's Encrypt. We used a Windows ACME client (required by Let's Encrypt) to validate our hostname. We had to fill in the "Host Name" field in the https Binding properties page. After the process was succesful and we got the certificate, the web-site is functioning properly from the Internet but it gives a 404 response when we request things locally. If we delete the Host Name property the site functions as expected both locally and from the Internet. We would have the name removed but we set the ACME tool to auto-renew the certificate every three months. Is there a way to have the site both serve loally and leave the Host Name property intact?
I'm working on an enterprise intranet .NET web application that needs several domains to be added to trusted sites to work properly (in Windows Internet Options). Is it possible to do this from web.config (rather than advising users to change their browser configuration)?
Thanks
May I know why are you going to add trusted website for clients?Did you get anything blocked?
Trusted sites are totally client side configuration.Its dangerous if server side can control your trusted site list.
So we can't do this via remote IIS server. Please promote trusted websites from ADDS group policy.What you can do from server side is just use a valid CA certificate for your website to make the connection secure.
https://social.technet.microsoft.com/Forums/lync/en-US/0baa6428-bf48-4e8a-82e1-b961918090d9/how-to-add-trusted-sites-to-group-policy?forum=winserverGP
Our team has a Windows 2008 server which is used primary for a common IIS dev box.
I want to enable SSL on one of the websites on IIS, so that it can only be accessed via HTTPS.
I created a self-signing certificate in IIS and installed it. However when I access the website via the browser (Chrome, Firefox or IE - doesn't matter), it always gives the scary..."this is not secure" screen. I've tried installing the certificate on my own computer, rebooting and I still get that screen.
One thing that I noticed is when I create a self-signed certificate, it adds the domain name to it...for instance, the name of the box is webIIS and our login domain is COMPANYDOMAIN. So it will say that the certificate was created by webIIS.COMPANYDOMAIN.com. This url resolves to nothing, since there is no such thing.
Am I going about it the wrong way?
I've answered a similar question here.
Few afterwords:
Your server should have a dns name. If it is in a domain (Active directory or something) it surely does. Find it, use it in CN of the SSL certificate.
CA that will issue SSL certificate should be trusted by clients accessing the server and by the server itself. Place CA certificate in Trusted Root Store (in LocalMachine store) on the server and all clients that will access it. If you have Active Directory it should be pretty simple to distribute it.
CRL that CA has to issue in defined intervals (it's up to you if the CRL will be issued one a day, month, year or lifetime) has to be accessible by clients and server. Either place it at http url that you gave when issuing SSL certificate or manually place in each certificate store (in Trusted Root Store).
I have this web app that is served via https, and now it needs to use a websocket service that is served from another server. Chrome, Firefox and Internet Explorer complain right away that if the application is secure (https), then it is not allowed to connect to an insecure websocket service (ws:// URI). Strangely, Apple Safari doesn't complain so.
Well, fair enough, I assumed any globally trusted certificate would be fine to be installed at the websocket server side, to enable secure service (wss:// URI). However the company that maintains the socket server claims that they have to install there the very same certificate that secures my web application. I read in webs that the wss will not run with self-signed certificate, but nowhere that it must be the same certificate that the calling web site runs on.
Since we are talking sharing a certificate key file with 3rd party, I wanted to double check this. If my secure site runs at domain first.com, and the websocket server at IP address a.b.c.d, what kind of certificate should be installed on the websocket server to enable the communication? On one hand, that would be a kind of cross-site scripting, but perhaps the browser security model allows it, assuming the user knows what they want?
What I understand from above, the browser connects to your web application and is then redirected to the other server. If that be the case, then browser would complain about being redirected to unsecured site from a secured URL. The way forward actually depends on the domain of the server that the redirect is happening to, for example, if your main site has URL form www.mainsite.com and the target site has URL form abc.secondsite.com or an IP, the second server must have configured an SSL certificate that has been issued to either abc.secondsite.com of the IP i.e. the name of the host requested must match exactly with the SSL ceritficate that is provided by the secondsite.
The secondsite technically does not have to have the same certificate as your mainsite, it just have to be a certificate issued by a trusted source (like Verisign etc.).
On the other hand, if you have a wildcard subdomain certificate i.e. a certificate issues is valid for all the *.mainsite.com domains and the URL form of the secondsite is sub_domain.mainsite.com, then the same certificate can be used on both the servers.
Hope this helps.
thanks
Since we are talking sharing a certificate key file with 3rd party, I
wanted to double check this. If my secure site runs at domain
first.com, and the websocket server at IP address a.b.c.d, what kind
of certificate should be installed on the websocket server to enable
the communication? On one hand, that would be a kind of cross-site
scripting, but perhaps the browser security model allows it, assuming
the user knows what they want?
You cannot provide a certificate for an IP address. In order to use WSS:// you need to connect to a domain name, and have a valid certificate for that domain name. So you need a SSL certificate for the domain name of your WebSocket server.
As far as I know, it does not need to be the same than the one on the site. You can check by entering here: http://vtortola.github.io/ng-terminal-emulator/ and executing the command websocket wss://echo.websocket.org, you will connect to a WebSocket in websocket.org that echoes your inputs.
WebSockets are not constrained by the SOP (Same Origin Policy), you can connect anywhere, and the server is responsible of checking the HTTP request header "Origin" and accept or refuse the connection.
Currently customers have sites on my domain like https://customername.myapp.com. I'd like for them to be able to upload an SSL cert and then access my site via https://myappname.customername.com - how would one go about doing this programmatically in .NET/IIS 7?
bump
So I might have an answer for you but it doesn't necessarily involve .NET/IIS 7.
I'm not quite sure what the end goal is here, but I'll take a stab at it. It sounds like you want customers to go customername.myappname.com and have it show myappname.customername.com's content? You don't simply want to redirect them? Do you have a trusted SSL certificate for myapp.com? If you do, then there's a way you can extend that trust to the myappname.customername.com websites.
Assuming your customers don't want to have to pay for SSL certificates for their websites, you could have them generate self-signed certificates (or create your own CA and sign their certificates) and upload them to your website. Then, using a combination of JavaScript and Flash you could do cross-domain requests from your website to theirs over SSL.
The way this would work:
A customer would go to your website myapp.com. From there (or from customername.myapp.com if you have a wildcard SSL certificate), they could login or just click on their name. Doing so would load a page with a JavaScript implementation of SSL, Flash swf, and the SSL certificate associated with that customer. Then the JavaScript SSL would do cross-domain ajax requests to the customer's site and show their content on myapp.com. This would enable a secure connection to their website via your website.
There's another bit of complexity that you might not be able to support in your use case, however. You need your customer's websites to be able to serve an XML file that contains a Flash cross-domain policy. This policy would specifically grant your site access to theirs.
The JavaScript TLS (SSL) and Flash you would host on your website are part of an opensource project called Forge. This blog post explains how it works in further detail and provides a link to Forge on github:
http://blog.digitalbazaar.com/2010/07/20/javascript-tls-1/
Most of this stuff is done using client-side JavaScript, but you'd use .NET/IIS 7 to provide your customers with the page to upload their SSL certificate.