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.
Related
I am working on a client-server application where server is a web server which performs client validation based on SSL certificate. Server trust a Root CA certificate. Client is a windows application developed in C++ which has a certificate signed by intermediate CA which in turn signed by Root CA.
I am able to set client certificate during https connection by calling WinHttpSetOption api with WINHTTP_OPTION_CLIENT_CERT_CONTEXT as option. However this will set only client certificate but not the entire chain. Server does not have intermediate CA in its store hence it is not able to authenticate the client.
Is there a way to set the full client certificate chain in WinHttp, provided the full chain is already present in certificate store of client?
The server has to have the CA certificate beforehand, it's not going to trust the root CA the client hands it. (I'm not sure about whether it (the server-side) would trust an intermediate CA signed by a trusted CA but my inclination says no).
Trusting some random CA a client sends would break the entire point of certificate verification, you would have no idea of whether the data the client submits is actually meaningful. So add the root and intermediate CA certificates to the server's certificate stores. (If you don't have access to that you'll have to talk to an admin and have them do it).
I'm not really seeing anything wrong with what you are doing.
You are implementing mTLS. The client side has a private key that it uses to validate itself to the Server. Most times the client will generate this private key itself and just send it to the server via CSR. In your case you have some CA generate it for you.
mTLS is used in place of some other sort of login a client might do to a server. The client itself doesnt care about the cert chain. The client doesnt need to validate itself. It just sends a token encoded via its private key. The server DOES need the root or intermediate cert in order to validate the key the client has sent. Usually you just install this root into your normal cert store (server side) so the server can validate the client.
Only I could find was to Add Sub CA to system store. During service startup or installation, open the CA certificate store and Add certificate context to it.
I wanted to implement One Way SSL in MQTT. From what I researched, in on way SSL, the client has a stored default cert. It will use this initially stored cert and compared it with the cert from the broker side. If the cert is valid, then they established a secured connection. However, our embedded software engineer says that the client side doesn't need cert, it will just have to get the cert from the broker side then it will use for a secured connection. To summarized, what I understand is the client has a stored cert, and it will compare it with the one the broker has. The engineer says the client doesn't a stored cert, it will just get one from broker.
He already tested it by connecting to our broker with any initially stored cert and it really worked. Now I don't understand how one way SSL really works.
SSL with MQTT works as it does with any other protocol.
There are 2* main modes
Server (broker) only authentication. In this case the client connects to the server (broker), the broker sends it's certificate to the client. The client checks the certificate is issued (signed) by somebody the client trusts, this proves the server (broker) is who it claims to be and can be trusted. The client and server (broker) then do key negotiation in order to set up an encrypted tunnel. The act of checking that the server certificate is issued by a trusted party is to check it is signed by a known CA (certificate authority) certificate, this means the client needs to keep a list of trusted certificates.
Mutual authentication of both client and server (broker). This is pretty much the same as before except the client also sends it's own unique certificate to the server (broker) this is also checked to see that it is issued by a known CA and the CN field is used as the user id of the client.
*There is also pre-shared keys mode which don't use certificates at all.
I have my WCF service running in HTTP. I want to make my service run in HTTPS. I did this in my local with self seigned certificate and its working fine. But I'm getting
"Could not establish trust relationship for the SSL/TLS secure channel with authority"
error when I deployed my code in QA environment and created Self signed certificate for the same. I found some solution to validate the certificate at client side (Link). But I'm looking for some solution to fix this from server side. I don't want to disturb the client.
I suspect the error reflect that the client does not recognize your self-signed certificate or the underlying certificate authority. As such, until the client adds the client certificate to their certificate store or otherwise trusts the certificate, the only way they will be able to access the service is via a validation workaround like the one reflected in the link you included.
In order to determine the underlying cause of the issue, you may want to enable WCF Tracing and review the exceptions (especially inner exceptions).
My team supports many WCF connections protected by mutual certificate authentication. We have noticed that the error top level error may not provide as much information as the inner exception. Just yesterday, I had a site with that exact error. When we looked in the trace file, we saw an inner exception revealing that the certificate had not been deployed to the certificate store in the proper location. A few days previously, the “could not establish trust relationship” error had an underlying inner exception that revealed the certificate had been revoked by the certificate authority.
Hope this helps.
Regards,
I've done thorough research on my problem and have read many other posts/blogs but their solutions didn't solve mine. I was hoping someone could help.
I have a very simple WCF service that uses WsHttpBinding Transport Security with Mutual Certificate Authentication. The server certificate is self-signed certificate and I have confirmed I have the certificate in the trusted store on the client machine. The server has the client certificate (also self-signed) in the trusted certificate store and I have already verified that I can mutually-authenticate to the service fine using SOAPUI client.
However, I'm not able to do so using the WCF client I created. On the WCF client, I've set the client certificate by calling the channel factory's Credentials.ClientCertificate.SetCertificate(...) method and I've also added
ServicePointManager.ServerCertificateValidationCallback +=
( sender,
certificate,
chain,
sslPolicyErrors ) => true;
to bypass all possible server certificate problems but I always get: Could not establish secure channel for SSL/TLS with authority server.com.
Can someone please suggest to me what might be the problem and/or what I should do to get this working? Any help is appreciated.
Thanks.
try this to see if this is only a problem with the certificate trust chain:
http://webservices20.blogspot.com/2008/12/wcf-gotcha-disabling-ssl-validation.html
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?