Este artigo foi traduzido por máquina. Para visualizar o arquivo em inglês, marque a caixa de seleção Inglês. Você também pode exibir o texto Em inglês em uma janela pop-up, movendo o ponteiro do mouse sobre o texto.
Tradução
Inglês

Trabalhando com certificados

.NET Framework (current version)
 

Para programar a segurança do Windows Communication Foundation (WCF), os certificados digitais X.509 são normalmente usados para autenticar clientes e servidores, criptografar e assinar mensagens digitalmente. Este tópico explica rapidamente os recursos do certificado digital X.509 e como usá-los no WCF, e inclui links para tópicos que explicam esses conceitos ainda mais ou que mostram como realizar tarefas comuns usando o WCF e certificados.

Em resumo, um certificado digital faz parte de uma infraestrutura de chave pública (PKI), que é um sistema de certificados digitais, autoridades de certificado e outras autoridades de registro que realizam e autenticam a validade de cada parte envolvida em uma transação eletrônica com o uso de criptografia de chave pública. Uma autoridade de certificação emite certificados e cada certificado tem um conjunto de campos que contêm dados, como assunto (a entidade para a qual o certificado é emitido), as datas de validade (quando o certificado é válido), o emissor (a entidade que emitiu o certificado) e uma chave pública. No WCF, cada uma dessas propriedades é processada como um Claim e cada afirmação é dividida ainda mais em dois tipos: identidade e direito.Para obter mais informações sobre Consulte certificados x. 509 certificados de chave pública x. 509Para obter mais informações sobre declarações e autorização no WCF consulte Gerenciamento de declarações e autorizações com o modelo de identidade.Para obter mais informações sobre implementação de uma PKI, consulte Windows Server 2008 R2 - serviços de certificados.

Uma função principal do certificado é autenticar a identidade do proprietário do certificado para outros. Um certificado contém a chave pública do proprietário, enquanto que o proprietário detém a chave particular. A chave pública pode ser usada para criptografar as mensagens enviadas para o proprietário do certificado. Somente o proprietário tem acesso à chave privada; portanto, somente o proprietário pode descriptografar essas mensagens.

Os certificados devem ser emitidos por uma autoridade de certificação, que é normalmente um distribuidor de certificados de terceiros. Em um domínio do Windows, uma autoridade de certificação é incluída e pode ser usada para emitir certificados para computadores no domínio.

Para trabalhar com certificados, geralmente é necessário exibi-los e examinar suas propriedades. Isso é feito facilmente com a ferramenta de snap-in do Console de Gerenciamento Microsoft (MMC).Para saber mais, vejaComo exibir certificados com o snap-in do MMC.

Os certificados estão localizados em repositórios. Dois grandes repositórios de certificado existem e são divididos em sub-repositórios. Se você for o administrador em um computador, poderá exibir os dois principais repositórios usando a ferramenta do snap-in do MMC. Os não administradores podem exibir somente o repositório do usuário atual.

  • O repositório do computador local. Ele contém os certificados acessados por processos do computador, como ASP.NET. Use este local para armazenar os certificados que autenticam o servidor para clientes.

  • O repositório do usuário atual. Os aplicativos interativos geralmente colocam certificados aqui para o usuário atual do computador. Se você estiver criando um aplicativo cliente, aqui é onde você normalmente coloca os certificados que autenticam um usuário para um serviço.

Esses dois repositórios são divididos em sub-repositórios. O mais importante deles ao programar com o WCF inclui:

  • Autoridades de Certificação Confiáveis. Você pode usar os certificados nesse repositório para criar uma cadeia de certificados, que podem ser rastreados para um certificado de autoridade de certificação nesse repositório.

    System_CAPS_importantImportante

    O computador local implicitamente confia em qualquer certificado colocado nesse repositório, mesmo se o certificado não vier de uma autoridade de certificação de terceiros confiável. Por esse motivo, não coloque nenhum certificado nesse repositório a menos que você confie totalmente no emissor e entenda as consequências.

  • Pessoal. Esse repositório é usado para os certificados associados com um usuário de um computador. Geralmente, esse repositório é usado para os certificados emitidos por um dos certificados da autoridade de certificação localizados no repositório Autoridades de Certificação Confiáveis. Como alternativa, um certificado localizado aqui pode ser emitido por conta própria e confiável por um aplicativo.

