I have an application that can be downloaded from my website and run on user PC. This application doesn't do anything special and just allows the web page to access the scanner. It uses SignalR for communication.
Basically, I run SignalR server under WinForms application and have javascript client that tries to access it through http://localhost:8084/signalR.
Everything works fine when I use HTTP version of the web application, but fails, when I use HTTPS for my web application: Most of the browsers don't allow unsecured connections from a secure page.
So, I've created a self-signed certificate that is installed on user system during installation and it works fine for Chrome, IE and Opera, but fails for Firefox and Edge.
So I was thinking, is there a better way to access SignalR applications that are running on localhost from webpage under https?
There isn't a better way. You are correct in your understanding that "[m]ost of the browsers don't allow unsecured connections from a secure page". I believe there isn't a browser that will allow this. Therefore if you want to call out from a secured website, you must use a secured connection as well.
I don't know the issue you're experiencing with Edge, as I can confirm that it does work. Firefox will NOT trust a certificate in the cert store, even if it is a trusted root or has a trusted root certificate. You have to manually add an exception for this certificate. Details, or at least information that will let you find the correct method to do this, can be found here.
There are some things you have to do in order to make sure your certificate and configuration is correct. First, you have to have a well formed certificate with a public and private key and a well formed certificate authority cert with only its public key. By "well formed" I mean it must contain all information required by browsers for full trust, such as a Subject Alternative Name entry.
You can use OpenSSL to generate the CA, then use that to sign a certificate you will use for the SSL port. Export the CA's public key and the SSL certificate's public and private keys. Exporting the CA's private key is a MAJOR no no. That would allow third parties to create new certs from it and install them on your client's machine. The CA gets installed in the machine's Trusted Root Certification Authorities store. The SSL cert can go into the Personal/Certificates store.
Once you have these, you have to configure the URL/Port you will use for access and SSL using the netsh command line tool. Add a URLACL to allow the application to access the url and port (netsh.exe http add urlacl), and then assign the certificate to the port (netsh.exe http add sslcert ).
Having done all this, you should be good to go. The only real problems you should have are Chrome being very demanding about the configuration of your certificates and Firefox refusing to trust your CA certificate even though it is in your trusted certificate store. Bastard.
And for Edge, I can definitely guarantee if you do all the above it will work. If it doesn't, you need to consult the js console to see what errors it is throwing.
Related
We have developed a .NET 4.5 application that runs an embedded (OWIN) webserver on localhost.
Some of its functionality requires us to make AJAX requests to that webserver from a public website on the Internet.
The problem is that that site uses HTTPS. Chrome now complains that there is unsafe content being loaded (which is correct).
To solve this, we would need to have our embedded webserver use SSL, so that there is no HTTPS-HTTP traffic. There are plenty of examples online of creating a self-signed certificate and binding that to a port, but our application needs to be distributed as well.
Is it possible (and how) to create a self-signed certificate for localhost (OWIN) that is actually redistributable?
I understand that this means that the connection is not trusted, because it's not verified by an SSL Authority, but we're only trying to use it so that there is no cross-protocol communication between the localhost and the public website.
We solved this in the end;
We are using SignalR and we distribute/install a certificate on the clients that is bought specifically for this purpose.
So our setup installs both the application and the certificate and binds it to the OWIN server. We got most of the information on how to do this via this blog:
https://weblog.west-wind.com/posts/2013/Sep/23/Hosting-SignalR-under-SSLhttps
It contains a detailed step-by-step description on how to get this to work.
EDIT:
Binding the certificate to the port is done by using the netsh command. We use InnoSetup to execute this for us. Info on how to do this is here.
Please note that we use a single certificate, and the command needs the certificate key in order to bind it.
This might be an issue using multiple (different) certificates, I'm not sure if it's possible to extract the key from the certificate to dynamically issue the command for different certificates. For a single certificate we had only a single key, and that was hardcoded.
It might be possible to extract the key, this is some info that might help in that regard.
I am making the proxy server. The problem with HTTPS connections. I found that I need to generate the certificate for each host and put it to Trusted Root.
But for example Fiddler uses only one certificate for all connections. Maybe it generates selft-signed, but don't install to the Trusted Root.
Maybe I can download the certificate from the server and use it to speak with a browser?
Installing and uninstalling certificates takes a bit long time.
You need to use your root-CA certificate to sign the server certificate of the server you are spoofing. As long as the root-CA certificate is valid and trusted by your browser, your browser should not throw any errors. So you need your browser to trust only your root-CA certificate and not every server spoofed certificate.
if we need to secure web site or use HTTPS for our web site then we need to use certificate at iis level. in development pc we often use Self-Signed Certificates which can be created very easily from IIS.
i visit this url http://weblogs.asp.net/scottgu/archive/2007/04/06/tip-trick-enabling-ssl-on-iis7-using-self-signed-certificates.aspx to learn how to create & use SSL for our site
after doing everything when we run or test the site in local pc then i feel Self-Signed Certificates does not work like real life certificate which people buy. here i am adding couple of picture from there you can see what kind of problem i am talking about.
just see the second picture and look at url. in case of ssl a lock sign come with green color.
so just guide me what else we need to do as a result Self-Signed Certificates just works like real life certificate in my pc. please discuss this in detail or redirect me to right article which can show what else to configure as a result browser address bar should properly reflect for SSL.
thanks
The certificate works the same. The problem is that a self-signed certificate is not always included in the browser's Trusted Issuing authority. If your sole purpose is for development, you can follow this method here of adding your issuer (self) to trusted authority or adding the certificate itself as trusted.
In production website, you need to purchase an SSL certificate because your visitors' browsers cannot trust self-signed certificates as they cannot verify the issuer.
Having said that, for development and testing purposes, the behaviour you described is fine, but if you really need to get rid of the warning, you need to register the certificate in your local PC (all PCs that you don't want to see the warning on) and then use the same certificate for your website in IIS.
Follow this guide from step 2 onward, but here are the outlines:
First you need to copy the certificate to your local PC:
In IIS, export the certificate to a file.
Copy the file to your local PC.
Use MMC to import the certificate from the file. Make sure you import it to Personal folder.
Repeat the last two steps for all PCs.
Now that you have the certificate registered in your local PC, you need to tell your PC to trust it:
View the certificate in MMC and go to the second "Details" tab.
Scroll-down to the "Thumbprint" and selected it to display the certificate hash.
Copy the has into the clipboard (the hash identifies your certificate).
Open Notepad and paste the hash there.
Remove all the spaces from the hash using the "Replace" feature in Notepad.
Use the hash in the following command:
netsh http add sslcert ipport=0.0.0.0:443 appid={214124cd-d05b-4309-9af9-9caa44b2b74a} certhash=PASTE_YOUR_CERT_HASH_HERE
Note: The "AppId" doesn't really matter, its just a GUID.
In MMC, move the certificate from the Personal folder to the Trusted Root Certificates folder.
I have a client application (windows service) which sends a request (WebClient.UploadString()) to a web service. I've created a certificate through IIS. This I attach to the WebClient before sending the request. However, I get the following message:
The remote certificate is invalid according to the validation procedure.
I believe this is referring to the server having an invalid certificate, but I am unsure of the best way to make the client trust the server. Eventaully, this web service will be installed on a number of servers as will the windows service so I can't attach the certificate to a single computer. Any ideas?
I don't know your exact situation/setup, but here is some general info on using self-signed certificates.
If you want to use a self-signed certificate you will need to add that certificate to the server's trusted root certificate store.
Basically the server does not trust the certificate used to sign your certificate, which is the certificate itself since it is self-signed.
As an alternative, you can create your own root certificate and add it to the server's trusted root, then use that to sign additional client certificates. This will make it easier because you won't have to install each client certificate on the server, just the root one used to do the signing.
Of course, you can always buy a certificate from a company (GoDaddy, Verisign, etc). These will be signed by a certificate that is already trusted.
Also, there might be ways to bypass the checking, but you probably don't want to do that.
I am having a lot of trouble setting up an X509 certificate scheme in C#.NET. SSL is enabled on the server and the connection is being made over SSL. Certificates are being added to the request's store via request.ClientCertificates.Add(). However, no client certificate is being attached to the handshake request (which I am both confirming by both checking the server's code through HttpRequest.ClientCertificate and by analyzing the handshake in Fiddler).
As nearly as I can tell, the problem here is that the server is not requesting a client certificate. The certificates are definitely in the outgoing request, but I see none on the handshake and none on the server side - they simply disappear into the ether. I'm aware of the semantics behind choosing a certificate (thanks to this page), but it hasn't resolved my problem. The CAs should be the same; I am using the same self-signed, private key secured certificate for each end of the test.
Apparantly I can use certutil.exe to check which certificates will be chosen when used with a given server certificate. This would be a huge help if I could figure out how to use it like this. Certutil is a big program that is poorly documented. Any help would be appreciated.
If you're using IIS serverside you MUST provide certificate that is trusted by your server. So you MUST add client cert' CA cert into server computer 'Root certificate authorities' storage. IIS doesnt work with self-signed certificates. It requests client cert providing list of CAs it trusts to.