Israel Aece

Software Developer

Consumindo Serviços da NF-e com WCF

Todas as empresas, quando vendem uma mercadoria são obrigadas a emitir nota fiscal. Até pouco tempo atrás, as notas não eram padronizadas e cada empresa utilizava em modelo diferente. O governo decidiu então criar um mecanismo para que fosse possível a emissão de forma eletrônica.

Com isso cada estado brasileiro criou uma porção de web services que permite a emissão, autorização, cancelamento, consulta de status, etc. Como é possível perceber nas URLs dos serviços, eles utilizam o ASP.NET Web Services (ASMX) para expor estas funcionalidades.

Como sabemos, o WCF é o pilar de comunicação dentro do .NET Framework, e mantém compatibilidade com os antigos serviços desenvolvidos em ASMX. Isso quer dizer que é possível consumir estes serviços com a API do WCF. Para que isso seja possível, alguns cuidados precisam ser tomados para garantir que o acesso será permitido.

Os serviços são protegidos e para acessá-los é necessário apresentar um certificado digital válido. Os certificados podem ser adquiridos por entidades certificadores, tais como Serasa, Certsign, VeriSign, etc. E vale dizer que até mesmo o WSDL, documento que descreve as funcionalidades do serviço, também está protegido, e precisamos também apresentar um certificado para simplesmente adicionar a referência no Visual Studio.

Vale lembrar que existem alguns tipos de certificados, e no meu caso, estou utilizando um certifcado de cartão A3 (e-CNPJ) que está protegido por um PIN (senha) que é necessário informá-la sempre que o certificado está prestes a ser utilizado. Como estou com ele devidamente instalado, ao acessar a URL do serviço no navegador, já aparece uma lista com os possíveis certificados, assim como podemos notar na imagem abaixo. Uma vez que o certificado é escolhido, então a senha será exigida e, consequentemente, teremos acesso à página padrão do ASP.NET que descreve o serviço.



Da mesma forma que acontece acima, o Visual Studio também exigirá o certificado ao realizar o "Add Service Reference", e informando corretamente, o download do WSDL será realizado e a referência para o serviço será configurada. Atente-se aqui que não estamos utilizando a opção "Add Web Reference", pois ela recorre a API antiga (SoapHttpClientProtocol) para acesso e não utiliza o WCF.

Apesar da ferramenta já criar uma configuração padrão, ela não é válida para o acesso. Precisamos ajustar para informar ao WCF que ele precisa utilizar um certificado antes de fazer a requisição ao serviço. Estamos optando por utilizar um binding customizado para que seja possível adequar a segurança e a serialização de acordo com as exigências da SEFAZ.

Entre as customizações, temos que utilizar a versão 1.2 do SOAP. Além disso, informar que o transporte será baseado em HTTPS e que é necessário um certificado do cliente para apresentar ao serviço para ter acesso ao recurso. A configuração do certificado é feita através de um behavior e associado ao endpoint do serviço. Abaixo temos o resumo do arquivo de configuração válido para realizar o acesso. Por questões de simplicidade, estou utilizando o serviço que retorna o status (operante ou não) dos demais serviços da SEFAZ.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <bindings>
      <customBinding>
        <binding name="NFe">
          <textMessageEncoding messageVersion="Soap12" />
          <httpsTransport requireClientCertificate="true" />
        </binding>
      </customBinding>
    </bindings>
    <behaviors>
      <endpointBehaviors>
        <behavior name="NFe">
          <clientCredentials>
            <clientCertificate storeName="My"
                               storeLocation="CurrentUser"
                               x509FindType="FindBySubjectName"
                               findValue="ISRAEL AECE ME:........."/>
          </clientCredentials>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <client>
      <endpoint address="https://nfe.fazenda.sp.gov.br/ws/nfestatusservico2.asmx"
                binding="customBinding"
                bindingConfiguration="NFe"
                behaviorConfiguration="NFe"
                contract="ServiceReference1.NfeStatusServico2Soap12"
                name="ServiceReference1.NfeStatusServico2Soap12" />
    </client>
  </system.serviceModel>
</configuration>

Uma vez que a configuração está concluída, podemos acessar o serviço e visualizarmos o retorno. Note que o código C# nada sabe sobre as configurações de certificado. É importante ressaltar que como este certificado tem um PIN, um prompt irá aparecer automaticamente para a digitação do mesmo. Na sequencia é possível visualizar o resultado que foi devolvido pelo serviço.

