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?
Related
I am working with a REST service provider and they want me to use a client certificate provided by them when making HTTP call.
How does a client cert achieve authentication?
If someone has a copy of the client cert, they too can be authenticated right?
Does a client cert offer anything else beside authentication?
How are they different from a username/password authentication?
How does a client cert achieve authentication?
By being either signed by someone the peer trusts (including self-signing), or signed by someone that is trusted by someone the peer trusts, etc.
If someone has a copy of the client cert, they too can be authenticated right?
Wrong. They would also need the private key.
Does a client cert offer anything else beside authentication?
No.
How are they different from a username/password authentication?
Much more secure. No password-guessing is possible.
However There is no such thing as a 'client certificate provided by them'. The process of generating a client certificate starts with you. You generate a key pair and a Certificate Signing Request (CSR) and you have it signed by a CA. Or you generate a self-signed certificate. You then provide your certificate to them. If they are proposing to carry out all these steps and provide the resulting key pair and certificate to you, they do not know what they are talking about and should be severely chastised for security breaches. A private key is only private if no-one else has a copy.
I'm writing a simple client and server using Go. I don't want to pay for an SSL certificate, and I've read that self-signed certificates are useless for proving identity since an attacker could just MITM and provide his own self-signed certificate.
However, I've learned that I can have my client use whatever root certificates I want. Can I just create my own, have the client trust that, sign a certificate for my server, and connect securely while being protected from MITM attacks? If so, how do I create my own root certificate?
A self-signed certificate is a special case of deploying your own PKI (pushed to the extreme where you only have one certificate in that PKI).
Both can be used to prevent MITM attacks, provided that the client can verify the server certificate using trust anchors (certificates) it knows in advance (and has been configured with them in a trusted manner).
You can create your own CA and configure your client to use its root CA certificate or, if you only have a very limited set of servers, you can usually configure clients to trust a specific certificate directly (self-signed or not).
You may be interested in these questions for links to tools:
Solutions to sign certificates
Recommendations for a Certificate Management tool for Linux
OpenSSL's CA.pl (useful, but may lack general management interfaces)
Once you've understood the basic principles, the technical aspects are not necessarily difficult, but part of the real difficulty is in the administration of your CA.
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.
Designed a svc that will be intermittently consumed by one known customer application across the internet.
Know next to nothing about security so started digging.
Figuring from what I have found;
SSL security transport layer fits.
Self Signed certificate and send public key to client is required.
Am I on the right track or is there a flaw in my logic.
thanks
Bob
You are on the right track
A SSL Certificate helps you do two things:
That the client knows who the server is
That the communication between the client and the server is encrypted
With a self signed certificate you are not sure who signed the certificate, but it works fine for encryption.
The client must trust the certificate, so with a self signed, the client must place the certificate in its list of trusted certificates.
So I have a WCF service where I have various parts of the service contract with a ProtectionLevel of Sign. I set the credentials on the client side by choosing a certificate from the certificate store. This is fine.
However ....
Does this client certificate need to be in the 3rd party certificate store on the server for this to work?
If this is the case how can I configure a service which accepts any client certificate?
And finally how do I access the signing certificate within the implementation of the operations which require signed messages? Just the signing certificate subject name would do fine!
Thanks
Ah the joy of self answering.
So
"It depends". If you have
ChainOrPeer validation then both the
chain or the presence of the
certificate in the trusted people
store results in success. Only
validating on chain obviously checks
the chain, setting Peer validation
uses the store, and None lets
everything through.
Set the validation mode to none
The SecurityContext for the request
contains an X509CertificateClaimSet
which in turn exposes the
certificate itself.