Quando você instala um certificado em um servidor Web, ele poderá ser utilizado por alguma aplicação (UI ou serviços) que é executada no mesmo. Ao vincular esse certificado através do binding de HTTPS no IIS, você poderá começar a fazer uso deste protocolo na sua aplicação. Agora, imagine que você tenha um certificado que foi emitido para um outro domínio, diferente daquele que você está utilizando. Por exemplo, veja que o certificado abaixo foi emitido para o "Dummy", diferente do meu domínio utilizado pela aplicação, que é localhost.

Ao tentar acessar através do navegador, uma mensagem de aviso será exibida, indicando que o certificado que ele está utilizando é duvidoso, já que foi emitido para um domínio diferente daquele que ele foi vinculado. A imagem abaixo mostra essa mensagem:

Quando o usuário é interrogado, ele poderá decidir se continua ou não acessando aquele site, algo simples de fazer quando trata-se de aplicações que permitem a interação do usuário. Podemos também hospedar serviços no IIS, sejam eles WCF ou ASP.NET Web Services (ASMX), expondo através de HTTPS. Depois deste serviço referenciado na aplicação cliente, ao executá-la, você poderá se deparar com uma exceção do tipo SecurityNegotiationException, com a seguinte mensagem: Could not establish trust relationship for the SSL/TLS secure channel with authority [Servidor].

Durante a execução da aplicação cliente, antes dela efetivamente consumir o serviço, o WCF pergunta se ele deve ou não confiar no certificado, e o comportamento padrão é não. É exatamente o que acontece quando acessado através do navegador. Como o serviço não é interativo, você precisa de alguma forma, verificar se deseja ou não confiar naquele certificado que está sendo utilizado. Se não pudermos alterar o certificado, de uma forma semelhante a que vimos aqui, podemos escrever um código que permita efetuar essa verificação em tempo de execução.

Para isso, fazemos o uso da classe estática ServicePointManager, que está no namespace System.Net. Essa classe é responsável por gerenciar as conexões com a internet. Essa classe fornece uma propriedade chamada ServerCertificateValidationCallback, que deverá apontar para um método que segue a assinatura imposta pelo delegate RemoteCertificateValidationCallback. Abaixo temos um exemplo da sua utilização:

ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;

A partir do momento que você configura esta propriedade, as requisições HTTPS que são realizadas, começam a ser verificadas pelo método vinculado. Repare que entre os parâmetros enviados para este método, um deles é o certificado que está sendo avaliado. E além disso, esse método deverá retornar um valor boleano, indicando se o certificado é ou não válido, de acordo com a regra que você especificar ali. É importante que você analise cuidadosamente antes de especificar isso no seu código, pois dessa forma, ele dará "bypass" em todos os certificados, independentemente se eles forem ou não válidos. Talvez isso é algo que seja legal em ambiente de desenvolvimento, mas em produção poderá representar uma vulnerabilidade de segurança.

O WCF fornece várias possibilidades para autenticar o cliente. Isso permitirá ao serviço somente possibilitar o acesso ao mesmo, se a autenticação do cliente for realizada com sucesso, independente do tipo de credencial e de como isso é avaliado. É muito comum quando falamos de autenticação, em pensar que somente isso acontecerá do lado do serviço.

Da mesma forma que o serviço precisa validar o cliente para conceder o acesso, o cliente também precisa validar o serviço, para saber se ele está enviando a mensagem para o local correto. Felizmente o WCF possibilita a autenticação mútua, ou seja, antes de efetivamente enviar a mensagem para o serviço, o cliente primeiramente fará algumas validações para determinar se o serviço para qual ele enviará a mensagem, é realmente quem ele diz ser.

Depois que o cliente inicia a comunicação com um endpoint e depois que o serviço o autentica, ele irá comparar a identidade do endpoint remoto com a identidade fornecida para o cliente durante a referência do mesmo, através do documento WSDL. Se os valores forem iguais, então o cliente assume que é o serviço correto. Isso irá proteger o cliente de possíveis ataques de phishing, evitando que o mesmo seja redirecionado para endpoints maliciosos.

