I'm contacting a web service using a certificate stored in Machine and in user space "myUser".
When I contact the web service impersonating "myUser" from a win application all works well.
But when I contact this using Sharepoint context (I have only 1 frontend) I have only sometimes the following error:
Could not establish trust relationship
for the SSL/TLS secure channel with
authority 'server.host:4443'
I verified that the web service is invoked using user "myUser" as expected but in Sharepoint context sometimes this method crashes.
I don't know what can be the problem. It seems related to Sharepoint/ASP.NET security context but all seems to be ok. Any suggestion?
I think that the only sometimes is the important point here.
Since it works most of the time it is actually setup and configured ok.
The machine that you are sending the certificate to must be able to validate the certificate. My guess is that something is going wrong sometimes. Things that could cause this are:
a network problem, firewall ...
AD server down (I am assuming a self issued certificate)
AD server too busy
Check the event logs of your AD and Sharepoint server.
Have you granted access to the certificate for the asp.net worker process under which SharePoint is running?
In Windows 2008, you need to open the certificates mmc (Start -> Run -> MMC -> File -> Add/Remove SnapIn -> Certificates. Be sure to select "Computer Account" when prompted for how certificates will be managed. Locate the certificate, right-click on it, select "All Tasks". There should be an option in there that allows you to manage permissions to the certificate. You will need to grant read access to the account under which the application pool for SharePoint is running.
Note: if you are running Windows Server 2003, you will need to use winhttpcertcfg.exe to configure certificate permissions.
Try this:
System.Net.ServicePointManager.ServerCertificateValidationCallback = ((sender, certificate, chain, sslPolicyErrors) => true);
Before you make any calls.
Related
I am having problems correctly installing the OAuth certificate required for Xero partner integration on IIS 7.5 on Windows Server 2008 R2. There used to be guidance from Xero on this at http://developer.xero.com/documentation/advanced-docs/using-partner-applications-with-iis/ but the page just 404s now.
I've installed the certificate to the Trusted Root Certifications Store as per the prior Xero advice, and my code can retrieve the certificate (using its serial number); but when I try to access the private key, I get a CryptographicException: Keyset does not exist error, which other SO posts suggest is a permissions error (my application runs under a dedicated service account), but all those posts assume the certificate is installed in the personal certificate store - the TRC store does not give me the option of granting permissions to the service accounts or any other account.
I think that page used to give information about installing an Entrust client certificate as partner applications in the past needed to use one.
You don't need to use a client certificate these days and partners should instead direct their traffic to "https://api.xero.com" instead of "https://api-partner.network.xero.com".
You also don't need to install your oAuth certificate as that certificate is used only for signing your requests.
I'm adding support for JWT tokens in my Web Application, and I have an X509 certificate which it needs for signing those tokens.
I have rejected the idea of using the same certificate we use for HTTPs (see Can I use the Private Key Certificate of Web App to sign JWT?).
I think a self signed certificate should do the trick, in fact I can't see any advantages of a web of trust in this scenario (that doesn't mean there aren't any, I just can't think of any).
The web application runs on a farm of web servers. My current plan is to generate a self signed cert and put the X509 certificate into the certificate store in Windows on each machine. Our IT department are checking, but they think they can roll that out to all the Web Servers in the farm using Group Policy. So this seems like a feasible plan.
The certificate store in windows looks pretty confusing to me. I think there are two options:
1) Put it in "My" store for the user under which the IIS App pool run. There are many app pools, so potentially the certificate will be in many stores.
2) Put it under the LocalMachine store, and then grant explicit access to the specific certificate for the IIS user(s).
3) Something else I can't think of.
Is there a "correct" place for these type of certs, and if so where is it?
The usual CertificateStore for signing certificates is the My store. I normally place them in LocalMachine location, but it is probably safer to put them in the certificate store for the Application Pool identity itself.
I would then give the Application Pool read-only access to this certificate only (right click certificate, then 'All Tasks' > 'Manage Private Keys', then add your Application Pool identity and give 'Read' permissions only.
I'm setting up a server so that only mapped certificates can get to the webservice. It is set to require SSL/Client certificates, anonymous authentication, asp.net impersonation, forms authentication, and windows authentication are all disabled. One-to-one client certificate mapping is enabled, and certs are set up on the box with an appropriate user mapping. When I try to use the webservice, I get 401.2. If I enable anonymous authentication, it works, but I don't want any old cert to be able to access the website.
I have another machine that has anonymous authentication disabled in this configuration, and it works. I'm not sure what the difference is.
I ran into the same problem, but the solution above did not solve my problem. I was configuring IIS Certificate Authentication on a subdirectory of the website, not on the website itself.
So, this is wrong:
And this is correct:
Once I moved the configuration to the root of the website, everything worked perfectly.
I found the solution at http://blogs.msdn.com/b/saurabh_singh/archive/2009/06/13/avoid-this-confusion-around-client-certificate-mapping-in-iis-6-0-7-0.aspx.
Did you issue your client certs from a Certificate Server that the clients/server trust? If you look at the "Enhanced Key Usage" property on the certificates, is "Client Authentication" one of it's properties? In IIS, is the client certificate mapping role installed (see image 1)? did you enable "Client Certificate Mapping" and map the users to the certificate? You need to import all of the client certificates and map them to user accounts here. You can remove all of the other client authentication methods when you have configured that here.
The problem ended up being the software that was calling in, not in the configuration. I'm awarding natemrice the bounty since he put in a good effort to answer what ended up being a non-question.
edit: For more information, it actually ended up being a mismatch between the cert being sent (from the local box) and the cert that was put in the oneToOne mappings. The common name was the same, but the certs were different (likely the first one expired) so the cert simply wasn't authorized.
I'm trying to create a WCF application hosted in IIS. This WCF App will call a third party website to download a CSV file. Third party website has provided a certificate to authenticate the WCF call. My development environment is,
-OS: Windows 2008R2
-Tools: Visual Studio 2010 (.Net 4.x)
During development I've no problem to make the calls using a HttpWebRequest, but after I deploy the same thing in IIS, it gives me the following error, even if I run the Visual Studio 2010 using IIS as dev server,
"\r\nCertificate information doesn't match login, connection denied."
The certificate during installation requires a password. I've installed it in "My User account" and "Computer account". It is also installed in IE. In all the installation it is installed in "Trusted Root Certification Authorities". But, still I'm getting the error message. I've given my code snippet below,
X509Certificate2 xc = new X509Certificate2(CertPath, GetCertificatePassword());
HttpWebRequest wc = (HttpWebRequest)WebRequest.Create(QryUrl);
wc.ClientCertificates.Add(xc);
Stream str = wc.GetResponse().GetResponseStream();
If someone can provide me any information, would be nice, thanks again,
This is just a guess: check that the user account that IIS runs under has access to the private key associated with the certificate.
If you use the MMC Certificates snap-in, select the certificate and then right-click -> All Tasks -> Manage Private Keys, and from there if you don't see the user account of IIS listed, you can add it there by clicking Add, and then in the dialog that comes up if for example you run IIS as Network Service, type "network service" (with the space) and click Check Names and then when you are back to Manage Private Keys you can set the security access.
I believe you only need to allow Read access to use the private key for a TLS connection.
You can set the access to the private key whether installed in Local Computer or Current User, but IIS won't have access to your Current User unless it runs as your user account.
Also, if it is a client certificate with a private key it almost certainly should go in the Personal store, and not in Trusted Root Certification Authorities. So try Local Computer, Personal, and give access to the private key to the account that IIS (or the application) runs under.
Looking for some advice about the use of client certs to retro-fit access control to an existing app.
Our company has an existing intranet app (classic ASP/IIS) which we licence to others. Up till now it's been hosted within each organisation that used it and the security consisted of "if you're able to access the intranet you're able the access the application".
I'm now looking for a way to host this app externally so that other organisations who don't wish to host it themselves can use it (each new client would have their own installation).
All user in the new organisation would have a client cert so what I'd like to do is use the 'Require Client Certificate' stuff in IIS. It allows you to say "if Organisation=BigClientX then pretend they're local userY".
What I would prefer is something that says "if Organisation=BigClientX then let them access resources in virtualdirectoryZ otherwise ignore them".
I would be very happy to buy an addon (perhaps an ISAPI filter ?) which would do this for me if that was the best approach. Any advice / war stories would be welcomed.
You likely want to do this. client certs are really intended for a second factor of authentication, but not the primary source. To say it differently, you still need to configure your app for basic or forms authentication.
The technology behind public/private keys is rock solid. However, you need a very mature IT organization who is dealing with certificate lifecycle management. If you do not have this, you will get untold failure scenarios because the certificate was expired, wasn't copied to the new computer, etc.
This is especially true in your scenario where your application is internet facing (in thee 'hosted' scenario) - you have little control about the issuance of the certificates to your users.
I've done something similar...
Generate the certificates internally from your org's domain controller. Export them both as PFX format for distribution, and CER format for you to import in IIS.
Distribute the PFX format exports along with the CA certificate for your DC, so your customers machines will "trust" your CA.
Now in the app properties IIS, go to the Directory Security tab, and under "Secure Communications" click "Edit". In there, click "Accept client certificates", "Enable Client Certificate Mapping", then "Edit".
Under the 1-to-1 tab, click "Add" and import the CER file. Enter the account you'd like to map this certificate to.
As for the "let them access resources" I'd advise doing that by the user account they're mapped through - that is, you can provide access to resources based on that account either through NTFS permissions, or through code by identifying the security context of the logged-in user.