Como posso usar um certificado curinga SSL para autenticar mutuamente vários servidores WCF via X509?
-
06-07-2019 - |
Pergunta
Eu tenho dois servidores WCF, tanto no domínio mydomain.com (exemplo fictício, assim como IP abaixo!), Respectivamente chamado server1 e server2.
Ambos são acessíveis através de seus endereços IP públicos (foo.1 e 2), mas também a partir da LAN privada que estão em (ou seja 192.168.0.1 e 192.168.0.2)
Eu tenho um certificado SSL curinga para * .meudominio.com. É instalado corretamente nas lojas relevantes (isto é pessoal para criptografia e clientes confiáveis ??para autenticação)
Eu gostaria ambos os meus servidores para se conectar uns com os outros em seus endereços de rede local usando o meu certificado curinga para fins de autenticação.
Eu atualizei o arquivo C: \ Windows \ System32 \ drivers \ etc \ hosts para torná-lo parecido com este:
192.168.0.1 Server1.mydomain.com
192.186.0.2 Server2.mydomain.com
Aqueles não são os endereços IP eu ganho se resolver Server1.mydomain.com (eu preferiria ficar foo.1 - 2)
Eu também editou o sufixo DNS específico da conexão para os meus IPV4 interfaces locais para "mydomain.com"
O meu certificado é referido como esta em meus arquivos Server.config (eu despojado todas as partes não relacionadas à autenticação)
<behavior name="ServerToServerBehavior" >
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="PeerOrChainTrust" revocationMode="Online"/>
</clientCertificate>
<serviceCertificate x509FindType="FindByThumbprint" findValue="13a41b3456e431131cd461de"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="myServerAsClientBehaviorConfiguration">
<clientCredentials>
<clientCertificate x509FindType="FindByThumbprint" findValue="13a41b3456e431131cd461de" storeLocation="LocalMachine"/>
<serviceCertificate>
<authentication certificateValidationMode="PeerOrChainTrust" revocationMode="Online" trustedStoreLocation="LocalMachine"/>
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
Isso funciona perfeitamente bem no meu próprio computador dev com gerados localmente X509 certificados, mas no meu ambiente de produção, aqui está o que eu recebo:
Server.Connect: Falha ao conectar-se servidor Server2: System.ServiceModel.Security.MessageSecurityException: verificação de identidade falhou por saída mensagem. A identidade DNS esperado o ponto de extremidade remoto foi 'Server2.mydomain.com', mas o controle remoto ponto final fornecido reivindicação DNS 'Mydomain.com'. Se este é um endpoint remoto legítimo, você pode corrigir o problema por explicitamente especificando identidade DNS 'mydomain.com' como a propriedade de identidade de EndpointAddress ao criar canais proxy.
Eu tentei obter o servidor para responder Server2.mydomain.com em vez de apenas mydomain.com, sem sucesso. Qualquer dica sobre como fazer isso?
Eu também tentei a solução sugerida na mensagem de erro, mas isso parece não ter nenhum efeito em todos os (outros usuários parecem ter o mesmo problema e eu ainda tenho que encontrar uma solução). Qualquer idéia de como consertar isso?
Edit: I cheque já com o meu provedor certificado que eu posso de fato usá-lo para autenticação X509.
Solução
Eu finalmente entendi por que meu campo de identidade estava sendo ignorada.
O meu objectivo foi construído como este:
DistantServer = new ServiceReferenceServerToServer.ServerToServerClient("myServerBinding", "net.tcp://server.mydomain.com/Server");
quando o parâmetro uri é fornecido, o campo de identidade DNS (definido no app.config), é substituído, bem como (mesmo se ele está vazio, que é o caso quando usamos uma string em vez de um objeto URI real).
a solução é configurá-lo através de programação usando o seguinte código:
System.ServiceModel.EndpointAddress uri = new System.ServiceModel.EndpointAddress(new Uri("net.tcp://server.mydomain.com/Server"),new System.ServiceModel.DnsEndpointIdentity("mydomain.com"),new System.ServiceModel.Channels.AddressHeader[0]);
DistantServer = new ServiceReferenceServerToServer.ServerToServerClient("myServerBinding", uri );
Outras dicas
Eu acho que a substituição reivindicação DNS o erro está falando seria especificado no lado do cliente, não o servidor, para que você não está abrindo nada por fazer essa mudança, exceto que seu cliente poderia se conectar com êxito a qualquer servidor em sua domínio (se ele estava ouvindo). O erro que você está vendo é um bocado como o equivalente a uma incompatibilidade hostname na cert segurança de mensagem. Eu comecei a segurança de mensagens para trabalhar com certificados curinga depois de muito trepando, mas você pode ter que fazer algum trabalho de validação personalizada desde a sua cert provavelmente não tem o uso de autenticação do cliente especificado.
Você tem algum motivo você não está usando a segurança de transporte? Muito mais simples para começar a trabalhar a menos que você tem roteamento Layer7 intermediário ...