Essa validação ocorre de forma transparente e dependerá de qual tipo de identidade é fornecida pelo serviço. Atualmente temos cinco possibilidades: Domain Name System (DNS), Certificate, Certificate Reference, RSA, UPN (User Principal Name) e SPN (Service Principal Name). O uso de cada um deles dependerá do cenário e dos requerimentos de segurança exigidos. Para saber mais detalhes sobre cada um deles, consulte este artigo.

Se você quiser interceptar esse processo, você poderá criar um “autenticador” customizado. Isso nos permitirá customizar como essa validação deverá ser realizada, ficando sob nossa responsabilidade determinar se o serviço para qual o cliente está tentando enviar a mensagem é válido ou não.

Para que isso seja possível, é necessário criarmos uma classe que herde da classe abstrata IdentityVerifier (namespace System.ServiceModel.Security) e implementar os métodos TryGetIdentity e CheckAccess. O primeiro deles, recebe um parâmetro de output do tipo EnpointIdentity que será populado, com um objeto que representa a identidade remota do serviço, retornando um valor boleano indicando se a identidade foi ou não criada. O segundo método, CheckAccess, é onde devemos efetivamente validar se a identidade do serviço é realmente válida. Esse método também retorna um valor boleano, só que neste caso, indicando se a identidade é válida ou não, de acordo com a regra que vamos customizar. O código abaixo ilustra a implementação desta classe:

public class ValidadorDeIdentidadeDoServico : IdentityVerifier
{
    public override bool CheckAccess(EndpointIdentity identity, AuthorizationContext authContext)
    {
        foreach (var set in authContext.ClaimSets)
        {
            foreach (var claim in set)
            {
                Console.WriteLine(claim.ClaimType);
                Console.WriteLine("\t{0}", claim.Resource);
            }
        }

        Console.WriteLine();
        return true;
    }

    public override bool TryGetIdentity(EndpointAddress reference,
        out EndpointIdentity identity)
    {
        return IdentityVerifier.CreateDefault().TryGetIdentity(reference, out identity);
    }
}

Depois dessa classe criada, precisamos acoplá-la na execução do proxy. Mas para isso, iremos precisar de um binding customizado. Através do método abaixo vamos efetuar essa configuração. Note que ele atribui a instância da classe ValidadorDeIdentidadeDoServico na propriedade IdentityVerifier, que será responsável pela validação do serviço.

public static Binding ConfigurarBinding()
{
    WSHttpBinding binding = new WSHttpBinding(SecurityMode.Message);
    binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
    binding.Security.Message.EstablishSecurityContext = true;

    BindingElementCollection elements = binding.CreateBindingElements();
    SymmetricSecurityBindingElement ssbe =
        (SymmetricSecurityBindingElement)elements.Find<SecurityBindingElement>();

    ssbe.LocalClientSettings.IdentityVerifier = new ValidadorDeIdentidadeDoServico();
    return new CustomBinding(elements);
}

Para finalizar, temos que configurar o proxy para, ao invés de utilizar a configuração padrão do arquivo de configuração, usar o binding customizado, onde definimos a classe que será responsável por efetuar a validação do serviço. O código abaixo ilustra como fazemos a vinculação do binding ao proxy:

using (ContratoClient p =
    new ContratoClient(ConfigurarBinding(),
    new EndpointAddress("http://localhost:2334/srv")))
{
    //…
}

Algumas funcionalidades de segurança do WCF exigem que se utilize certificados para proteger a mensagem. Eu tenho escrito sobre algumas dessas funcionalidades aqui e, no download do código fonte, o certificado não está junto com o projeto. Com isso, ao rodar a aplicação, voce receberá uma exceção dizendo que não foi possível localizar este certificado. Isso aconteceu recentemente com o artigo sobre customização de autenticação e autorização e que o leitor Marco Tulio apontou aqui.

