I just got started programming WCF services and got my first service up and running for a local police department. They will be using this to lookup plates for overnight parking violations. It's running message security and an x509 certificate for encryption.
Is there a way to package the certificate with the installation or some how have the service create it and download it to the client depending on the authentication I am using?
Right now I am going to be manually installing it on each tough book but would like to automate the process more.
Certificate distribution is a standard task for most enterprise IT departments, applications modifying CA roots is somewhat taboo.
If you are talking about pushing the public key of a server certificate to each client, look at Add a trusted root certification authority to a Group Policy object. If you are talking about creating a client certificate for use of mutual TLS authentication, look at Deploy User Certificates.
If instead you are talking about an ephemeral certificate some other certificate which is only accessed by your application from code, you can add it as an Embedded Resource in your assembly and use it via the X509Certificate2(byte[]) constructor.
I would caution you against putting a private key in your application resources, since any user of the application can do whatever they wish with it. PKI is designed such that Private Keys do not need to be shared. Regardless, Jeff Valore shows a method to do so, which I have reproduced below:
var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("MyCert.cer");
var bytes = new byte[stream.Length];
stream.Read(bytes, 0, bytes.Length);
var cert = new X509Certificate2(bytes, "certPassword");
Related
ACME is used by some certificate authorities to process automated signing of certificate requests and issue resulting certificates.
An increasing number of applications (Eg Traefik) now have builtin support for ACME. This is very useful for managing certificate cycling without tracking where every deployed application stores its certificates.
However "free" certificates from letsencrypt and similar certificate authorities are not always appropriate for all applications. Such examples include some software requiring the exact same certificate being installed in multiple layers of an application's edge gateway (yes this does happen).
I'm wondering if, hypothetically, ACME v2 can be used to redistribute existing SSL certificates and associated private keys. Or is it only capable if responding to CSRs where the private key is never transferred between ACME server and client?
ACME is defined by RFC8555 currently.
There is nothing that prevents other CA to use it, besides Let's Encrypt, and indeed there are other CAs existing using it, and others adding it to their existing API.
The key associated to a certificate should never travel. The CA shouldn't know it. As such, there are no operations in ACME that would allow a CA to send the key, besides the certificate, and that is a good thing.
Retrieving a certificate is a core operation, see "7.4.2. Downloading the Certificate". It could happen separately/outside of a previous certificate request. The problem being then: how does the client know which URL to use to download a specific certificate (an information that it receives when doing the normal authorization/validation steps)?
There are other protocols to manage communication of cryptographic materials such as X509 certificates.
Still in ACME, you might be interested in RFC 8739 "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)" which allows the CA to pre-generate certificates.
And the related RFC 9115 "An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates",
Outside of ACME, but very similar, you have RFC 8894 "Simple Certificate Enrolment Protocol" (but still no transmission of private key).
But you are not clearly describing the problem you have around "redistribute existing SSL(sic) certificates and associated private keys". What else do you really need besides an URL that gives back that data if it is that you want to send back to client (but again: making the private key travel is, in general, a bad idea)? Is authenticating the client the problem? Discoverability of the URL to use to download a specific certificate/key?
(This is for a new project, so I'm still considering options.)
I've got a server and client (phone app) communicating via gRPC, and now I'm looking into securing that connection. A common recommendation I see is to just use a self-signed server key, and embed the server's certificate directly within the client. This lets the app trust the server without requiring a cert download or third party CAs.
However, my understanding is that these certificates are only good for a year (per the openssl command to generate them). Wouldn't there be a problem in trying to renew the cert, when the old version is directly embedded in the client? I don't see how you could prepare the client for the new cert either, as both server and client would have to use the same cert for every request, right?
Given how often I see this method suggested, how do you get around the expiration problem?
We have multiple programs hitting one WCF Service. When a client sends a message they get to define both a client certificate and a service certificate. To do signing and encryption. As far as I know a service can set both at start up. But i'm finding difficulty on how a service would check certificates on a per request basis.
If program A uses a certificate and program B uses a different certificate. Is there a way to tell WCF how to look up those certs without using the windows certificate store? I know how to load a X509Certificate2 from a file but can't seem to find what piece needs to be overridden to tell it to use a specific cert based on what is coming in. Everything I have done so far looks for that clients cert in the cert store. Business rules would rather we placed them somewhere else that we are encrypting. I would like program A's request to use one file and program B's request to use another that I can specify.
In order to do client authentication, you actually need a certificate + a private key, i.e., not just a certificate.
You need a .PFX file that contains both a certificate and its corresponding private key. PFX are password protected.
Here is a sample code:
Client client = new Client();
var cert = new X509Certificate2(File.ReadAllBytes("c:\\certificate_with_key.pfx"), "pfx_password");
client.ClientCredentials.ClientCertificate.Certificate = cert;
We have selfhosted WCF services running using NetTCP:Transport:WindowsClientCredentialType
// Set Binding Security.
netTcpBinding.Security.Mode = SecurityMode.Transport;
netTcpBinding.Security.Transport.ClientCredentialType = TcpClientCredentialType.Windows;
netTcpBinding.Security.Transport.ProtectionLevel = System.Net.Security.ProtectionLevel.EncryptAndSign;
We now need to expose these services to domains outside our own but want to continue selfhosting and not use IIS. Thus I am trying to switch us to a ClientCredentialType of Certificate.
// Set Binding Security.
netTcpBinding.Security.Mode = SecurityMode.Transport;
netTcpBinding.Security.Transport.ClientCredentialType = TcpClientCredentialType.Certificate;
netTcpBinding.Security.Transport.ProtectionLevel = System.Net.Security.ProtectionLevel.EncryptAndSign;
I have previously setup a development environment (long ago) where we used MakeCert to generate a "dummy" certificate for development purposes with WCF. But we have since purchased a certificate from Verisign. I am a bit fuzzy on what needs to happen now. I can see us using this certificate to validate our Services to the Client, but how do we validate our .NET client with certificate? Do we use the same certificate? Do we have to install this certificate during install of our client? Bit wrapped around the axle here and could use a could explaining if anyone can help out.
No you will not install your certificate with private key on your clients. You mustn't give your private key to anybody - once it is compromised your security has gone! The problem is that client certificate must have a private key as well but that private key must be owned only by that single client. That means another certificate per client.
How is it usually implemented? By local certificate authority issuing certificates to your clients. Your service will trust that authority and so all clients holding certificates issued by your authority. That is the only scenario to get this under control otherwise you need to find another mechanism to authenticate your clients.
My use case is very simple : I have a GUI application, and inside this application I host a service however clients of this services must be able to authenticate with UserName safely (The only thing I want is to encrypt messages to be sure that nobody can sniff to retrieve password of clients, I don't care about more security).
So, I want to ship a certificate with my GUI application and that my host (which is inside the GUI application... I know it's a little dirty) use the certificate to encrypt messages.
So my question is : Does my requirements oblige me to install the certificate inside the store on the host machine ?
Am I obliged to generate a new certificate with makecert for every host ?
What is the easiest way to deploy my application ?
(I control the client application so the validation of the certificate is not a problem)
First of all you should not use makecert to generate production certificates.
You could store the certificate in code and not in the machine but keep in mind that the security of the whole encryption is as good as the security of the certificate's private key. If the machine where the application will be run is secure you could use the certificate "incode" but if you cannot guarantee the security of the host machie you should install the certificate in Windows Store. Make sure the user running the application has permissions to read the certificate's private key.
If using WSE or WCF make sure you test the default message or transport encryption methods provided to see if they are good enough for your use.
Here is some references for installing certificate with private key (.pfx file) programmaticly.