Trabalhar com certificados
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 brevemente os recursos do certificado digital X.509 e como usá-los no WCF e inclui links para tópicos que explicam melhor esses conceitos ou que mostram como realizar tarefas comuns usando 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 certificação e outras autoridades de registro que verificam e autenticam a validade de cada parte envolvida em uma transação eletrônica por meio do 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), datas de validade (quando o certificado é válido), emissor (a entidade que emitiu o certificado) e uma chave pública. No WCF, cada uma dessas propriedades é processada como um Claim, e cada declaração é dividida em dois tipos: identidade e direito. Para obter mais informações sobre certificados X.509, consulte Certificados de chave pública X.509. Para obter mais informações sobre declarações e autorização no WCF, consulte Gerenciando declarações e autorização com o modelo de identidade. Para obter mais informações sobre como implementar uma PKI, consulte Enterprise PKI with Windows Server 2012 R2 Ative Directory Certificate Services.
A principal função de um certificado é autenticar a identidade do proprietário do certificado para outras pessoas. Um certificado contém a chave pública do proprietário, enquanto o proprietário retém a chave privada. A chave pública pode ser usada para criptografar mensagens enviadas ao proprietário do certificado. Apenas o proprietário tem acesso à chave privada, pelo que apenas o proprietário pode desencriptar essas mensagens.
Os certificados devem ser emitidos por uma autoridade de certificação, que geralmente é um terceiro emissor de certificados. Em um domínio do Windows, é incluída uma autoridade de certificação que pode ser usada para emitir certificados para computadores no domínio.
Ver certificados
Para trabalhar com certificados, muitas vezes é necessário visualizá-los e examinar suas propriedades. Isso é feito facilmente com a ferramenta de snap-in do Console de Gerenciamento Microsoft (MMC). Para obter mais informações, consulte Como exibir certificados com o snap-in do MMC.
Armazenamentos de certificados
Os certificados são encontrados nas lojas. Existem dois grandes locais de lojas que são divididos em sub-lojas. Se você for o administrador em um computador, poderá visualizar os dois principais armazenamentos usando a ferramenta de snap-in do MMC. Os não-administradores podem exibir apenas o repositório de usuários atual.
A loja de máquinas local. Ele contém os certificados acessados por processos de máquina, como ASP.NET. Use esse local para armazenar 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 que normalmente coloca certificados que autenticam um usuário em um serviço.
Estas duas lojas são ainda divididas em sub-lojas. Os mais importantes ao programar com WCF incluem:
Autoridades de certificação raiz confiáveis. Você pode usar os certificados neste repositório para criar uma cadeia de certificados, que pode ser rastreada até um certificado de autoridade de certificação nesse armazenamento.
Importante
O computador local confia implicitamente em qualquer certificado colocado neste armazenamento, mesmo que o certificado não venha de uma autoridade de certificação de terceiros confiável. Por este motivo, não coloque nenhum certificado nesta loja, a menos que confie totalmente no emissor e compreenda as consequências.
Pessoal. Esse armazenamento é usado para certificados associados a um usuário de um computador. Normalmente, esse armazenamento é usado para certificados emitidos por um dos certificados de autoridade de certificação encontrados no armazenamento de Autoridades de Certificação Raiz Confiáveis. Como alternativa, um certificado encontrado aqui pode ser auto-emitido e confiável por um aplicativo.
Para obter mais informações sobre repositórios de certificados, consulte Repositórios de certificados.
Selecione uma loja
A seleção de onde armazenar um certificado depende de como e quando o serviço ou cliente é executado. Aplicam-se as seguintes regras gerais:
Se o serviço WCF estiver hospedado em um serviço do Windows, use o armazenamento da máquina local. Observe que os privilégios de administrador são necessários para instalar certificados no armazenamento da máquina local.
Se o serviço ou cliente for um aplicativo executado em uma conta de usuário, use o repositório de usuário atual.
Aceder a lojas
As lojas são protegidas por listas de controle de acesso (ACLs), assim como as pastas em um computador. Ao criar um serviço hospedado pelo IIS (Serviços de Informações da Internet), o processo de ASP.NET é executado na conta ASP.NET. Essa conta deve ter acesso ao repositório que contém os certificados usados por um serviço. Cada uma das principais lojas é protegida com uma lista de acesso padrão, mas as listas podem ser modificadas. Se você criar uma função separada para acessar um armazenamento, deverá conceder a essa função permissão de acesso. Para saber como modificar a lista de acesso usando a ferramenta WinHttpCertConfig.exe, consulte Como criar certificados temporários para uso durante o desenvolvimento.
Confiança em cadeia e autoridades de certificação
Os certificados são criados em uma hierarquia em que cada certificado individual é vinculado à autoridade de certificação que emitiu o certificado. Este link é para o certificado da autoridade de certificação. Em seguida, o certificado da autoridade de certificação é vinculado à autoridade de certificação que emitiu o certificado da autoridade de certificação original. Esse processo é repetido até que o certificado da autoridade de certificação raiz seja alcançado. O certificado da autoridade de certificação raiz é inerentemente confiável.
Os certificados digitais são usados para autenticar uma entidade confiando nessa hierarquia, também chamada de cadeia de confiança. Você pode exibir a cadeia de qualquer certificado usando o snap-in do MMC clicando duas vezes em qualquer certificado e, em seguida, clicando na guia Caminho do Certificado . Para obter mais informações sobre como importar cadeias de certificados para uma autoridade de certificação, consulte Como especificar a cadeia de certificados da autoridade de certificação usada para verificar assinaturas.
Nota
Qualquer emissor pode ser designado como uma autoridade raiz confiável colocando o certificado do emissor no armazenamento de certificados de autoridade raiz confiável.
Desativar a confiança em cadeia
Ao criar um novo serviço, você pode estar usando um certificado que não é emitido por um certificado raiz confiável ou o certificado em si pode não estar no armazenamento de Autoridades de Certificação Raiz Confiáveis. Apenas para fins de desenvolvimento, você pode desativar temporariamente o mecanismo que verifica a cadeia de confiança para um certificado. Para fazer isso, defina a CertificateValidationMode propriedade como ou PeerTrustPeerOrChainTrust. Qualquer um dos modos especifica que o certificado pode ser auto-emitido (peer trust) ou parte de uma cadeia de confiança. Você pode definir a propriedade em qualquer uma das seguintes classes.
Você também pode definir a propriedade usando a configuração. Os seguintes elementos são usados para especificar o modo de validação:
Autenticação personalizada
A CertificateValidationMode propriedade também permite personalizar como os certificados são autenticados. Por padrão, o nível é definido como ChainTrust. Para usar o Custom valor, você também deve definir o atributo como um assembly e tipo CustomCertificateValidatorType usado para validar o certificado. Para criar um validador personalizado, você deve herdar da classe abstrata X509CertificateValidator .
Ao criar um autenticador personalizado, o método mais importante a ser substituído é o Validate método. Para obter um exemplo de autenticação personalizada, consulte o exemplo de Validador de Certificado X.509. Para obter mais informações, consulte Credencial personalizada e validação de credenciais.
Use o cmdlet New-SelfSignedCertificate do PowerShell para criar uma cadeia de certificados
O cmdlet New-SelfSignedCertificate do PowerShell 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 assim uma hierarquia de certificados encadeados. O cmdlet destina-se a ser usado apenas como um auxílio ao desenvolver serviços e nunca deve ser usado para criar certificados para implantação real. Ao desenvolver um serviço WCF, use as etapas a seguir para criar uma cadeia de confiança com o cmdlet New-SelfSignedCertificate.
Crie um certificado de autoridade raiz temporária (autoassinado) usando o cmdlet New-SelfSignedCertificate. Salve a chave privada no disco.
Use o novo certificado para emitir outro certificado que contenha a chave pública.
Importe o certificado de autoridade raiz para o armazenamento de Autoridades de Certificação Raiz Confiáveis.
Para obter instruções passo a passo, consulte Como criar certificados temporários para uso durante o desenvolvimento.
Qual certificado usar?
Perguntas comuns sobre certificados são qual certificado usar e por quê. A resposta depende se você está programando um cliente ou serviço. As informações que se seguem fornecem uma orientação geral e não constituem uma resposta exaustiva a estas questões.
Certificados de serviço
Os certificados de serviço têm a tarefa principal de autenticar o servidor para os clientes. Uma das verificações iniciais quando um cliente autentica um servidor é comparar o valor do campo Assunto com o URI (Uniform Resource Identifier) usado para contatar o serviço: o DNS de ambos deve corresponder. Por exemplo, se o URI 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 nome comum, por exemplo, CN = www.contoso.com. Também é possível que o campo Assunto fique em branco, caso em que o campo Nome Alternativo do Assunto pode conter o valor Nome DNS.
Observe também que o valor do campo Finalidades pretendidas do certificado deve incluir um valor apropriado, como "Autenticação do servidor" ou "Autenticação do cliente".
Certificados de cliente
Normalmente, os certificados de cliente não são emitidos por uma autoridade de certificação de terceiros. Em vez disso, o armazenamento pessoal do local do usuário atual normalmente contém certificados colocados lá por uma autoridade raiz, com uma finalidade pretendida de "Autenticação de cliente". O cliente pode usar esse certificado quando a autenticação mútua é necessária.
Revogação online e revogação offline
Validade do certificado
Cada certificado é válido apenas por um determinado período de tempo, chamado de período de validade. O período de validade é definido pelos campos Válido de e Válido para de um certificado X.509. Durante a autenticação, o certificado é verificado para determinar se ainda está dentro do período de validade.
Lista de revogação de certificados
A qualquer momento durante o período de validade, a autoridade de certificação pode revogar um certificado. Isso pode ocorrer por vários motivos, como um comprometimento da chave privada do certificado.
Quando isso ocorre, todas as cadeias que descendem do certificado revogado também são inválidas e não são confiáveis durante os procedimentos de autenticação. Para descobrir quais certificados são revogados, cada emissor publica uma lista de revogação de certificados (CRL) com carimbo de data e hora. A lista pode ser verificada usando a revogação online ou a revogação offline definindo a RevocationMode propriedade ou DefaultRevocationMode das seguintes classes como um dos valores de X509RevocationMode enumeração: X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthenticatione as IssuedTokenServiceCredential classes. O valor padrão para todas as propriedades é Online.
Você também pode definir o modo na configuração usando o revocationMode atributo da< autenticação> (do <serviceBehaviors>) e da <autenticação> (do< endpointBehaviors).>
O método SetCertificate
No WCF, muitas vezes você deve 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 programaticamente usando o SetCertificate método de várias classes que representam certificados X.509. As classes a seguir usam o SetCertificate método para especificar um certificado.
O SetCertificate método funciona designando um local de armazenamento e armazenamento, um tipo "find" (x509FindType parâmetro) que especifica um campo do certificado e um valor para localizar no campo. Por exemplo, o código a seguir cria uma ServiceHost instância e define o certificado de serviço usado para autenticar o serviço para clientes com o SetCertificate método.
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");
Dim baseAddress As New Uri("http://cohowinery.com/services")
Dim sh As New ServiceHost(GetType(CalculatorService), baseAddress)
sh.Credentials.ServiceCertificate.SetCertificate( _
StoreLocation.LocalMachine, StoreName.My, _
X509FindType.FindBySubjectName, "cohowinery.com")
Vários certificados com o mesmo valor
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á lançada porque não há como distinguir qual certificado é necessário. Você pode atenuar isso definindo como x509FindTypeFindByThumbprint. O campo de impressão digital contém um valor exclusivo que pode ser usado para localizar um certificado específico em uma loja. No entanto, isso tem sua própria desvantagem: se o certificado for revogado ou renovado, o SetCertificate método falhará porque a impressão digital também desapareceu. Ou, se o certificado não for mais válido, a autenticação falhará. A maneira de mitigar isso é definir o x590FindType parâmetro e FindByIssuerName especificar o nome do emissor. Se nenhum emissor específico for necessário, você também poderá definir um dos outros X509FindType valores de enumeração, como FindByTimeValid.
Certificados em configuração
Você também pode definir certificados usando a configuração. Se você estiver criando um serviço, as credenciais, incluindo certificados, serão especificadas em serviceBehaviors><. Quando você está programando um cliente, os certificados são especificados em endpointBehaviors><.
Mapear um certificado para uma conta de usuário
Um recurso do IIS e do Ative Directory é a capacidade de 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 como usar o mapeamento do Ative Directory, consulte Mapeando certificados de cliente com mapeamento de serviço de diretório.
Com esse recurso habilitado, você pode definir a MapClientCertificateToWindowsAccountX509ClientCertificateAuthentication propriedade da classe como true. Na configuração, você pode definir o mapClientCertificateToWindowsAccount<atributo do elemento de autenticação> 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 token que representa uma conta de usuário do Windows é considerado uma elevação de privilégio porque, uma vez mapeado, o token do Windows pode ser usado para obter acesso a recursos protegidos. Portanto, a diretiva de domínio requer que o certificado X.509 esteja em conformidade com sua política antes do mapeamento. O pacote de segurança SChannel impõe esse requisito.
Ao usar o .NET Framework 3.5 ou versões posteriores, o WCF garante que o certificado esteja em conformidade com a diretiva 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 costumavam funcionar quando executados na primeira versão, falhem se o mapeamento estiver habilitado e o certificado X.509 não satisfizer a diretiva de domínio.