Neste artigo específico, para que voce consiga rodá-lo, o primeiro passo é criar um certificado de testes a partir do utilitário makecert.exe que, por sua vez, vem juntamente com o SDK do .NET Framework. Para utilizá-lo, basta definir algumas configurações necessárias para a geração do certificado, algo como é mostrado abaixo:

C:\>makecert -sr LocalMachine -ss TrustedPeople -sky exchange -pe -a sha1 -n "CN=localhost" C:\localhost.cer

Observação: Para entender cada uma dessas opções que o utilitário fornece, consulte este artigo.

Depois do certificado criado, então nos resta configurá-lo para que o serviço possa fazer uso dele. Ao abrir o arquivo de configuração do host, efetue a mudança do certificado, apontando para este que foi recém criado. O código ficará semelhante ao qual é mostrado abaixo:

<serviceCredentials>
  <serviceCertificate
    findValue="localhost"
    storeLocation="LocalMachine"
    storeName="TrustedPeople"
    x509FindType="FindBySubjectName" />
    <!-- Outras Configurações -->
</serviceCredentials>

Depois disso, execute o host separadamente e atualize a referencia no projeto cliente para que a chave pública seja alterada.

Para finalizar, ainda falando do artigo que explora a customização da autenticação e autorização no WCF, é necessário alterar o path dos arquivos XML que estão dentro da classe/arquivo XmlSecurityHelper.

Os ASP.NET Web Services fornecem uma possibilidade de efetuar a autenticação do serviço através de SOAP Headers. Para isso, bastava criar uma classe que herde da classe SoapHeader e criar as propriedades UserName/Password e, via SoapHeaderAttribute, voce vinculava este header aos métodos que exigem a autenticação do usuário para poder funcionar.

Essa configuração funciona bem, mas é vulnerável. A questão é que o envelope SOAP irá trafegar entre o cliente e o serviço de forma desprotegida e, sendo assim, qualquer um que interceptar a requisição, conseguirá extrair essas informações confidenciais. A autenticação baseada em SOAP Headers apenas são seguras se o transporte garantir a segurança; em outras palavras, isso quer dizer HTTPS. Outra alternativa ainda utilizando os tradicionais ASP.NET Web Services, seria a utilização do WSE (Web Services Enhancements), que possibilita a segurança em nível de mensagens.

O WCF, que é seguro por padrão, tem um comportamento ligeiramente diferente em relação aos ASP.NET Web Services. Para utilizar a autenticação baseada em UserName/Password que o WCF fornece sob o protocolo HTTP, será necessário utilizar um certificado. Sem a utilização deste, não seria possível garantir a integridade e confidencialidade da mensagem, comprometendo as informações e, principalmente, permitindo que alguém intercepte a mensagem e capture os dados sigilosos. Assim como os ASP.NET Web Services, se o serviço WCF for exposto via HTTPS, isso não é necessário, mas utilizar segurança baseada em transporte tem seu ponto negativo: a segurança é apenas garantida ponto-a-ponto e, caso haja intermediários entre o cliente e o serviço, não temos a garantia de que a mensagem chegará segura até o destino.

Quando fazemos uma referencia a um serviço WCF, e ele possuir um certificado definido para assegurar a troca de informações entre o cliente o e serviço, a IDE do Visual Studio ou o utilitário svcutil.exe, adicionanão um elemento chamado identity/certificate com o atributo encodedValue. O valor deste atributo é uma série de letras e números mas, o que isso representa?

Essa informação trata-se da chave pública do certificado, codificada no padrão Base64. Ela será utilizada pelo runtime do WCF para criptografar as informações que serão trocadas, mais precisamente, as credenciais. Quando essa informação não existir no cliente, a configuração do serviço deverá permitir a negociação ou informar a referencia para o certificado que, geralmente, esta armazenado em um dos repositórios do cliente.

