Is there way to attach client side SSL file (.pfx) file in WCF binding? I don't want to use certificate store.
This should work
webServiceProxyInstance.ClientCredentials.ClientCertificate.Certificate = new X509Certificate2("path to the pfx file", "password to open the private key");
Related
I am currently facing issue in connecting to a soap https service from soapui. I am provided with public and private certificates. I have added the public certificate in the preferences--> SSL setting tab. And then I have configured the outgoing ws security --> keystore with the private key. Also I have created a signature with the private certificate.
When I hit the service am getting a soap response saying "certificate is not trusted" . Am new to this setup and please correct me if am wrong.Can you please help me in resolving the issue ?
I have been given a wsdl and xsd file from a company partner to access their https service.
I have installed the client certificate and can access their API using SoapUI after configuring the security in soapUI.
what are the next steps to consume the API in a .net application?
I have generated the proxy using svcutil.
I have added the certificate to the local machine and current user - trusted root certification authorities
The cert is from the service provider and works through soapUI. its not self signed.
When i make the call to the service i get Could not establish secure channel for SSL/TLS with authority 'WEB_SERVICE_URL:11851'.
Do i need to configure https in the config file or what am i missing?
thank you
It turned out i had to specify the certificate in code
// Create the binding.
BasicHttpBinding customerBinding = new BasicHttpBinding();
customerBinding.Security.Mode = BasicHttpSecurityMode.Transport;
customerBinding.Security.Transport.ClientCredentialType =
HttpClientCredentialType.Certificate;
// Create the endpoint address. Note that the machine name
// must match the subject or DNS field of the X.509 certificate
// used to authenticate the service.
EndpointAddress customerEa = new
EndpointAddress("https:URL_OF_SERVICE:11851/WebServices/GetCustomerDetailsService");
// Create the client.
customerClient = new GetCustomerDetails1Client(customerBinding, customerEa);
// The client must specify a certificate trusted by the server.
customerClient.ClientCredentials.ClientCertificate.SetCertificate(
StoreLocation.CurrentUser,
StoreName.My,
X509FindType.FindBySubjectName,
"CERTIFICATE_NAME");
I'm trying to set up a WCF-service with SSL on Azure.
Can someone please explain a bit about the differences of using certificates is these cases?
Certificate for https-binding in IIS
ServiceCertificate in Web.Config
ClientCertificate in Web.Config
Certificate in ServiceDefinition.csdef
Certificate in ServiceConfiguration.Local.cscfg
Certificate in ServiceConfiguration.Cloud.cscfg
More I should know about?
I want to publish several service-endpoints within the same role, some with SSL and some without. Do I need binding-certificates at all or is it service-certificates I should use?
Start by reading WCF Transport Security with Certificate Authentication and Configuring SSL for an application in Windows Azure
Certificate for https-binding in IIS - exactly what it says, the cert is used by IIS to create a secure binding on a site/service, typically on port 443
ServiceCertificate in Web.Config - WCF service-side binding cert used for WCF Transport Security with Certificate Authentication - private key cert used to authenticate client request signed with the corresponding public key
ClientCertificate in Web.Config - WCF client-side binding cert used for WCF Transport Security with Certificate Authentication - public key cert used to sign a request for authentication to a service using Transport Security with the corresponding private key
Certificate in ServiceDefinition.csdef - default certificate used to create a secure endpoint in Azure worker & web roles. NOTE: This is the certificate Azure installs in IIS to bind to the service endpoint (see #1)
Certificate in ServiceConfiguration.Local.cscfg - same as 4, just used in a "Local" build/deployment configuration
Certificate in ServiceConfiguration.Cloud.cscfg - same as 4, just used in a "Cloud" build/deployment configuration
I am in a process of generating an SSL cert for a domain name.
What I have done:
Went to the IIS management > Server Certificates and clicked on Create Request. This generated a *.com file with a hash inside it that I submitted to the GoDaddy.
From GoDaddy I got back a zip with two files: *.crt and *.p7b
I exported the certificate to a *.cer file and uploaded it to Azure, but when I try to deploy the cloud project I get an error:
Certificate with thumbprint associated with HTTPS input endpoint
does not contain private key
After reading similar issues on the Internet, I understand that my *.cer file doesnt contain the private key.
My problem is that no matter how I try to export it to a *.PFX, the PFX option is always disabled in the cert export wizard.
Also not sure if it is related, but when I Click on Complete Certificate Request in IIS and select the cert that I got from GoDaddy. I get an error:
Cannot find the certificate request that is associated with this
certificate file. A certificate request must be completed on the
computer where the request was created.
You will not have the option of exporting from IIS or exporting to PFX from Certificate Manager if you do not do the IIS "Create Certificate Request" and "Complete Certificate Request" from the same machine.
That was my problem. I did these two steps from two different machines.
I had to create a new request (in IIS), go to GoDaddy, rekey my certificate, download the new certificate, and then complete the request (in IIS).
This turned out to be something completely idiotic, as usual messed up by Microsoft.
The process of creating a cert for a domain is that you need to use [Create Certificate Request] in IIS.
Then send the created hash to the Authority and use the [Complete Certificate Request] in IIS where you provide the cert given to you by the Authority. This will install the cert into your local IIS
After the cert is installed you need to right click on it and do an export to a *.PFX file. The PFX file now can be uploaded to Azure or any other hosting...
The processes could have been very simple, if Microsoft didn't make sure to screw it up.
The thing is that when you click on [Complete Certificate Request], the file open dialog has a file type of *.CER, but this is wrong because you need to provide *.CRT!!! The solution is to change the file type select to All Files *.* and chose the *.CRT file provided by the Authority.
I am using WCF for the client to access service. I am trying to access the endpoint with TLS (https). I have certificates with both private and public keys.
If I have the end point of the service to have the host name same as the certificate name ("Issued To"), then i am able to access the service from the client.
If the names of the "issued to" and end point domain name are different i get the error "Could not establish trust relationship for the SSL/TLS secure channel with authority". I have added the certificates to "Trusted Root", "Personal" and "trusted People". In my service i have used "PeerOrChainTrust".
Please let me know if anybody has any idea on this.
Thanks,
Jan
In that case, you need to define the trust policy for the server on client side,
Call SetCertPolicy once before you make any call to the services.
using System.Net;
using System.Security.Cryptography.X509Certificates;
public static void SetCertPolicy()
{
ServicePointManager.ServerCertificateValidationCallback += RemoteCertValidate;
}
private static bool RemoteCertValidate( object sender, X509Certificate cert, X509Chain chain,
SslPolicyErrors error )
{
// trust any cert!!!
return true;
}
I don't think you can override the check on whether the certificate name matches the server name.
Some agents allow you to manually override after the warnings, but unless WCF has a setting to disable certificate validation with all the dangers that brings. SSL is designed first and foremost for the client to be able to validate which server it is talking to, otherwise you will be open to all sorts of vulnerabilities (including man-in-the-middle and fake servers).