Para obter mais informações sobre armazenamentos de certificados, consulte armazenamentos de certificados.

Selecionar onde armazenar um certificado depende de como e quando o serviço ou o cliente é executado. As seguintes regras gerais se aplicam:

  • Se o serviço WCF está hospedado em um serviço do Windows, use o repositório computador local. Observe que os privilégios de administrador são necessários para instalar certificados no repositório do computador local.

  • Se o serviço ou cliente é um aplicativo executado em uma conta de usuário, use o repositório usuário atual.

Os repositórios são protegidos por listas de controle de acesso (ACLs), como pastas em um computador. Ao criar um serviço hospedado pelos Serviços de Informações da Internet (IIS), o processo do ASP.NET é executado sob a conta do ASP.NET. Essa conta deve ter acesso ao repositório que contém os certificados que um serviço usa. Cada um dos principais repositórios é protegido por uma lista de acesso padrão, mas as listas podem ser modificadas. Se você criar uma função separada para acessar um repositório, deverá conceder permissão de acesso a essa função. Para saber como modificar a lista de acesso usando a ferramenta WinHttpCertConfig.exe, consulte Como criar certificados temporários para uso durante o desenvolvimento.Para obter mais informações sobre usando certificados de cliente com o IIS, consulte como chamar um serviço Web usando um certificado de cliente para autenticação em um aplicativo Web ASP.NET.

Os certificados são criados em uma hierarquia onde cada certificado individual está vinculado à CA que emitiu o certificado. Este é o link para o certificado da CA. O certificado da CA em seguida vincula à CA que emitiu o certificado da CA original. Esse processo é repetido até que o certificado da CA seja alcançado. O certificado da CA é inerentemente de confiança.

Os certificados digitais são usados para autenticar uma entidade confiando nessa hierarquia, também chamado de cadeia de confiança. Você pode exibir a cadeia de qualquer certificado usando o snap-in do MMC clicando duas vezes no certificado e, em seguida, clicando na guia Caminho do Certificado.Para obter mais informações sobre importar cadeias de certificado para uma autoridade de certificação, consulte Como especificar a cadeia de certificados da autoridade de certificação utilizada para verificar assinaturas (WCF).

System_CAPS_noteObservação

Qualquer emissor pode ser designado uma autoridade confiável colocando o certificado do emissor no repositório de certificados da autoridade confiável.

Ao criar um novo serviço, você pode usar um certificado que não seja emitido por um certificado raiz confiável ou o próprio certificado de emissão pode não estar no repositório das Autoridades de Certificação Confiáveis. Somente para a finalidade de desenvolvimento, você pode desativar temporariamente o mecanismo que verifica a cadeia de confiança para um certificado. Para fazer isso, defina a propriedade CertificateValidationMode para PeerTrust ou PeerOrChainTrust. Qualquer um dos modos especifica que o certificado pode ser emitido por conta própria (confiança de par) ou parte de uma cadeia de confiança. Você pode definir a propriedade em qualquer uma das seguintes classes.

CLASS

Propriedade

X509ClientCertificateAuthentication

X509ClientCertificateAuthentication.CertificateValidationMode

X509PeerCertificateAuthentication

X509PeerCertificateAuthentication.CertificateValidationMode

X509ServiceCertificateAuthentication

X509ServiceCertificateAuthentication.CertificateValidationMode

IssuedTokenServiceCredential

IssuedTokenServiceCredential.CertificateValidationMode

Também é possível definir a propriedade usando configuração. Os seguintes elementos são usados para especificar o modo de validação:

A propriedade CertificateValidationMode também permite que você personalize como os certificados são autenticados. Por padrão, o nível é definido como ChainTrust. Para usar o valor Custom, você também deverá definir o atributo CustomCertificateValidatorType para um assembly e um tipo usados para validar o certificado. Para criar um validador personalizado, você deverá herdar da classe abstrata X509CertificateValidator.

