I am having the same issue with client certificates that many people have reported, but none of the solutions I've seen have worked for me. I have a client I wrote in VB.Net (using VS 2010 and .Net framework 4.0) that needs to connect to a web service running on Apache Tomcat/5.0.27. It works fine with SSL when client certificates are not required, but as soon as client certificates are required, it fails with “THE REQUEST WAS ABORTED: COULD NOT CREATE SSL/TLS SECURE CHANNEL”
Testing it with Internet Explorer (8, 9 and 10, on XP and Win7x32), when SSL is enabled (configured on Tomcat by setting sslProtocol="TLS" secure="true" scheme="https" in the system.xml file), but client certificates are disabled (clientAuth="false"), IE is happy after the CA certificate and the server certificate are installed on the client PC. (IE will complain without the certificates, but you can tell it to ignore the warning. When the certificates are installed, it connects without any warnings.) When client certificates are required (clientAuth="true"), IE will not connect. After I import the client certificate file, it still does not connect. IE shows that the client file is installed, and it shows the certificate is ok and it trusts the CA, but it shows it in what seems to be the wrong store: Intermediate Certificate Authorities, and client authentication is not ticked under Purpose. The MMC certificates snap-in shows the client certificate is in the Personal - Current User store.
The certificate was issued to us by the owners of the web service, so in theory it has to work. The properties look ok, and the purpose shows "All application policies".
I need to get this to work with my .Net client. I use a Web Reference to create the connection to the web service. I set PreaAuthenticate=True, and attach the certificate file to the web reference, and can see it attached in the IDE. Using Network Monitor, I can see that the server sends certificates to the client (in two large packets), but the client doesn't seem to send any back to the server.
I have tried various recommendations, e.g. setting ServicePointManager.Expect100Continue = true and
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3, but this makes no difference.
I have disabled firewalls and proxy servers, so nothing should be blocking the traffic.
I'd appreciate any help.
Ok, it turns out there is a problem with the certificate they supplied, or it is somehow incompatible with the client. I found instructions on using OpenSsl to create a certificate, and it works with their server. They used java's keytool to make the certificate, so either it creates an incompatible certificate, or they didn't use the right procedure, and the procedure I used with OpenSsl is the correct one.
The steps in OpenSsl are to create a private key file (client.key), create a certificate request (client.req), sign the key (client.pem) then export it (client.pfx).
Related
We're not using Kestrel, nor IIS Express. We use IIS for local development. Thus we can't find out any command of dotnet dev-certs to help us.
We can create a self-signed certificate in IIS by going into server node, then Server Certificates, then Create a self-signed certificate, and give it a name and either Personal or Web Hosting, and it's created. Then use it in binding of our site (443, https, choosing certificate and domain.local)
However, when we want to go to domain.local in Google Chrome we get that untrusted certificate warning.
We can export certificate in IIS and double click it to install it in Windows. Now the error we see in Chrome is that this certificate is created for LocalComputerName and can't be used for domain.local.
At this point we're stuck at how to specify domains (Subject Alternative Names or SAN) for self-signed certificates, and how to automate this process from command line.
Any help?
I'm adding Google reCaptcha v3 to my J2EE application that runs under WebSphere 6.1. (I know, its no longer supported. A software upgrade is on the plan, just not immediately.)
I've followed the steps below to add the www.google.com:443 cert to WebSphere's NodeDefaultTrustStore, and after restarting WebSphere, the SSL cert is accepted no problem. My servlet code that does the reCaptcha verify logic works fine and all is well.
However, the following day, the certificate I imported is no longer accepted. When I import it again, I see that the Fingerprint (SHA digest) is different than the previous day. It looks like Google changes their SSL cert on a daily basis. Is this true? If so, how do I get around this problem in WebSphere?
CWPKI0428I: The signer might need to be added to the local trust store.
You can use the Retrieve from port option in the administrative console to retrieve the certificate and resolve the problem.
If you determine that the request is trusted, complete the following steps:
Log into the administrative console.
Expand Security and click SSL certificate and key management.
Under Configuration settings, click Manage endpoint security configurations.
Select the appropriate outbound configuration to get to the (cell):ServerNode01Cell:(node):ServerNode01 management scope.
Under Related Items, click Key stores and certificates and click the NodeDefaultTrustStore key store.
Under Additional Properties, click Signer certificates and Retrieve From Port.
In the Host field, enter www.google.com in the host name field, enter 443 in the Port field, and www.google.com_cert in the Alias field.
Click Retrieve Signer Information.
Verify that the certificate information is for a certificate that you can trust.
Click Apply and Save.
"Retrieve from port" adds the leaf certificate. To do something more reliable, trust the issuer. The current issuer for is GlobalSign root CA R2 which you can grab from https://pki.goog/ (GS Root R2)
Unfortunately it is hard to automate grabbing the root CA in tools like "retrieve from port" because many SSL toolkits do not send the root CA over the wire during the handshake -- because the client should already have it.
Here's an approach for WebSphere Liberty that might work for 6.1, I haven't tried it.
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_add_trust_cert.html
Use the openssl method but take the -second- certificate in the list (which doesn't expire until 2021).
So, I have a wildcard SSL cert from Go Daddy, and it has been installed on a few servers. However, on one particular server I cannot seem to get this thing done. Here's the process that has worked on all servers but this one:
1. Create CSR
2. Having gotten the certificate from the provider, I open the MMC certificates snap-in and import the intermediate cert to the intermediate authority store (or personal store, both have been tried). This is successful, in that I can view the certificate from the MMC
3. Go to the IIS server and under Server Certificates, I complete the CSR, point to the provided certificate and it imports into the web server successfully.
4. I go to an individual web site to assign the certificate to the web site under binding. When I select https and the IP address, the drop-down menu activates, but the certificate I just installed is not available for choosing.
5. I go back to the server Certificates, and the cert I just viewed is no longer there.
Go Daddy says to rekey, however, this makes no sense, since immediately prior to this, I installed that same wildcard cert to a different server, and it works fine. Obviously, this is something with IIS or Windows on this particular server.
Does anyone have any idea how to fix this without rekeying? Server platform is Windows 2008R2, IIS 7.5
If you have followed steps described in https://www.godaddy.com/help/iis-7-install-a-certificate-4801 then from your side it's done. And for more references, you can also check out this https://stackoverflow.com/a/43247419/7738413
Otherwise, rekeying is the last option.
I am dabbling with WCF and SSL and have hit a bit of a problem.
I have a self-hosted WCF service and a basic client which connects to request a token.
I have it set up on my development machine it appears to communicating over SSL just fine.
But when I set it up on a different machine to test the deployment the client keeps getting nothing back from the service.
I assume it has something to do with the certificates I have set up as this is the only thing I think could be different.
I have used the netsh command to associate my port with an existing certificate that was already on the server. And it appears the same as my dev machine (where I created the certificate with makecert manually.
I initially tried to follow the same steps on the deployment server but failed as there was already a certificate with a common name of the server, so eve though the certificate generated when ever I tried to use the cert hash thumbprint of the newly generated certificate I was being given the :
SSL Certificate add failed, Error: 1312
A specified logon session does not exist...
The only way I could get the netsh http add to work was by specifying the cert hash of the existing certificate.
Is this my problem or a red herring? How do you debug issues like this?
Personally I just configure WCF tracing. It usually provides more user friendly info about a problem. Here's a how to link Configuring Tracing
Hope it helps!
Background:
I am updating an internal application to a two-step authentication process. I want to add a client certificate authentication process (via a smart card) on top of a traditional username/password form. The application is written in C#, hosted on IIS7, and targeting Chrome and IE8.
Problem:
I am having issues with getting the application to prompt the user for a client certificate. I have been debugging the application with the help of Fiddler. When I have a test client certificate saved in Fiddler's user's directory (C:\Documents and Settings\USER\My Documents\Fiddler2), the application works as expected. I am prompted for a PIN number protecting the smart card, and, when entered correctly, takes me to the login form. When I close Fiddler, the application throws a 403 Forbidden error instead (since Fiddler is no longer running and pointing to its certificate). What I haven't been able to figure out is why the application won't prompt for a certificate normally.
Current Server Setup:
Self Signed Certificate was created
443 Binding is pointing at Self Signed Certificate
Anonymous Authentication is Enabled
The Self Signed Certificate was added to both the Trusted Root CA and Intermediate CA (I read that another person had it in both rather than just the Trusted Root CA and that solved their issue, though neither set up has worked for us).
I cleared out the rest of the certificates in the Trusted Root CA that I didn't need (I read elsewhere that having too many certificates would cause SSL to choke).
I am out of ideas to try other than starting from scratch on another server. Does anyone know what the issue might be? This seems like it should be fairly straight forward and that I'm missing something minor. Any ideas are welcomed.
Update:
After spending more time with this issue today, I strongly believe it has to do with IIS7 not being configured correctly (I did not set up it originally). I think this because I enabled Failed Request Tracing, looked at the subsequent .xml files being generated, and saw that a 500 error was being thrown.
Chrome is throwing a "Access to the webpage was denied" message rather than a "403 - Forbidden: Access is denied". I don't know if this helps. I do know that when I do not make certificates required, the site will work as intended. Requiring a certificate is where it fails.
The Application Pool is set to .Net 4.0 | Classic | Network Service.
Your problem is that the browser doesn't either get the request to provide client certificate or there is a security related option to block it from happening. IE offers certificate only if the web site is in correct zone (intranet or trusted sites). Please check this before everything.
If that doesn't help then see this answer for next step. The netsh documentation says:
clientcertnegotiation
Optional. Specifies whether the negotiation of certificate is enabled or disabled. Default is disabled.
Enable that and even the dumbest browser should notice that it is supposed to offer certificate for authentication. To diagnose your problem further you can use WireShark to see the negotiation in action.
In every browser I've seen, the browser will not prompt you to select a certificate if it does not have any certificates signed by a CA the server trusts. So make sure your server is configured with the correct CAs. As Boklucius suggested, you can use openssl to examine the list of trusted CAs your server is sending to clients and see whether the CA you have signed your client certificates with is among them.
Try openssl s_client -connect yourip:443 -prexit
And see if the CA (your self signed cert) is send to the client in the Acceptable client certificate CA names.
you need to install openssl first if you don't have it
I'll throw in a "try restarting the browser" suggestion, particularly if you installed the certificate while the browser was running.
To add a rather painful lesson to the mix: Make sure you quit Skype (or any other application) that eats port 443.
So the idea here is if you are running a dev environment on the same machine (both client and IIS), and your team uses Skype or some other app to communicate.
Watch the hours go by as you try and debug this problem, seemingly doing everything "right", netsh http sslcerts and such, even rebooting but to no avail. Well, turns out Skype will eat 443 so turn it off and "poof" there goes your certificate prompt.
Then feel free to throw things at the wall, shout obscenities or just "Rage, rage against the dying of the light".
Also, make sure Fiddler isn't getting in the way. If you have it decrypting the SSL, it'll corrupt the message back to IE, and it doesn't have the certificate installed, so it can't offer it. Turn off fiddler, and voila, the certificate prompt appears.
In Firefox, if you press 'Cancel' the first time you're prompted for a certificate, and you left the sneaky 'Remember this decision' box checked, then Firefox will remember that and never offer it again.
You can view and delete your previous remembered decisions in Firefox Preferences -> Privacy & Security (about:preferences#privacy), View Certificates, and check the Authentication Decisions tab.
Just connecting to my VPN and trying showed me the certificate prompt. Needs to be done only the first time.