I have a WCF service (authored in-house) using a WS-HTTP binding and transport security (SSL). We are authenticating callers with client certificates and a whitelist of acceptable certificates (certs are provided to us out-of-band). So we're using a custom validator (e.g. a class deriving from System.IdentityModel.Selectors.X509CertificateValidator) to do a database query to check the whitelist.
It works in the following case: We have a root certificate used in development, issued by the development team (using OpenSSL). This root is trusted (e.g. installed in the Trusted Third-Party CA cert store) on the server hosting our WCF service. The test client is configured to present a certificate signed by this root. This case behaves as expected.
It does not work in the following case: The client presents a self-signed certificate to the service. In this case the client receives the error message "The HTTP request was forbidden with client authentication scheme 'Anonymous'", and-- here's the odd part-- the service's certificate validator doesn't even run. We don't get any chance to give the thumbs-up. The client cert is rejected by a layer lower than our validator.
How can I use a self-signed client certificate with my service?
You can't. In WCF, WS-HTTP transport security is SSL. My error results from a failure in the SSL negotiation between the parties.
The normal case of this negotiation is as follows: The service sends the client a list of root certificates that it trusts. The client examines this list and finds a certificate that the server will find trustworthy and sends it.
In my error case, the client is examining the server's list and determining that its cert will not be trusted. At this point the client will normally attempt to negotiate down to anonymous access, which is forbidden in my case, so the negotiation fails.
WCF does not support self-signed client certificates, or certs issued by an untrusted CA, in WS-HTTP binding + transport security scenarios, even if you use custom validation mode. It does support this scenario in message security. I suspect that Net.TCP supports this scenario, but haven't tested that.
Related
I'm having a .net core API and an EmailService as a connected service (WCF)
The EmailService is hosted on IIS (HTTPS); I'm trying to connect to the emailService with a Client Certificate. Everything is fine but i'm getting the
The HTTP request was forbidden with client authentication scheme 'Anonymous' error;
On the EmailService side:
The SSL Settings are on Require SSL (Require), the IIS Binding is on HTTPS
On the API side:
When i'm trying to access the emailservice by chrome browser, i'm getting a prompt for a client certificate, i'm picking the cert and everything works alright;
Any suggestions?
Thanks
I am not sure if you can call the service properly since WS-security is not supported in DotNet Core. Anyway, this error typically indicates that the client’s certificate cannot be recognized by the server-side when establishing the Https communication. Also, if your client communicates with the server over HTTP and the server requires SSL, this kind of error also occurred.
The Https secure communication between the client-side and the server-side can not be established properly. As you know, the https secure communication requires the procedure of exchanging each other’s public key of the certificate. Therefore, the server-side and the client-side should establish mutual trust. In other words, the server’s certificate must be trusted by the client and the client’s certificate must be trusted by the server. The specific operation is to install the certificate in the local Trusted Root Certification Authorities.
Please refer to the below link.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/transport-security-with-certificate-authentication
Besides, the client-side should have access to the private key of the certificate provided by the client so that the https secure communication is valid. The specific operation is to add the current user to the private key management group of the certificate.
Feel free to let me know if there is anything I can help with.
Currently I want to expose a gRPC Method as Public API and protected by Auth0 (JWT Token), with Istio(Envoy Proxy) will help validating the token on server side. Since the JWT Token is not encrypted by the standard (it is only used to end-user authentication and authorization layer), I want to encrypt the communication using TLS. Also, my public server already have valid certificate.
The problem is on the gRPC Client side. Every example I look, the gRPC Client have to initialize the TLS Connection with server cert pem file. Is it really necessary? Because it adds operational burden and complexity, where we have to distribute our server pem file everytime we renew the certificate AND/OR the client side has to restart the application.
Thanks,
Agung
If you are using a self signed certificate, then yes you must explicitly trust it in your client. If you use a publicly signed certificate on your Server, gRPC will use the Operating System's certificate authorities to verify the cert. (In the case of Java, it uses the JVMs cert authorities.)
If you are using a self-signed certificate you need to specify the server's root certificates in the pem_root_certs member of the SslCredentialsOptions struct passed in when creating a channel, as Carl says.
However if you are using a CA issued certificate, leaving the pem_root_certs member empty will cause gRPC to default to its own master list (reviewable online), not any OS-specific list.
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.
I have two WCF Services using WsHttpBinding with transport security mutual certificate authentication that are being hosted on the same windows server. Clients that can access one WCF service should not have access to the other WCF service. I need some help on configuring the client certificates on the windows host. The client certificates are signed by trusted CAs and the intermediate and root certificate chain is already installed on the the server. It seems like the service automatically relies on chain of trust and does not require the actual client certificates installed on the server at all before letting the client access the service - this is not the behavior I want. Can someone please tell me how I should be configuring these client certificates in order explicitly allow access to one service and not the other?
Thanks.
That has nothing to do with certificates themselves. When using mutual SSL authentication certificates are used only to authenticate client and the authentication is done outside of your application (this is difference to message security where you can create custom certificate validator). Once certificate is trusted client is automatically authenticated to anything on the server using certificates for authentication.
You are looking for authorization - the step where you define what can authenticated client do with your service. You can either hardcode your authorization logic into your service by using role based security or you can implement two custom ServiceAuthorizationManagers and assign each to single service.
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.