I have a pfx (create with openssl) with CSP = "Microsoft Software Key Storage Provider". Certificate's key usage is set to Digital Signature, Key Encipherment, Key Agreement. Certificate is imported into LocalMachine, in Intermediate Certification Authorities. The reason for that CSP option is because I want to have the private key stored in the TPM when the certificate is imported into the Windows Certificate Store.
I have a WFC service (.net framework 4.6) with certificate authentication configured. When the service starts (service is hosted in console app during dev, and running in elevated privileged as Administrator), it throws
System.ArgumentException: It is likely that certificate 'CN=xxxx' may not have a private key that is capable of key exchange or the process may not have access rights for the private key. Please see inner exception for detail. ---> System.Security.Cryptography.CryptographicException: Invalid provider type specified.
Have googled and a number of posts have suggested that it could be a permission to the private key that is the issue. But I have no idea where is this key located?
Or is there other causes to this error?
Related
I have a SOAP web service inside that I am calling a third party secured web service (it was HTTP earlier now they secured it). they have valid SSL certificate. while calling the third party service I am getting below error,
Server was unable to process request. ---> The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel
at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
There are few articles which says TSL 1.2 should be enabled, to check about TSL further, I have below component on my server,
Here is third party service call,
Can someone guide me, where should I setup trust relationship ?
Do I need to modify my code or just some configurations changes needed
In addition to Abraham post above, make sure that that IIS has enough access to the certificates. We faced the issue and at first, it seemed like the app could access the certificates but that wasn't the case. We fixed it by going to the Manage Certificates -> Personal -> Certificates -> Right Click the certificate -> All tasks -> Manage Private Keys -> Add -> Grant Access to "Everyone" (testing only, you should only grant access to IIS). The connection worked after doing this.
There is a process of exchanging the public key of the service certificate during the secure communication. Therefore, we should establish the trust relationship between the client-side and the server-side. As for mutual certification authentication, we should establish the trust relationship each other.
Trust relationship represents the certificate is valid, the server is real and secure. Namely, it represents this is a validation of the server’s identity. This also could be accomplished by the below code segments.
//adding below code segments to ignore the service certificate validation.
ServicePointManager.ServerCertificateValidationCallback += delegate
{
return true;
};
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Ssl3;
More commonly, this should be finished by installing the service Root certificate in the local Trusted Certification Authorities.
To get the certificate you can either,
1, Ask the service vendor for it, you can ask for the Root CA
certificate, you can authorize all the servers you need at once;
Use a web browser to get the certificate. Access the service creation page with HTTPS(https://localhost:xxxx/xxx.svc). Then use the web browser options to export the certificate to a .cer file.
Install the certificate.
Double-click the .cer file to install the certificate. Choose Local Computer, then choose Trusted Root Certification Authorities.
Here is a detailed step.
https://success.outsystems.com/Support/Enterprise_Customers/Installation/Install_a_trusted_root_CA__or_self-signed_certificate
Feel free to let me know if there is anything I can help with.
How do I add a Connected Service that requires a Certificate?
I need to call a SOAP API developed by another company. The company has supplied me with a pfx-file based on a cer-file I've created. I've installed the certificate in "Trusted Root Certification Authorities" (in local computer and current user) using the supplied password. But when i try to add a WCF Web Service Provider either through the URL or the wsdl-file I get the error: "Could not create SSL/TLS secure channel", and the addition of the service is abandoned.
When I contacted the company they asked me to check if the certificate was installed correctly by calling the API from SOAP UI (adding a jks-file they gave me) - this works fine. They could not be of further assistance.
I'm writing a aps.net core web application and using .net core 3.0 in VS19
I'll have to mention that this is my first practical encounter with certificates and the question might be somewhat in concise.
The PFX might contain more than one certificate.
Are you shure you created a .cer (Certificate) and not a .csr (Certificate signing request)?
Nonetheless, the certificate must be in the personal store and the the certificate that issued it must be place into the Trusted Root Certification Authorities (if it is the last one in the chain).
Here is an example ( i ran certlm.msc and clicked the end entity certificate:
Sectico is the root certificate and goes to Trusted Root Certification Authorities
COMODO RSA ... is the intermediate certificate and goes to Intermediate Certification Authorities
Daniel... is the end entity certificate and goes to Personal
I recommend to import into Personal and then move (drag-drop) the certificates.
For the end entity there must be a private key associated - which can be identified by the key icon:
Microsoft also provides some documentation on the topic: https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff648360(v=pandp.10)?redirectedfrom=MSDN
Why a service certificate is required when non-windows client credential specified ?
(i found some specifications on the book said that, a service certificate can be used to negotiate a symmetric key for messaging encryption and signing when negotiation is enabled, but if negotiation is disabled, the client must reference the certificate in the store or including the BASE64 encoded public key, it comes out another question as below)
when the negotiation is disabled, definitely the service certificate will be used for encrypting message, because the client knows the public key, but which one will be used for message signing ?
when the transport security is enabled, and the service certificate is also specified, it said that the certificate will be used for negotiate a SSL session key for message signing and encryption, it applied to all the bindings ,such as HTTP, TCP, etc.
when we are using the windows client credentials, which one will be used for message encryption and signing?
thanks.
IF you choose to authentucate the client you can choose between windows credentials, username, certificate or SAML token. If windows auth is not available you need some other mechanism.
As for the other questions please be more specific. In general client will generate a temporary key (session key) which will be used to encrypt the message. Server certificate will encrypt the session key.
I have the error "The X.509 certificate ... chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. The revocation function was unable to check revocation because the revocation server was offline."
I get this error when I run my wcf service in IIS with an apppool under the "ApplicationPoolIdentity". I have given the "ApplicationPoolIdentity" accounts (iis apppool*) private key access permissions to the certificates in the store. It works fine under "Network Service". The certificate is internally issued from one of our domain controllers. I thought that Microsoft wants websites to be run under "ApplicationPoolIdentity" now. Is there a way to give the correct permissions to the "ApplicationPoolIdentity" in order to avoid this error or should I just use "Network Service" instead?
What you will probably notice when you put a network sniffer like WireShark on the line, is that the identity that your application pool is running under is not allowed to go to the location mentioned as URL in the revocation parameter in your certificate chain. That problem does not occur when the application pool is running under the NETWORK service account, as you describe.
As stated by the error logged to you, you can also change the revocationMode="NoCheck" to disable WCF checking for revoked certificates. Read http://msdn.microsoft.com/en-us/library/aa347699.aspx for details. But you should only do that either is a safe closed environment or for development purposes.
I'm using SharePoint 2010 and I'm configuring a web part using ChannelFactory and Certificate to access a WCF service.
But I'm getting this error message:
Error occured: Could not establish secure channel for SSL/TLS with authority 'my FQDN'.
How could I configure my SharePoint web application to have access to read this installed certificate?
(I'm sure the certificate is installed correctly on the server where sharepoint is installed and all the WCF configurations are correct)
Many thanks in advance,
Are you talking about a client certificate that SharePoint would use to authenticate itself when connecting out to some service? If that is the case, then you would need to install a certificate along with a private key. Otherwise, if you are just talking about a root certificate to validate some server certificate on a remote service, you do not need the private key.
Assuming that you mean a client certificate with private key (I don't know how SharePoint uses certificates), then you would have to install the certificate along with a private key, and then, make sure SharePoint has access to the private key.
It's not enough just to install with the private key -- you have to either install logged in as the Windows account that the code using the private key will be running under, or, if you install the certificate into the Local Machine "Personal" store, for example, you have to set an ACL on the certificate to give another Windows account access to the private key. To do that, you can use the WinHttpCertCfg tool. Cf. here for the general idea, and here to download the tool. Or from the MMC Certificate snap-in, select the certificate in the Local Machine, Personal store, right-click, select All Tasks, Manage Private Keys, and grant access from there.
Have you tried uploading it to the Manage trusts area?
http://centraladmin/_admin/ManageTrust.aspx
Rebooted the server?
Installed on all servers in the farm? Into the machine store (not service or personal)?