Por padrão, serviços WCF utilizam as identidades e grupos do Windows para autenticação e autorização, respectivamente. Um dos grandes problemas é quando temos isso sendo disponibilizado através de uma aplicação web, pois iria requerer que todos os clientes que acessam via web estivessem devidamente cadastrados dentro do Windows; além disso, há o problema com relação aos grupos de usuários, já que muitas vezes não temos acesso para cadastrá-los e, quando isso não é um problema, podemos ter um problema adicional quando estivermos rodando em culturas de servidores diferentes.

Com isso, dificilmente uma aplicação ou serviços que são expostos para a internet utilizam as contas e grupos do Windows. A solução é que felizmente o ASP.NET 2.0 fornece uma infraestrutura completa para o gerenciamento de autenticação e autorização, chamada de Provider Model. Ela nos dá uma enorme flexibilidade, onde podemos trocar a fonte de dados/persistência e a aplicação continua trabalhando normalmente. Este provider é um módulo do software que estamos desenvolvendo que fornece uma interface genérica para uma fonte de dados, onde abstraem a base de dados. Além disso ser flexível, a qualquer momento podemos trocar a base de dados (essa arquitetura também é extensível) ou seja, se mais tarde quisermos customizar algo, podemos fazer isso sem maiores problemas.

Com toda essa infraestrutura já bem desenhada e sendo utilizada largamente no mercado, a Microsoft decidiu, em uma das formas de segurança de serviços WCF, integrar com esse modelo disponibilizado pelo ASP.NET 2.0. Este artigo já assume que você tenha conhecimento suficiente nesta infraestrutura e, em alguns pontos, vamos falar de alguns detalhes mais superficialmente. Se você ainda não estiver a vontade nisso, eu aconselho extremamente ler o artigo Entendendo e Implementando Segurança no ASP.NET 2.0 antes de prosseguir.

O transporte da mensagem

Quando estamos em um cenário de internet, as mensagens são enviadas para o serviço através de puro HTTP, porém é extremamente importante proteger o corpo e as credenciais do usuário durante essa "viagem". A solução para isso é criptografar a mensagem para garantir a integridade e privacidade, utilizando a senha do usuário mas, mais uma vez por questões de segurança, o WCF não utiliza essa forma por ser vulnerável, pois o usuário pode ter uma senha pouco complexa e qualquer um que esteja monitorando a comunicação poderá interceptar e, conseqüentemente, "quebrar" a criptografia.

Para proteger a mensagem, o WCF utiliza um certificado do tipo X.509, que fornece uma proteção extremamente confiável. Este tipo de certificado também autentica unicamente o serviço para o cliente, trabalhando com duas chaves: uma pública e outra privada. Quando criptografamos algo com a chave pública, somente quem tiver a chave privada poderá decriptografar o seu conteúdo e, neste nosso cenário, o detentor da chave pública é o serviço WCF que, por sua vez, deverá manter a chave privada armazenada em algum local seguro para que a mesma não caia em mãos erradas.

A chave pública fica disponível no servidor que expõe o serviço e, sendo assim, qualquer cliente pode acessar os endpoints do serviço WCF e obter a chave pública. Como já sabemos, essa chave pública será utilizada pelo cliente para criptografar todas as mensagens que serão enviadas para o serviço que, por sua vez, quando receber a requisição, irá decriptografá-la utilizando a chave privada e utilizará as credenciais fornecidas pelo usuário para autenticá-lo e, conseqüentemente, permitir o acesso ao serviço.

Para o teste que vamos realizar no decorrer deste artigo, necessitamos de um certificado X.509 para utilizarmos durante a criação do serviço. Como não tenho nenhum certicado disponível, podemos criar um para testes. Para isso, utilizaremos um utilitário chamado Makecert.exe que é fornecido junto com o .NET Framework e pode ser encontrado no seguinte endereço: C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\. Este utilitário cria um par de chave pública e privada e armazena em um arquivo de certificado. Para criar o certificado, abra o prompt de comando do Visual Studio .NET 2005 (isso para evitar o path completo do utilitário) e digite:

