I am hosting a secured WCF service which is a wrapper over an existing ASMX service.
My service needs have certificate authentication (transport level security, same as in the original service). My problem is that the users will be using client certificates issued by original service And not my new certificates.
To my knowledge you can not customize certificate authentication over Transport level security. But there must be some way to use third party cert authentication/encryption here
Does anyone having idea on how to make it possible in this case?
How can you have a digital certificate without a public key? Digital certificates rely on asymmetric cryptography. If you don't have the public key file, then you can export it from the certificates you do have - but they most certainly do have public keys.
Related
There is a server with WCF client, which periodically initiates communications over internet with many WCF services installed on our clients computers. WCF services and WCF clients are hosted in Windows Service, current binding is basicHttpBinding.
Communication has to be over https with mutual authentication. Company ordered SSL certificate but it is not clear if this certificate can be installed on clients computers (because WCF service is there) without exposing a private key. Binding can be basicHttpBinding or wcHttpBinding with transport or message security but using certificates.
Is it possible to install service-side certificate on client computers and client-side certificate on our server? Should this architecture be re-worked so WCF service is on our server or it is possible to secure somehow this current solution?
Each computer involved requires it's own certificate. A certificate value for authentication relies on the uniqueness of the private key. The private key never leaves the host machine, and the certificate can be used to authenticate said machine (because is the only one in the world that posses that private key). As soon as you start distributing copies of a private key, security is pretty much compromised.
Normally such deployment rely on PKI infrastructure which can create certificates on-demand and sign them with a trusted key.
What product/protocol the certificates are used for is irrelevant. What kind of WCF HTTP binding you use it maters not.
I think there's a gap in my mental model of WCF authentication, hoping someone can help me fill it in.
So, I'm creating a WCF service and would like to have clients authenticate using certificates, and message-level security. I'd like the service to validate these using chain trust so that I don't need each client cert installed on the service. For now, I'm not interested in having the service authenticate to the client.
Here's my understanding of what's needed to do this:
The client needs a certificate signed by a CA that's trusted on the service side.
The service needs a CRL installed for that CA.
The service config should have message security turned on, specify clientCredentialType="Certificate", and chain trust for client certificate validation.
The client config should have message security turned on, specify clientCredentialType="Certificate", and an endpoint behavior that tells how to find the client certificate in the store.
The client makes a request to the service, sending its certificate. The service sees that the client's cert is signed by its trusted CA and lets the request through.
Now, all of the walkthroughs of this process I've found also include a step of creating a certificate for the service. None of them explain what this is for, which is throwing me. Why is a service certificate needed if I just want to authenticate the clients?
You are right. In theory no server certificate is required, in practice wcf enforce you to use one. The good news is that you should use a dummy certificate for the server and also set ProtectionLevel to SignOnly. I suggest to read this article which talks on a similar scenario and mostly relevant.
Firstly, Thanks to all those patient techies trying to help unknown people.
Secondly, I have a wcf service which should be consumed by only several clients (10) known to our company. This wcf service has the x509certificate "CN=ABCD". Now it expects to receive a certificate in turn from clients to consume this service. So here are the design questions
Should I create one certificate
"CN=ABCD" , then right click on it
and export as pfx files and
distribute them to Clients?
Some say to validate in code and
some say to validate in config which
is better?
How should I know which client is
calling as the certificate has same
name for all if my company
distributes it?
what is the difference between .cer
file and .pfx file?
When passing the certificate to
clients, will I be giving both .cer
and .pfx files?
How should I be revocing only one
client if it expires?
My comapny already has a certificate
like *.fdfd.org . Can I use this as
my X509Certificate instead of
generating one?
Many questions! But due to lot frustration, I wanted to have the opinion of developers out there because I couldn't get the right info.
NO You must have separate certificate for the service and you should have one certificate for each client. Once you share private key of your service your security has gone.
You can either install public keys of client certificates to Machine\Trusted people (client with any trusted certificate will have access to your service) or you can use custom certificate validator (only message security - according to your previous question you probably use message security) to validate really only those 10 certificates.
This is only possible if you create separate certificate for each client. It is also possible to combine certificate with supporting user name and password but it requires very advanced WCF configuration and still sharing single certificate among multiple clients is a bad decision.
Certificate is just container for some information - keys for asymmetric encryption. .cer contains only public key which can be freely distributed - you will probably have to distribute .cer file of your service's certificate among clients. .pfx contains both public and private key and must be secured as much as possible. Once .pfx file is compromised the certificate is not secured any more and must be replaced. Because of that you must keep your service's .pfx (installed in certificate credential store) and each client must keep his .pfx.
If you create certificate for clients you will pass at least .pfx to them. Obviously once you send such certificate by unsecured email you seriously hurt the security.
If one client expires you will remove its certificate from trusted certificates. If you have your own certification authority (which you should have if you want to create certificates for clients)
If your service sits on fdfd.org you can probably use it but only for the service.
What is the advantage of using a trusted certificate instead of self-signed for message security in WCF?
As far as i understand it's only used for encryption, not really validating the identity.
Depends, if you use an SSL certificate to offer the WCF Service in https then it's used for encryption, and the client could require it to be trusted (or not).
If the WCF Service Requires the client to sign the request, it is only used for Validation/Verification - and then you will certainly need a trusted certificate.
(The client certificate is then configured as an <endpointBehavoir>)
The problem is you cannot really trust the message unless you trust the issuer. Message security implies encryption and signature. If the certificate is not signed by a trusted issuer, there is a much higher risk that the security infrastructure is not reliable:
are certificate properly stored?
who is able to issue certificates?
...
A valid certificate is one of the first steps to secure your infrastructure.
Think of it as if anyone was able to create his own ID card, how would you trust someone then?
We have a typical client-server WCF service and I would like the following:
Client passes a certificate to the Server through the ClientCredentials property
Server looks at the certificate and see's that it has been issued by our trusted certificate authority
The client is rejected if they use a certificate that is not issued by our CA.
The client has a clientAuthentication certificate installed, along with our trusted CA.
The server has our trusted CA certificate installed. I dont want to install any other certificates.
I am flexible on the binding, however it does need to work in a web scenerio.
I thought about using BasicHttpBinding with TransportCredentialOnly, however it doesnt support certificates :(.
Ive tried using wsHttpBinding in Message mode, however that requires a ServerCertificate to perform server authentication and message encryption... which I dont want!
Is there any built-in way to achieve this?
All build in bindings allow using client certificates only when server certificate is used - mutal certificate authentication and security. To support your scenario you will have to handle it completely yourselves. If you want to inject your authentication mechanism to WCF you will have to do custom token and custom credentials.