Develop Reference

Certificate issue using WCF with SSL

I'm trying to connect to a service that a 3rd party company is publishing. For the authentication part, we use two certificates, one with a public key and one with a private key.
I've made an console application just to test the certificates in differente stores, with the following possibilities:
Location: Current User; Store: Personal
Location: Local Machine; Store: Personal (installed with admin user. I don't have admin permissions)
It was working until I've changed my computer to another this week. I've tested on other machines and it's working on both configurations. But mine only works when I try the 'Current User Location'. Why? My application needs to use the 'Local Machine Location'.
The only possibility I can think about is some kind of permission. But I'm not finding any clue on web. All the similar links say something about the bindings, wrong certificates, overriding ServiceCallBack, etc.
Someone knows if any permission is needed to use the certificate from LocalMachine?
Obs: the application can find the certificate, but when it uses I got the following error:
Could not establish trust relationship for the SSL/TLS secure channel with authority 'name-of-certificate'
Note: I know there is other posts similar to this, but the problem/scenario is really different.

Possibly the identity of the application pool has to rights to read the private key of the certificate from the Local Machine store.
To add the permission, go to the Certificate snapin, right click the certificate, select All Tasks and Manage private keys. From there, add the application pool identity.
Also, as always, make sure that the application pool's "Load user profile" setting is set to true.

.net example of using client certificates in web service call?

I'd like to use client certificates to verify the identity of administrative callers to my web service. Then I can issue certificates only to the people I want to call my web service and be pretty sure noone else can call it. This is in a very controlled scenario where only one or two people will get the client certificate, so distribution isn't a hard problem.
This article provides a good example of how to call a web service using a client certificate.
But how can I check details of the client certificate from within my web service? This old article talks about configuring IIS to do it, but I'd like to do it programmatically within my app. I think?
thanks for any suggestions!

The incoming Request has a ClientCertificates collection that you can interrogate -- you can check the various fields in the cert or check the actual raw byte data (perhaps against a datastore or other source) if you want to completely validate it.
Note, if you issue the certs from your own private CA, you will need to install the CA's cert on your webserver into a store that is visible to all users, otherwise IIS won't request those certs from the user (due to the nature of how the server/client interaction works.)

How can I create a subdomain in asp.net?

How can I create a subdomain in an asp.net C# application? I am working with an asp.net portal. In that portal I need to be able to create the subdomain at runtime. The ftp for that subdomain also needs to be the same as the main domain ftp.

There are a handful of working parts here. It sounds like the requirement is that this all happen at runtime. I am sure a lot of web hosting providers are deep into these sets of problems and likely have custom solutions.
DNS: you'll need to have an API open at the DNS host. If it's a LAN environment, you'll have to check your DNS provider on whether they have APIs exposed. (i.e. Windows Server or whatever your network operating system is). If this is a public facing site that needs to be accessed via the internet, you'll have to get those APIs from the DNS registrar. Are the subdomains to be permanent?
IIS: You'll have to setup wildcard mapping, (i.e. *.mydomain.net). When an HTTP request comes in, logic within the ASP.NET page can determine the subdomain that you're working with. You could extract the subdomain, perform a lookup on that subdomain to get more information (CustomerID, names, valid visitor IP address ranges, whathaveyou).
FTP: if you require secure logins for that subdomain, you'd have to have created AD or local machine accounts for those users. If you want anonymous access, that's OK too. There are some scripting options that you'll have to look at to have that FTP folder setup as well. That is assuming you're using IIS's FTP module. If you are using a 3rd party FTP application, that complicates the scenario even further. Their APIs would have to be investigated.
Active Directory: If you are requiring secure access for each subdomain, you'll have to create AD users and/or groups. You can certainly script the creation of users into groups. Perhaps the users will be local to your web server. That doesn't scale well if you want to add another web server, but it's certainly do-able.

subdomain's are controlled by your dns settings. Beyond that I can't understand your question.

I think the best way is to have a wildcard DNS entry - i.e. *.domain.com that points to the domain. And then use a rewriting tool, like helicontech.com, to rewrite the 1st part of the subdomain to tell your app what you're looking at.
This would use regular expressions to pass the subdomain to your app:
RewriteCond Host: (mysub).domain.com
RewriteRule (.*) /$2?subdomain=$1 [I,L,U]

There are two halves to this:
A) Changing your DNS Settings:
This varies based on your host and whatnot. Contact them and ask if you can't figure it out.
B) Changing your host settings:
This varies based on your server. I assume you're using some version of IIS.
In IIS6, you can right click a web site, select the properties page, go to the web site tab, select advanced in web site identification, and start adding bindings (Generally you'll use default or the ip address for IP Address, 80 for TCP Port (unless SSL), and the site for the host header file (e.g. www.example.com or subdomain.example.com).
In IIS7, you right click on a website and select edit bindings, then click "Add". IIS7's add screen is pretty self explanatory.

I think he wants to created a subdomain from code, using an API probably that needs to be provided by his webhost folks. Like his own DNS manager app. If I interpreted your question wrong, then I guess you probably oughta reiterate a bit more.

Access files from network share in c# web app

I have a web application that needs to read (and possibly write) files from a network share. I was wondering what the best way to do this would be?
I can't give the network service or aspnet accounts access to the network share. I could possibly use impersonation.
The network share and the web application are both hosted on the same domain and I can create a new user on the domain specifically for this purpose however I'm not quite sure how to join the dots between creating the filestream and specifying the credentials to use in the web application.
Unfortunately the drive isn't mapped as a network drive on the machine, it's only available to me as a network share so unfortunately I can't make a transparent call.
There is one problem I can think of with impersonation... I can only impersonate one user per application domain I think but I'm happy to be corrected. I may need to write this file to several different shares which means I may have to impersonate several users.
I like the idea of creating a token... if I can do that I'll be able to ask the use up front for their credentials and then dynamically apply the security and give them meaningful error messages if access is denied... I'm off to play but I'll be back with an update.

Given everyone already has domain accounts. Try IIS integrated authentication. You will get an ugly logon box off network but your creds should pass down to the file share.
#lomaxx
Are you saying that only you have perms to the share or that you manually mapped it to a drive letter. If the later you can use ucn \host\share the same way you would use a c:\shared_folder.
Random
Would it be a burden to mirror the share to a local folder on the host? I hear ROBOCOPY is pretty handy.
Another Idea. Run IIS on your target share you can read via http and if you need to write investigate webdav.

I've had no problems connecting to network shares transparently as if they were local drives. The only issue you may have is what you mentioned: having the aspnet account gain access to the share. Impersonation is probably the best way to do this.
You should be able to use any filestream objects to access the network share as long as it has a drive letter on the server machine.

Impersonation worked well for me in this scenario. We had a wizard that uploaded a zip file through the website, but we load balanced the site. Therefore needed to setup a way to save the file on all the machines.
There are many different ways to do it. We decided to make all requests to run under the user we setup and just added the web.config entry and setup the security permissions on the folders for the user. This kb article explains the setup very well.

You do have some options and one of of those is impersonation as you mentioned. However, another one I like to use and have used in the past is a trusted service call. Let's assume for a moment that it's always much safer to limit access through IIS to ensure there are as few holes as possible. With that let's go down this road.
Build a WCF service that has a couple of entry points and the interface might look like this.
public interface IDocumentService
{
public string BuildTrustedRelationship(string privateKey);
public byte[] ReadFile(string token, string fileName);
public void WriteFile(string token, string fileName, byte[] file);
}
Now, you can host this service via a Windows service very easily and so now all you need to do is on Application_start build the relationship with the service to get your token and you're off to the races. The other nice thing here is that this service is internal, trusted, and I've even hosted it on the file server before and so it's much easier to grant permissions to this operation.

If you can create a new AD user, I think the simplest solution is to have the Application Pool run under that AD account's authority, which would mean your application is now running as the AD user. You would need to add the AD user to the IIS Worker Process Group on the machine running your application. Then as long as your AD user has write permissions on the network share, you should be able to use the UNC path in your file operations.

Other ways to encrypt WCF Connections

I'm currently working on a project that requires encrypted data be passed between WCF hosts. As I understand it there are only 2 ways to ensure that data passed over WCF is secure.
Using Certificates
Using a Domain (or having the same username and password on every machine on the network)
Using certificates can be expensive and complicated to manage and since we're not guaranteed to have a server class machine at every deployment a Domain is also out of the question. Having every machine use the same username and password is also problematic if that password ever needs to be changed.
Currently we use OpenSSH to tunnel our connections between hosts. Is there another option built into the framework that I'm unaware of?

Encryption requires a key. Keys are usually implemented as certificates. If you own both sides of the communication, you can create your own certificate for free without having to go buy one from a trusted root authority.

Here is an alternative. Works without IIS and SSL/X509 certificates.

If you are using a http endpoint, you can use a secure transport such as https.

Use traditional encryption of the data that you are placing inside the WCF container. Maybe something like the following:
http://www.obviex.com/samples/EncryptionWithSalt.aspx

The cheapest method is probably to run your own certification authority. This means you have total control over the certificates, but you do not have to pay for external certification. If you automate this appropriately, you can give every machine on your net a cryptographic identity and use your local certification to tie everything together.