makecert -sr LocalMachine -ss My -sky exchange -pe -a sha1 -n "CN=IACertificate" IACertificate.cer

Basicamente, através da linha acima, criamos um certificado chamado IACertificate e armazenamos ele em um arquivo chamado IACertificate.cer. Mas é importante dizer sobre cada um das opções que são passadas para o utilitário Makecert.exe, opções que são detalhadas através da tabela abaixo:

Observações: Se quiser uma lista completa de todas as opções fornecidas pelo utilitário Makecert.exe, consulte este link. Depois de criado o certificado, se desejar visualizá-lo, vá até a opção Run do Windows e digite: mmc; em seguida, vá até o menu File, Add/Remove Snap-in..., terá um botão chamado Add no fim da janela; ao clicar nele um novo formulário será apresentado e na listagem terá um item chamado Certificates que, ao selecioná-lo, abrirá um wizard onde você deverá, na primeira tela apresentada, selecionar a opção Computer account. Isso fará com que todos os certificados do seu computador sejam exibidos na console de administração. Ao navegar até Personal, Certificates, verá ali o certificado recém criado.

Como o nosso foco será disponibilizar isso através de uma aplicação que irá correr dentro do IIS, é necessário concedermos direitos de leitura a chave privada do certificado em questão para as contas dos worker process do IIS. Para isso, temos que seguir dois passos que são mostrados abaixo:

• Através do utilitário FindPrivateKey.exe, conseguimos identificar a chave privada, para que seja possível encontrá-la e, em seguida, conceder os direitos a mesma. Se não tiver o Microsoft SDK for .NET Framework 3.0 instalado, então voce pode baixar os exemplos de WCF da Microsoft que, dentro dele, existe um projeto chamado FindPrivateKey.sln, que é justamente o projeto que gera esse utilitário.

• Depois de encontrada a chave, voce pode conceder os direitos através do utilitário cacls.exe (como é mostrado neste post) ou via Windows Explorer, através da aba Security.

Criação do contrato e configuração da autorização

Neste momento, vamos nos concentrar na criação e configuração do serviço WCF. Mais uma vez, vou considerar como conhecimento prévio o procedimento para a criação de serviço básico de WCF, principalmente no que diz respeito aos atributos que devem ser aplicados aos tipos para torná-lo um serviço WCF. Para o exemplo, vamos criar um contrato padrão, chamado de IServiceContract, que será implementado pelos serviços concretos. Esse contrato (uma Interface) terá dois métodos simples, chamados de BoasVindas e HoraAtual. Essa Interface está exibida abaixo:

using System;
using System.ServiceModel;

namespace DevMinds.ComponentCS
{
    [ServiceContract]
    public interface IServiceContract
    {
        [OperationContract]
        string BoasVindas();

        [OperationContract]
        DateTime DataAtual();
    }
}

using System;
using System.Threading;
using System.Security.Permissions;
using DevMinds.ComponentCS;

public class DefaultService : IServiceContract
{
    [PrincipalPermission(SecurityAction.Demand, Role = "User")]
    public string BoasVindas()
    {
        return string.Format("Ola {0}!",
            Thread.CurrentPrincipal.Identity.Name);
    }