Ao criar um autenticador personalizado, o método mais importante para substituição é o método Validate. Para obter um exemplo de autenticação personalizada, consulte o exemplo Validador de certificado X.509.Para saber mais, vejaCredencial personalizada e validação de credencial.

A ferramenta de criação de certificado (Makecert.exe) cria certificados X.509 e pares de chave privada/chave pública. Você pode salvar a chave privada no disco e, em seguida, usá-la para emitir e assinar novos certificados, simulando uma hierarquia de certificados encadeados. A ferramenta é destinada para uso somente como uma ajuda ao desenvolver serviços e nunca deve ser usada para criar certificados para implantação real. Ao desenvolver um serviço do WCF, use as seguintes etapas para criar uma cadeia de confiança com Makecert.exe.

Para criar uma cadeia de confiança com Makecert.exe

  1. Crie um certificado temporário de autoridade (autoassinado) usando a ferramenta MakeCert.exe. Salve a chave privada no disco.

  2. Use o novo certificado para emitir outro certificado que contém a chave pública.

  3. Importe o certificado de autoridade no repositório de Autoridades de Certificação Confiáveis.

  4. Para obter instruções passo a passo, consulte Como criar certificados temporários para uso durante o desenvolvimento.

As perguntas comuns sobre certificados são qual certificado usar e por quê. A resposta depende de se você está programando um cliente ou serviço. As informações a seguir fornecem uma orientação geral e não são uma resposta completa a essas perguntas.

Os certificados de serviço têm a tarefa principal de autenticar o servidor para clientes. Uma das verificações iniciais quando um cliente autentica um servidor é comparar o valor do campo Assunto para o Uniform Resource Identifier (URI) usado para contatar o serviço: o DNS de ambos deve coincidir. Por exemplo, se a URL do serviço for “http://www.contoso.com/endpoint/”, o campo Assunto também deverá conter o valor “www.contoso.com”.

Observe que o campo pode conter vários valores, cada um prefixado com uma inicialização para indicar o valor. Mais comumente, a inicialização é “CN” para o nome comum, por exemplo, "CN = www.contoso.com". Também é possível para o campo Assunto ficar em branco. Nesse caso, o campo Nome Alternativo da Entidade pode conter o valor Nome DNS.

Observe também que o valor do campo Finalidades do certificado deve incluir um valor apropriado, como “Autenticação do servidor” ou “Autenticação do cliente”.

Os certificados de cliente não são normalmente emitidos por uma autoridade de certificação de terceiros. Em vez disso, o repositório Pessoal do local atual do usuário geralmente contém os certificados colocados lá por uma autoridade raiz, com uma finalidade de “Autenticação do cliente”. O cliente pode usar um certificado quando a autenticação mútua é necessária.

Cada certificado é válido somente por um período de tempo determinado, chamado de período de validade. O período de validade é definido pelos campos Válido de e Válido até de um certificado X.509. Durante a autenticação, o certificado é verificado para determinar se o certificado ainda está dentro do período de validade.

A qualquer momento durante o período de validade, a autoridade de certificação pode revogar um certificado. Isso pode ocorrer por muitas razões, como um comprometimento da chave privada do certificado.

Quando isso ocorre, todas as cadeias que descenderem do certificado revogado também tornam-se inválidas e não são confiáveis durante os procedimentos de autenticação. Para descobrir quais os certificados são revogados, cada emissor publica uma lista de certificados revogados (CRL) com carimbo de data e hora. A lista pode ser marcada usando a revogação online ou offline definindo a propriedade RevocationMode ou DefaultRevocationMode das seguintes classes para um dos valores de enumeração X509RevocationMode: as classes X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthentication e IssuedTokenServiceCredential. O valor padrão para todas as propriedades é Online.

Você também pode define o modo na configuração usando o atributo revocationMode de <autenticação> de elemento <clientCertificate> (< serviceBehaviors >) e de <autenticação> de elemento <clientCertificate> (do < endpointBehaviors >).

