We have a web application under default website using client certificate authentication to authenticate its client. It is failing in handshaking with client certificate for authentication and errored out with either timeout or 403 - Forbidden: Access is denied error.
We found below error on system event logs,
When asking for client authentication, this server sends a list of
trusted certificate authorities to the client. The client uses this
list to choose a client certificate that is trusted by the server.
Currently, this server trusts so many certificate authorities that the
list has grown too long. This list has thus been truncated. The
administrator of this machine should review the certificate
authorities trusted for client authentication and remove those that do
not really need to be trusted.
IIS configuration looks much similar to what we have done for this web application on other environments, we verified couple of other checks required for this application
In certificate Store: We verified all server certificate and client cert with its authority hierarchy are available.
Application Authentication: Anonymous
Application SSL Setting: Require SSL/ Accept
ApplicationHost.config: enabled OnetoOneMapping under iisClientCertificateMappingAuthentication also added base64 certificate mapped with service accounts
I am not sure this authentication issue has to do anything with above error message in event log.
I know that this is probably too late to help the OP, but for anyone else with this event log message, there is a well-structured post on this issue at https://www.codit.eu/blog/2013/04/03/troubleshooting-ssl-client-certificate-issue-on-iis/, which suggests:
There are two solutions to solve this issue:
The first solution is to clean up the Trusted Root Certification Authorities store (Local Machine) and remove all unnecessary certificates. Be aware that you don’t remove certificates that are required by Windows.
A second solution is to configure Schannel to no longer send the list of trusted root certification authorities during the TLS/SSL handshake process. This can be done by adding this registry entry on the web server
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Value name: SendTrustedIssuerList
Value type: REG_DWORD
Value data: 0 (False)
I am developing an API using a local server with a self signed SSL certificate.
Every time I make a request with PAW I get a dialog warning me that the certificate is self signed, and asking me if I would like to proceed.
This gets tiresome after the first few hundred requests.
Is there a way to tell PAW that I trust this certificate?
Here are the steps:
When the alert "Paw can't verify the identify of the remote server..." is shown
Click "Show Certificate"
Check the box "Always trust ... when connecting to ..."
Hit "Continue"
You probably will have to enter your system password to allow the Keychain to mark this certificate as trusted
Then on next calls, it won't prompt you again. See the short screencast here: http://cl.ly/3r102z170X3F
An alternative (but unsafe) way is to uncheck "Validate SSL Certificates" in the Preferences (Paw menu > Preferences), under the "HTTP" tab.
Hope this helps!
I need to give an account a permission for a certificate within a group application, in order to solve the fllowing problem:
Could not establish secure channel for SSL/TLS with authority XXX.
I'm using the winhttpcertcfg tool, but when I execute it, I get a message saying
this can only be done by the user who installed the certificate.
How can I find out who installed the certificated?
I am trying to setup a WCF service to use a Certificate for Authenticating the client. I have read tons of posts on how to create the certificate, and I have been able to do so (finally).
I am installing the Cert Authority and the Cert on a server that runs Windows 2008 R2. When I open the MMC Certificates Snap-in, I choose Computer Account. Is this correct? I am doing this because my WCF service will run in a Windows Service, and will be running even when no user's are logged in. But admittedly, I don't know what the difference is between the three options:
My user account
Service account
Computer account
Once the snap-in loads, I import the Authority Cert into Trusted Root Certification Authorities. Then, I import the cert into Trusted Publishers. I don't encounter any errors when doing this. When I do the import, of both the Authority Cert and the Cert signed by that authority, I don't make any reference to the .pvk file. It is my understanding that the private key is embedded in either the cert or the authority cert. Here are the commands I use to create each cert:
MakeCert.exe
-n “CN=InternalCA”
-r
-sv InternalCA.pvk InternalCA.cer
-cy authority
MakeCert.exe
-sk InternalWebService
-iv InternalCA.pvk
-n “CN=InternalWebService”
-ic InternalCA.cer InternalWebService.cer
-sr localmachine
-ss root
-sky exchange
-pe
Notice I used -ss root. I have seen many posts using -ss My. I don't really understand what the difference is or when it is appropriate to use each value.
My WCF service runs on this machine inside a Managed Service (Windows Service). When I start my windows service, which hosts the WCF service, it crashes immediately and a seemingly common error is reported in the event viewer:
System.ArgumentException: It is likely
that certificate 'CN=TempCertName' may
not have a private key that is capable
of key exchange or the process may not
have access rights for the private key
I have found posts that say I need to grant permissions to the user running the service to the key.
This one seems to be a popular answer here on stackoverflow: Grant access with All Tasks/Manage Private Keys
But I don't have the option of All Tasks/Manage Private Keys
But I'm not clear on how to do that. But also, the service is running under my domain account, which is an administrator and is also the same user that installed the cert.
Please Help :)
Here's the best link that should help you get your self-hosted SSL WCF service to work with your own custom CA/certificates: SSL with Self-hosted WCF Service.
After you get it working from the guide above, you may want setup your service programatically to use the right certificate during installation-time.
I find that verifying my HTTP.SYS configuration with the HTTPCfgUI tool to be easier than via the command line httpcfg/netsh commands.
Next, if you still encounter errors, you can debug further using WCF Tracing. Additionally, you should turn on WCF Message Tracing as well. You can trace the .NET network stack too, if the WCF tracing doesn't provide enough information.
You can test if your certificate/CA pair on the service is working by hitting your service URL in a browser on another machine. It should first state that the certificate is invalid. Then, import the CA on the machine into the trusted root, and hit the service URL again. This time it should display the service description page as usual, with no warnings.
I think you are close. Here are some suggestions:
Make sure you are getting a private key attached to your certificate in the second step. You have to run the command in an elevated process -- even if you have Admin privileges, you have to, for example, right-click and "Run as Administrator" to start the command shell you use for this command. Otherwise, you won't get the private key into the localMachine store.
I would use -ss my and put the certificate (with private key) into the Personal store. Here I see this:
cc.ClientCredentials.ClientCertificate.SetCertificate(
StoreLocation.CurrentUser,
StoreName.My,
X509FindType.FindBySubjectName,
"contoso.com");
and so wherever you are pointing to in your equivalent, put the certificate there.
You don't need to import the private key of the CA cert (the first one you created). That's only kept around to sign more certificates with MakeCert. You will need a copy of that CA certificate (without the private key!) on the client that is connecting in, otherwise the client won't be able to validate the InternalWebService certificate.
You don't really need the CA certificate locally on the server machine, because it will only be needed by the client. But it doesn't hurt, and would be needed if anything on the server connects to the service locally. Also, it makes the InternalWebService certificate look good on the MMC snap-in. You can try with and without the CA in the Trusted Root store and you'll see what I mean. But in any case, I would not put the private key of the CA into the local computer store.
Check the private key permissions for InternalWebService from the MMC snap-in (right-click on the certificate, then Tasks, Manage Private Keys...) If you import under a different user account than the service runs under, then certainly it won't have access yet, and you have to go give it access. Otherwise the service will get the certificate, but it will appear that the certificate does not have a private key.
To summarize:
Run with Admin privileges to make sure the private key of InternalWebService is really getting into the certificate store. (You'll see a little key on the certificate in the MMC snap-in, and right-clicking on the certificate will have an option "Manage Private Keys..." which is not present if there is no private key attached.)
Put the InternalWebService in the place where you Web service is looking for it. I would guess "Personal" (a.k.a. "my") but you know where that is in your service config. Whether current user or local machine, look in your config.
Give access to the InternalWebService certificate private key.
Put the CA certificate -- without its private key -- under Trusted Root, and you'll need to put that on the client as well (or otherwise have the client accept an "untrusted certificate" at its end.)
Warning:
The signer certificate has expired.
I get the following when I try to sign with jarsigner, and the output jar doesn't get generated.
How do I renew my jar signature?
Are you using a self-signed certificate? If so, you just need to use keytool to generate a new certificate, then sign your jar using keysigner.
If you are using a third-party signed certificate (Verisign, Thawte, etc), you'll need to renew your key using their online system (usually the same place you got the original cert).