    [PrincipalPermission(SecurityAction.Demand, Role = "Manager")]
    public DateTime DataAtual()
    {
        return DateTime.Now;
    }
}

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <connectionStrings>
    <add
      name="SqlServerConnString"
      connectionString="Data Source=.;Initial Catalog=DBWCF;Integrated Security=SSPI;"
      providerName="System.Data.SqlClient"/>
  </connectionStrings>
  <system.serviceModel>
    <services>
      <service name="DefaultService" behaviorConfiguration="ServiceBehavior">
        <endpoint
          name="DevMindsEndpoint"
          contract="DevMinds.ComponentCS.IServiceContract"
          binding="wsHttpBinding"
          bindingConfiguration="ServiceBinding" />
      </service>
    </services>
    <bindings>
      <wsHttpBinding>
        <binding name="ServiceBinding">
          <security mode="Message">
            <message clientCredentialType="UserName" />
          </security>
        </binding>
      </wsHttpBinding>
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="ServiceBehavior">
          <serviceCredentials>
            <userNameAuthentication
                userNamePasswordValidationMode="MembershipProvider"
                membershipProviderName="SqlMembershipProvider"/>
            <serviceCertificate
                storeLocation="LocalMachine"
                storeName="My"
                x509FindType="FindBySubjectName"
                findValue="IACertificate" />
          </serviceCredentials>
          <serviceAuthorization
              principalPermissionMode="UseAspNetRoles"
              roleProviderName="SqlRoleProvider" />
          <serviceDebug includeExceptionDetailInFaults="true"/>
          <serviceMetadata httpGetEnabled="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
  <system.web>
    <membership
      defaultProvider="SqlMembershipProvider"
      userIsOnlineTimeWindow="15">
      <providers>
        <clear />
        <add
          name="SqlMembershipProvider"
          type="System.Web.Security.SqlMembershipProvider"
          connectionStringName="SqlServerConnString"
          applicationName="WCFApp" />
      </providers>
    </membership>
    <roleManager enabled="true" defaultProvider="SqlRoleProvider" >
      <providers>
        <add
          name ="SqlRoleProvider"
          type="System.Web.Security.SqlRoleProvider"
          connectionStringName="SqlServerConnString"
          applicationName="WCFApp"/>
      </providers>
    </roleManager>
  </system.web>
</configuration>

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <client>
      <endpoint
        name="DevMindsService"
        address="http://localhost:2969/DevMinds.WebHostingCS/DefaultService.svc"
        behaviorConfiguration="ClientBehavior"
        binding="wsHttpBinding"
        bindingConfiguration="ClientBinding"
        contract="DevMinds.ClientUICS.localhost.IServiceContract">
        <identity>
          <certificate
            encodedValue="AwAAAAEAAAAUAAAAUJNV9NaKKu1ufLDJSReysIhSHokgAAAAAQAAALkBAAAwgg
                          G1MIIBY6ADAgECAhD8doIP5AdsgEtkMqF7eimCMAkGBSsOAwIdBQAwFjEUMBIG
                          A1UEAxMLUm9vdCBBZ2VuY3kwHhcNMDcwNDAzMTMxNjM3WhcNMzkxMjMxMjM1OT
                          U5WjAYMRYwFAYDVQQDEw1JQUNlcnRpZmljYXRlMIGfMA0GCSqGSIb3DQEBAQUA
                          A4GNADCBiQKBgQC/+fgp/kuwIVmhpJW2XFDdFQKT0hDRhbdsIvV8ikrUANCuii
                          ufPvo10FqMrVPqeowy+c2XxYpQ6lGeMx4QWVeZC9LdGCzli1UNKdarT6wBiBsK
                          qAxmb6lJkKnkL4HycepYckbT2H65oIDDnfFNv1TYUP1/gPHoz6bsIFCa4eXCMw
                          IDAQABo0swSTBHBgNVHQEEQDA+gBAS5AktBh0dTwCNYSHcFmRjoRgwFjEUMBIG
                          A1UEAxMLUm9vdCBBZ2VuY3mCEAY3bACqAGSKEc+41KpcNfQwCQYFKw4DAh0FAA
                          NBAGoc8S3JfsoQPRqwCIO0WYopE8vJ92IYLkxQ5k68BuN1mLUftbVoEv/TO/Y5
                          7ToFWzTsDMT5BfG37G1Y0P5Iq+Q=" />
        </identity>
      </endpoint>
    </client>
    <bindings>
      <wsHttpBinding>
        <binding name="ClientBinding">
          <security mode="Message">
            <message clientCredentialType="UserName" />
          </security>
        </binding>
      </wsHttpBinding>
    </bindings>
    <behaviors>
      <endpointBehaviors>
        <behavior name="ClientBehavior">
          <clientCredentials>
            <serviceCertificate>
              <authentication certificateValidationMode="PeerTrust" />
            </serviceCertificate>
          </clientCredentials>
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

