Differences between a bought certificate and a dev certificate? - c#

I Got a solution that contains a C# winform client and a server (Windows Service WCF service, IdentityServer4 and ElasticSearch). Certificate is required when running IdentityServer in production so this will be implemented on all of the services. It will probably only be a one way certificate(function certificate for services).
The production will run a bought certificate.
Is there any reason to buy an certificate for dev or will a dev certificate from a local Windows server be enouth to really test everything like as if it was in production?

A test certificate will work the same way as a bought certificate. Its however possible that you will need to override the check of the certificate on client and service to grant it even if the certificate is not installed in the required service. If you however are able to generate certificate specific for the computers that are running the software, then there will be no need to override the certificate check method.

Related

Access SignalR application running on localhost from browser

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.

Different certificates for each REST-service installation

We are about to implement SSL for a .NET Framework product that uses a service layer which in turn uses NancyFX and REST/JSON.
The clients communicating with the service need to access it through HTTPS, hence the need for a certificate. We are running on both Windows and Linux (through Mono) and the user is prompted for a username/password or sending it through auth header.
To get the clients to trust the certificate, it must be assigned by a trusted CA but how do we solve this when we do not know anything about the address on which the service is configured?
So - how to get a trusted certificate assigned to the installed service with a minimum effort for the user. Best thing would be to handle this through a normal Install procedure (on Windows). Is this possible?
We have a large number of users (> 5000) that will go through the upgrade process and will be needing the certificate, so to manually create and assign certificates does not seem like an option.

How to bypass Untrusted certificate error from GWT client side code?

I created a self hosted HTTPS WCF web service running on my Localhost machine. Now i make a request to this web service from a GWT based application hosted on some domain.
I use self-signed X.509certificate which is not approved yet. Whenever my GWT application make requests, It shows an error because of untrusted Certificate. Can i bypass this error from my GWT client code or suggest me an alternative solutions ?
Is there are any other protocol which supports WCF service that we can use for communication and will not trigger the security alert from browser?
Updated
Whole scenario:
You installed a exe in your system, which take cares of WCF web service and importing certificate to your local machine.
You open a GWT based website from your browser. Let's say some.com
some.com continuously polling a request to his/her local machine. Let's say on https://localhost:8098/{someendpoint}
But because of this HTTPS and untrusted certificate. It is not able to make request.
since you said
Let's start with local testing
How about installing your self signed certificate onto the machine on which you are testing the GWT ?
You should be able to double click the certificate and follow the prompts/wizard to install it.
This applies to development only (for production you'd need a proper certificate)

Websphere MQ access to SSL certificate when running inside IIS7 as DefaultAppPool?

I have a C# Web service which is running under IIS 7.5 on Windows Server 2008 R2 using the DefaultAppPool user as the application identity (IIS APPPOOL\DefaultAppPool). The Web service uses IBM Websphere MQ (7.0.1.2) to do it's stuff and uses the SSL certificates stored in a key.kdb setup via IBMs KeyMan utility.
Normally (for C# apps that are not running IIS) I need to label the personal certificate within the kdb so that it's name matches the user that is running the app i.e. the certificate would be labelled as ibmwebspheremqbs6mjb (see http://www-01.ibm.com/support/docview.wss?uid=swg21245474) and this allows the app to successfully access the SSL certificates within the key.kdb.
But..... when running as a Web service and naming the certificate ibmwebspheremqdefaultapppool the application cannot access the SSL certs. If I change the AppPool identity to be bs6mjb then everything works (I'm not allowed to run the app pool as bs6mjb).
I'd prefer not to setup a default certificate as mentioned in the link above, does anyone know what the certificate should be labelled as to work with DefaultAppPool?
For MQ clients the certificate label must have the user name who runs the client. In your case, for example ibmwebspheremqbs6mjb. If the certificate label is something else, the MQ client (actually GSKit libraries) will not find the certificate to connect to queue manager. I think that's what is happening when you have the label as ibmwebspheremqdefaultapppool.
This blog has interesting and useful details. You may want to check under what user IIS runs and create a certificate for that user and do the required SSL setup between client and MQ queue manager.

self signed certificate in windows server

I have a C# console app that consumes a web service that is outside of my network. I am told that the web services uses self-signed certificate for SSL. I am not familiar with the certificate and I am wondering what I need to do in .net/windows server environment.
Thanks.
Self signed certificates will not be viewed by your application as valid by default because there is not a trusted third party validating the certificate. Typically you'll see self signed certificates on test servers, and you can find more info on self signed versus signed certificates here.
If you are having trouble calling the web services then you'll need to either install the certificate on the machine that your application is running on, or create a custom validator that you can use to tell your application to accept the self signed certificate. From .NET 2.0 onward, custom SSL validation is done by specifying a custom method on the ServicePointManager.ServerCertificateValidationCallback property.
An example of using the ServerCertificateValidationCallback property can be found here:
http://weblogs.asp.net/smehaffie/archive/2009/09/10/calling-web-services-that-use-self-signed-certificates.aspx
That's a large question especially regarding X.509 security. Usually with self-signed certificate, you have to import the initial CA used to sign this certificate (usually the self-signed CA used by the application) into your keyring (to be sure that you are connecting to the right server). It's usually required because your client application will check at the connection if the certificate is signed by a known and trusted CA or matching an existing certificate in your keyring.
In C#, you can check the System.Net.Security namespace and especially the SSlStream class for more details.
If you need to import certificate in your keyring, you can use various interfaces to access the keyring from the GUI, using the command line "Certutil.exe" or via the various APIs.

Categories

Resources