using (var client = new NfeStatusServico2Soap12Client())
{
    var corpo = new XmlDocument();
    var mensagem = "<?xml version=\"1.0\" encoding=\"utf-8\" ?>" +
                "<consStatServ xmlns=\"http://www.portalfiscal.inf.br/nfe\" versao=\"3.10\">" +
                "<tpAmb>1</tpAmb>" +
                "<cUF>35</cUF>" +
                "<xServ>STATUS</xServ>" +
                "</consStatServ>";

    corpo.LoadXml(mensagem);

    var resultado = client.nfeStatusServicoNF2(new nfeStatusServicoNF2Request()
    {
        nfeCabecMsg = new nfeCabecMsg()
        {
            cUF = "35",
            versaoDados = "3.10"
        },
        nfeDadosMsg = corpo
    });

    Console.WriteLine(resultado.nfeStatusServicoNF2Result.OuterXml);
}

<retConsStatServ versao="3.10" xmlns="http://www.portalfiscal.inf.br/nfe"><tpAmb
>1</tpAmb><verAplic>SP_NFE_PL_008f</verAplic><cStat>107</cStat><xMotivo>Serviço
em Operaçao</xMotivo><cUF>35</cUF><dhRecbto>2015-03-19T08:31:31-03:00</dhRecbto>
<tMed>1</tMed></retConsStatServ>

Validando a Assinatura Digital da NF-e

Atualmente as empresas emitem as notas fiscais em formato eletrônico. Para isso, foi desenvolvido um projeto que especifica e rege a emissão destas notas em ambiente nacional, que é conhecido como Nota Fiscal Eletrônica ou, simplesmente, NF-e. Este projeto faz uso de diversas tecnologias para garantir a segurança e, principalmente, a integridade da mesma.

A integridade é a garantia de que o arquivo XML que a representa não tenha sido alterado desde a sua emissão. Quando uma empresa emite uma nota fiscal, a SEFAZ gera um arquivo XML digitalmente assinado, utilizando o certificado digital da empresa emitente. Como sabemos, esse arquivo XML é a nota fiscal em formato eletrônico, e essa assinatura está embutida nele. A assinatura digital nada mais é que um cálculo matemático que é realizado sobre todo o arquivo XML, e se qualquer mudança ocorrer neste depois da assinatura, a mesma se tornará inválida.

Se você recebe este arquivo e quer garantir que ele não tenha sido alterado, então podemos recorrer à classes que estão dentro do .NET Framework para realizar esta validação. Basicamente devemos carregar o conteúdo XML para o objeto XmlDocument, e em seguida, procurar pelo elemento <Signature /> que é armazena o hash calculado e o certificado serializado que foi utilizado para realizar a assinatura.

var xml = new XmlDocument();
xml.Load("00000000000000000000000000000000000000000000.xml");

var nfe = (XmlElement)xml.GetElementsByTagName("NFe")[0];
var signature = (XmlElement)nfe.GetElementsByTagName("Signature")[0];
var signer = new SignedXml();

signer.LoadXml(signature);
Console.WriteLine(signer.CheckSignature());

Depois de carregado e separado os elementos que serão avaliados, recorrermos a classe SignedXml para validar a assinatura, onde devemos submeter o elemento que contém a assinatura para o método LoadXml, e em seguida, invocar o método CheckSignature, que retorna um valor boleano indicando se ela está ou não válida.

O overload do método CheckSignature utilizado acima (sem parâmetros) analisa o elemento <Signature /> tentando extrair os certificados de forma automática. Caso queira ter um maior controle sobre os certificados utilizados para analisar a assinatura, podemos utilizar um código mais rebuscado para atingir este objetivo:

private static bool ValidateWithCertificate(SignedXml signer)
{
    var keyInfoEnumerator = signer.KeyInfo.GetEnumerator();

    while (keyInfoEnumerator.MoveNext())
    {
        var x509Data = keyInfoEnumerator.Current as KeyInfoX509Data;

        if (x509Data != null && x509Data.Certificates.Count > 0)
            foreach (var cert in x509Data.Certificates)
                if (signer.CheckSignature((X509Certificate2)cert, true))
                    return true;
    }

    return false;
}

Como o próprio nome sugere, a propriedade KeyInfo contém informações referentes à chave que foi utilizada para realizar a assinatura. E, utilizando um enumerador, identificamos se trata-se de um certificado, e ao iterar pela coleção, invocamos o método CheckSignature, e através de um segundo overload, passamos o certificado que queremos que ele considere para realizer a validação. Apesar de ter o mesmo resultado, aqui é possível extrair informações do certificado utilizado, caso seja necessário.