using (localhost.ServiceContractClient c = new localhost.ServiceContractClient())
{
    c.ClientCredentials.UserName.UserName = "Claudia";
    c.ClientCredentials.UserName.Password = "123456";
    MessageBox.Show(c.DataAtual().ToString());
    MessageBox.Show(c.BoasVindas());
}

Quando configuramos um certificado dentro de uma aplicação IIS, é necessário concedermos direitos de leitura a chave privada do certificado em questão para as contas dos worker process do IIS. Via Alexander Strauss eu encontrei a forma de fazer isso:

1. Através do utilitário FindPrivateKey, conseguimos identificar a chave privada, para que seja possível encontrá-la e, em seguida, conceder os direitos a mesma. Se não tiver o Microsoft SDK for .NET Framework 3.0 instalado, então voce pode baixar os exemplos de WCF da Microsoft que, dentro dele, existe um projeto chamado FindPrivateKey.sln, que é justamente o projeto que gera esse utilitário.
2. Depois de encontrado a chave, voce pode conceder os direitos através do utilitário cacls.exe (como é mostrado no post do Alexander) ou via Windows Explorer >> Security.

Geralmente, alguns possíveis erros que podem acontecer quando voce executa um serviço WCF e o worker process não tem permissão de leitura a uma determinada chave privada. Pude detectar dois deles:

• System.ArgumentException was unhandled Message="The certificate 'CN=Chave' must have a private key that is capable of key exchange.  The process must have access rights for the private key." Source="System.ServiceModel"
• CryptographicException: Keyset does not exist

É importante lembrar que se voce alterar as contas padrões no IIS para o worker process, é necessário conceder o direito de leitura a chave privada do certificado para o usuário ali determinado.

Hoje tive uma experiencia interessante, ou seja, um Windows Service que criei para automatizar alguns processos aqui na empresa utiliza as classes de HttpWebRequest e HttpWebResponse para enviar e recuperar dados de um serviço prestado por terceiros, que corre em cima de HTTPS, depois de migrado para um servidor Windows Server 2003, ao executá-lo e fazer uma requisição a este link seguro, o seguinte erro era retornado:

An unhandled exception of type 'System.Net.WebException' occurred in system.dll
Additional information: The underlying connection was closed: Could not establish trust relationship with remote server.

Fui então fazer alguns testes tentando acessar este mesmo link através do browser, e resultou com sucesso. Pude reparar que ao digitá-lo no browser, uma janela é aberta, perguntando ao usuário se ele quer ou não confiar no certificado digital que é fornecido pelo servidor que estamos tentando acessar. Com certeza optei por sim, e o retorno foi imediato. Mas a questão estava aí, ou seja, se a requisição é feita por um processo automático (Windows Service), que clicaria no botão? :P Nesse caso, criamos uma classe que implementa a interface ICertificatePolicy para gerir e autorizar que o certificado seja aceito. O código para isso é:

     Imports System.Net
     Public Class TrustAllCertificatePolicy

          Implements ICertificatePolicy

          Public Function CheckValidationResult(ByVal srvPoint As System.Net.ServicePoint, ByVal certificate As System.Security.Cryptography.X509Certificates.X509Certificate, ByVal request As System.Net.WebRequest, ByVal certificateProblem As Integer) As Boolean Implements System.Net.ICertificatePolicy.CheckValidationResult
               Return True
          End Function

     End Class

No código acima, através do método CheckValidationResult retornamos True para sempre aceitar e confiar neste certificado. Depois disso, antes de efetuar a requisição devemos definí-la na propriedade CertificatePolicy, como é exibido abaixo:

     System.Net.ServicePointManager.CertificatePolicy = New TrustAllCertificatePolicy

Para conseguir a encontrar essa solução, li o artigo do Jan Tielen, e pode ser visto aqui. Lembrando que isso também é valido para Web Services que rodam em ambiente seguro, como ele explica.