No WCF, você deve geralmente especificar um certificado ou conjunto de certificados que um serviço ou cliente deve usar para autenticar, criptografar ou assinar digitalmente uma mensagem. Você pode fazer isso por meio de programação usando o método SetCertificate de várias classes que representam certificados X.509. As seguintes classes usam o método SetCertificate para especificar um certificado.

CLASS

Método

PeerCredential

SetCertificate

X509CertificateInitiatorClientCredential

SetCertificate

X509CertificateRecipientServiceCredential

SetCertificate

X509CertificateInitiatorServiceCredential

SetCertificate

O método SetCertificate funciona designando um local de repositório e um repositório, um tipo “find” (parâmetro x509FindType) que especifica um campo do certificado e um valor a ser localizado no campo. Por exemplo, o código a seguir cria uma instância ServiceHost e define o certificado de serviço usado para autenticar o serviço para clientes com o método SetCertificate .

Uri baseAddress = new Uri("http://cohowinery.com/services");
ServiceHost sh = new ServiceHost(typeof(CalculatorService), baseAddress );
sh.Credentials.ServiceCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My,
X509FindType.FindBySubjectName, "cohowinery.com");

Um repositório pode conter vários certificados com o mesmo nome de assunto. Isso significa que, se você especificar que o x509FindType é FindBySubjectName ou FindBySubjectDistinguishedName, e mais de um certificado tiver o mesmo valor, uma exceção será gerada porquenãoexistenenhuma maneira de distinguir qual certificado é necessário. Você pode solucionar isso configurando o x509FindType como FindByThumbprint. O campo de impressão digital contém um valor exclusivo que pode ser usado para localizar um certificado específico em um repositório. No entanto, isso tem sua própria desvantagem: se o certificado for revogado ou renovado, o método SetCertificate falhará porque a impressão digital também será. Ou se o certificado não for mais válido, a autenticação falhará. A maneira de solucionar isso é definir o parâmetro x590FindType como FindByIssuerName e especificar o nome do emissor. Se nenhum emissor específico for necessário, você também poderá definir um dos outros valores de enumeração X509FindType, como FindByTimeValid.

Você também pode definir certificados usando configuração. Se você estiver criando um serviço, as credenciais, incluindo certificados, serão especificadas em < serviceBehaviors >. Quando você estiver programando um cliente, os certificados serão especificados em < endpointBehaviors >.

Um recurso do IIS e do Active Directory é a capacidade para mapear um certificado para uma conta de usuário do Windows.Para obter mais informações sobre o recurso, consulte Mapear certificados para contas de usuário.

Para obter mais informações sobre usando o mapeamento do Active Directory, consulte Mapeando certificados de cliente com mapeamento de serviço de diretório.

Com esse recurso ativado, você poderá definir a propriedade MapClientCertificateToWindowsAccount da classe X509ClientCertificateAuthentication como true. Na configuração, você poderá definir o atributo mapClientCertificateToWindowsAccount do elemento <autenticação> do elemento <serviceCertificate> como true, conforme mostrado no código a seguir.

<serviceBehaviors>
 <behavior name="MappingBehavior">
  <serviceCredentials>
   <clientCertificate>
    <authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
   </clientCertificate>
  </serviceCredentials>
 </behavior>
</serviceBehaviors>

Mapear um certificado X.509 para o símbolo que representa uma conta de usuário do Windows é considerado uma elevação de privilégio. Assim que for mapeado, o símbolo do Windows poderá ser usado para conceder acesso aos recursos protegidos. Portanto, a política de domínio exige que o certificado X.509 esteja em conformidade com sua política antes do mapeamento. O SChannel pacote de segurança impõe esse requisito.

Ao usar .NET Framework versão 3,5 ou posterior, o WCF garante que o certificado esteja em conformidade com a política de domínio antes de ser mapeado para uma conta do Windows.

Na primeira versão do WCF, o mapeamento é feito sem consultar a política de domínio. Portanto, é possível que aplicativos mais antigos que funcionavam ao serem executados na primeira versão falhem se o mapeamento for habilitado e o certificado X.509 não atender a política de domínio.

Mostrar: