I've been sent two server .crt certificates to use on my side for two-way SSL. I have a certificate that the server I'm trying to connect to has sent me for use too. I'm building a client api that talks to another web service XML api that uses two-way SSL. How would implementing that differ from just one server crt certificate?
Related
One of my clients java/Cold Fusion application is trying to access my WCF web service endpoint using client certificate mutual authentication.
We moved our wcf service to windows 2008 R2/IIS 7 machine and generated new certificate using 3rd party CA. After the change, client is getting 403.13 error.
On investigation, I found that the Certificate Request does not include the new certificate in the distinguished names list.
How can I configure IIS to include the client certificate in the trusted certificate list?
You can't add trusted certificates, it's done on machine level. If you open MMC and add the certificate plugin you should be able to add it to the Trusted Root Certification Authorities on the server.
I have a RESTFul API that I want to secure using SSL Certs. If I were to get some SSL certificates, would I need separate ones for each of my web clients that use my API or would the API be the only thing that needs the certificate?
The SSL certificate is installed on your web server hosting your REST API. The clients don't need to have a certificate to securely exchange data with your server.
Think about all the e-banking/e-shopping sites that you probably use. You don't specifically install any certificates on your computer to be able to use them. As long as you trust the certification authority that issued the certificates to those websites (handled by your computer transparently), your computer can connect to them over SSL.
So, as long as your own server's SSL certificate is valid and issued by a trusted certification authority, your clients will be able to connect securely over SSL without needing separate certificates.
SSL Certificates are for Web Server. You install them in your Web Server. Certificates are matched to your domain. They have nothing to do with the clients. Any client can access your server if you have a valid certificate.
I think you have multiple Resful API's.
Now you need not have separate Certificates for API's since Certificates are matched to your server's domain and not to the API's you host. You can have any number of API's and Clients connected to your server using a SSL Certifcate.
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.
Was wondering what the best practice for deploying a custom WCF - Security Token Service (STS) in a load balancing environment that uses signs and encrypts the token?
We're using Cirtix NetScaler to handle the load balancing and SSL termination (i.e. certificate is only installed on the NetScaler server). The STS has been specified to sign and encrypt the token via the SigningCertificateName and EncryptionCertificateName app settings. However the current web server configuration does not have a local certificate installed within it's certification store.
So my questions are:-
Do we need to worry about signing and encrypting the token if it's transferred over SSL?
Should we install the certificate on every web server or can we use the load balancer?
Can we use the same certificate on each web server or do we need to buy a certificate for each web server?
An STS which does not sign its tokens is not much use: without a signature, no relying party will be able to distinguish between a valid token issued by the STS and a token spoofed by someone with evil intent.
The certificate you install to support SSL is generally different to the STS's signing certificate. The latter identifies the Service, not the web server. So, by all means carry on installing the SSL certificate just on the load balancer. But you will need another certificate, representing the identity of the Service, installed (with its private key) on each machine which hosts the service, for use as the SigningCertificate. It should be the same certificate on each server (it's the same Service).
However, you typically don't need to buy such a certificate: you can issue your own - you just need to make sure each potential Relying Party is configured to recognise the certificate as a trusted STS, and also trusts the root issuer of the certificate (which will be either the certificate itself, if it is a self-signed certificate, or your root certificate, if you used a certificate server to issue it).
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.