I'd like to control certificate popup windows manually. For example, if an user wanna login with client-side-certificate, I prompts a certificate selection window; If he wanna login with username/password. System let him in without checking his certificate.
There are no standard APIs (or non-standard that I'm aware of) for controlling this with JavaScript or something similar.
The only solution I can think of is to have two webservers.
One for showing a web page that links to either the login form or the client certificate, and this server also implements the login form.
One that requires the user to specify a client certificate.
You could solve this using the same wildcard certificate for both servers and having them on different sub-domains so that you can actually back this setup by 2 different servers (IP addresses).
You can use the same actual physical server, and do "virtual host" dispatching based on the IP, and you can use the same wildcard SSL certificate for both.
The reason you need different servers is that the prompt for an SSL client certificate is triggered at the SSL handshake level, so you can't use name based virtual hosts, you need 2 actual servers to do it.
Related
I built out a few applications - published intranet environment - and all of them are prompting for a username and password in order to access the application (connection to this site is not private).
I am not sure if this is an IIS Setting that needs to be adjusted, I have tried adding everything on my end with the web config settings. Even explicitly turning authentication off and allowing anonymous users, does not do anything.
So my main question is could this security prompt feature be turned off through IIS since the application web.config is yielding no results?
I have the default settings that visual studio generates along with my database connection string.
There's two different things here. First, the prompt is because Anonymous Authentication is not enabled. If you don't want any sort of authentication or authorization, you can simply enable that. However, more likely, since this is an intranet, you do actually want people to be authenticated; you just don't want them to have to "login". For that, you should enable Windows Authentication.
The second piece, "Your connection to this site is not private", is either because you're running on HTTP, rather than HTTPS, or you are using HTTPS, but don't have a valid SSL cert. The latter is a very common issue in intranet scenarios, since there's usually not a public domain you can bind a cert to. In that scenario, you need to generate a self-signed cert and install it on all machines that need to access the site. Alternatively, you can set up your own internal CA, such that you can issue and validate your own internal certificates.
In either case, the message is there to let the user know that communication with this site will not be encrypted, so sensitive things, like say a username and password, will be transmitted in plain-text and can therefore be intercepted by monitoring the network traffic. That may or may not be a concern for your intranet environment, but the message is not internet/intranet-specific.
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.
I have a bunch of node.js apps serving information to an apache site via websockets (ws://). The site itself doesn't have a domain name and is accessed through its IP address (that's non-negotiable, unfortunately...)
The problem is the following :
Without a secure connection, browsers will block the ws://
traffic, so I have to use SSL and secure websockets wss://
Without a domain name, I cannot secure the connection except by
generating a self-signed certificate.
Self generated certificates are not trusted by browsers and
display an error 'certificate not trusted...'. Last chrome update
made it even more annoying to get through the message.
In addition to that, the IP changes regularly and is sent to the users (2-3 people) when it happens. So a certificate issued for a specific IP wouldn't be ideal (if it's free I can deal with the hassle of refreshing the cert).
Does anyone have a solution ?
If you only have a user or two, you could create your own CA, and have each person install it on their browser. You would still need to update the cert every time the IP changes though. google.ca/search?q=create+your+own+ca
One great advantage of using Azure Websites is that I can get secure HTTP (HTTPS) without doing nothing: I simply type https://xyz.azurewebsites.net and it works. I don't have to worry about certificates because I use the subdomain that Azure gives me (in the example it would be xyz)
So, what I usually do is that people come by through some registered domain I have, eg. http://www.my-application-homepage.com, and there, if they want to use my application, I redirect them to the subdomain at azurewebsites.net, using HTTPS.
Now, having said that:
I'm in need of upgrading to Azure Cloud Services or Azure Virtual Machines, because these have capabilities that Azure Websites don't . These two also offer a free subdomain: xyz.cloudapp.net, but my question is: will I get HTTPS there too? and how?
I searched in google for some cloudapp examples and what I tested was the following:
1) Connect through HTTP (ie. type http://xyz.cloudapp.net). Result: worked
2) Connect through HTTPS (ie. type https://xyz.cloudapp.net). Result: didn't work (chrome gave ERR_CONNECTION_TIMED_OUT)
No. HTTPS is not offered for .cloudapp.net domain as of today. Also since you don't own .cloudapp.net domain, I don't think you can buy a SSL certificate for that. If you want you could create a self-signed certificate and use that.
I would walk through the documentation listed here:
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Since you're getting a timeout with HTTPS (rather than a certificate error), check that you have a HTTPS endpoint defined in ServiceDefinition.csdef.
Additionally, be aware that the redirect-to-subdomain approach isn't much more secure than using a self-signed certificate. The reason browsers reject self-signed certs is that they are vulnerable to spoofing attacks: a user can't detect if an attacker has, for example, hijacked the DNS to point to his IP address instead of yours, where he hosts a facade of your site that just collects passwords or whatever.
In your scenario, the cloned site could redirect to another a second clone, one that is a facade of your cloudapp.net site. It could be even be secured with the attacker's SSL certificate. Unless the user was trained to recognize the host name of the real cloudapp.net, she wouldn't know she was on the attacker's "secure" site.
** Update: This method is not valid as well, we got the certificate revoked after one week using it **
We use this approach for staging/dev servers:
If you don't want to use a self-signed certificate, one option is to purchase a cheap SSL certificate, e.g.:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Then once you need to approve it you have to ask support to change the approver validation process: instead of sending an email to a admin#mydomain.cloudapp.net you can ask to change the validation process to placing a given file with a given file in the root of your website (you have to ask in the support / chat room about that option).
More info:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/alternative-methods-of-domain-control-validation-dcv
I have an embedded device which runs a web server.I need to integrate the server SSL certificate for the web server. If I have multiple such boxes, is it required to have different SSL for each box?
You can buy a wildcard certificate say for *.mydevices.mydomain.com, then give each device a name like myRouter1.mydevices.mydomain.com and that's it. Certificate Authorities do sell wildcard certificates, yet they are more expensive (but if you have many devices, this will be cheaper).
You need to consider one thing though - if the certificate's private key leaks from the device in any way (eg. the device is stolen altogether), you can revoke the certificate. But if you have one certificate shared on all devices, then the leak will invalidate all devices at the same time and you will have to replace the no more valid certificate on all devices.
Of course, you're going to get an "it depends":
If your users require a CA-signed certificate, then you'll have to pay for one for each box and load it some way. Browser's then won't complain...
If your users will allow a self-signed certificate, then you can just have the box generate one when it is commissioned. But, your user's browser's will complain...
If you ship with the same certificate, then it's kind of a security problem for you.
I would build a mechanism in so the user can load a certificate to the box in the field. Then you can satisfy whatever need comes up.