Importante: um erro bastante comum é que alguns sistemas incluem novas informações no XML depois que ele foi assinado. Ao fazer isso, a assinatura digital é corrompida, e ao submetermos o XML para o código que escrevemos acima, a assinatura será dada como inválida. Entre essas informações, é comum ver namespaces como os que são mostrados abaixo (em negrito), e segundo a Nota Técnica 2010/009 da SEFAZ, eles não devem ser incluídos, nem antes, e muito menos depois, da assinatura.

<?xml version="1.0" encoding="UTF-8"?>
<nfeProc xmlns="http://www.portalfiscal.inf.br/nfe"
         xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

         versao="2.00">
  <NFe xmlns="http://www.portalfiscal.inf.br/nfe">
    <infNFe Id="NFe..." versao="2.00">

Utilizando o HTTPS no ASP.NET Web API

Há algum tempo já é possível criar certificados para testarmos em nossas aplicações. Entre os tipos de aplicações que utilizamos certificados, temos aplicações Web (HTML ou APIs) que são expostas através de HTTP e HTTPS. Apesar dos certificados que são considerados "válidos" para o Mercado, devem ser comprados de uma autoridade certificadora (VeriSign, por exemplo), em tempo de desenvolvimento não necessitamos ter todo esse luxo.

Entre as várias opções que temos para criarmos certificados para testes, uma delas é recorrer ao próprio IIS, que possibita a criação de certificados autoassinados, e que podemos perfeitamente utilizar em um ambiente de desenvolvimento. A imagem abaixo ilustra a criação do mesmo e já podemos ver um site configurado com este certificado recém criado.



Se hospedarmos neste site uma Web API, poderemos acessá-la via HTTP ou via HTTPS, afinal, o site dá suporte para estes dois protocolos (bindings). Se quisermos, via programação, forçar com que a requisição seja, obrigatoriamente, realizada através do HTTPS, podemos avaliar antes de executar efetivamente a ação que estão sendo solicitada. Para dar mais flexibilidade, vamos criar um filtro que pode (e deve) ser aplicado naquelas ações que queremos que a mesma esteja sendo acessada através de HTTPS.

public class ValidacaoDeHttps : ActionFilterAttribute
{
    public override void OnActionExecuting(HttpActionContext actionContext)
    {
        var request = actionContext.Request;

        if (request.RequestUri.Scheme != Uri.UriSchemeHttps)
        {
            actionContext.Response =
                request.CreateResponse(
                    HttpStatusCode.Forbidden,
                    new StringContent("É necessário que a requisição seja HTTPS."));
        }
    }
}

Com esta classe criada, podemos decorar as ações que devem ser protegidas pelo transporte. O código abaixo ilustra a utilização deste atributo:

[ValidacaoDeHttps]
public string Get()
{
    return "XPTO";
}

IMPORTANTE: Ao acessar o serviço no navegador, podemos receber um aviso dizendo que o certificado não é confiável. Quando acessamos um recurso via HTTPS, uma das validações que é realizada é identificar se o nome domínio do certificado corresponde ao domínio da URL que estamos acessando. No meu caso, minha máquina chama IsraelAeceNB1; se acessar o serviço como localhost, então um aviso indicando a inconsistência será apresentado. Se utilizar o nome da máquina, então esse aviso não será exibido.

Vale lembrar que esse problema não ocorre somente no navegador. Se estivermos acessando o recurso através do HttpClient, uma exceção será disparada para indicar esse problema. Existe um recurso presente no .NET Framework, que é a possibilidade de interceptar essa validação e, consequentemente, tomar a decisão se podemos ou não aceitar o certificado, mesmo com esta falha. Essa validação deve ser configurada através do delegate ServerCertificateValidationCallback, assim como foi já comentado neste outro artigo.

No exemplo abaixo, estamos acessando o serviço via HTTPS com a URL definida como localhost (o que é suficiente para apresentar o erro), e como estamos dando um by-pass, a requisição é realizada com sucesso. Apesar disso ser útil em um ambiente de testes, é importante dizer que raramente deverá utilizar isso em produção, pois devemos sempre utilizar um "certificado válido".

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

using (var client = new HttpClient())
{
    var r = client.GetAsync("https://localhost/api/Informacoes").Result;

    Console.WriteLine(r.StatusCode);
    Console.WriteLine(r.Content.ReadAsStringAsync().Result);
}

Consumindo serviços via HTTPS

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.

Validando a Identidade do Serviço

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")))
{
    //…
}

Criando certificados para teste

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.

UserName e Certificados

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.

encodedValue

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.