SAN do certificado IKEv2: por que a verificação de identidade falha

O seu certificado encadeia numa CA de confiança, as datas estão corretas, e o par ainda recusa concluir a fase 1 com um erro de identidade. Acessibilidade e uma assinatura válida são apenas metade do que um cliente IKEv2 verifica. A outra metade é se a identidade esperada aparece no campo certo do certificado, e essa expectativa é definida pelo perfil, não pelo nome do ficheiro do certificado.

O sintoma tem sempre a mesma forma

Um perfil de ligação é alterado de um nome de anfitrião para um endereço IP, ou renovado de um certificado que tinha um nome DNS para um que só tem endereços, eo túnel deixa de negociar. Nada mudou no caminho de rede. O cliente alcança o par, recebe um certificado e rejeita a identidade do par porque o identificador que lhe foi dito para esperar não está representado num campo que aceita. As renovações são o gatilho habitual, porque o certificado de substituição vem muitas vezes de um modelo diferente do que substitui.

Ambos os lados registam então algo inútil, e é por isso que a falha é normalmente reportada como um problema de certificado. O registo do cliente pode indicar a identidade que queria, e esse nome é a pista que procura, não a data de expiração.

Combine o tipo de identificador, não apenas o valor

Um SAN dNSName e um SAN iPAddress são campos diferentes com regras de correspondência diferentes, por isso um certificado que contém 203.0.113.10 como cadeia DNS não satisfaz um cliente que espera uma identidade IP. Os validadores modernos ignoram em grande parte o nome comum, por isso a etiqueta amigável nos detalhes do certificado não prova nada sobre o que vai corresponder. Se um nome de anfitrião foi substituído por um endereço durante a resolução de problemas, assuma que a identidade esperada se deslocou com ele até ter verificado. Compare a cadeia no perfil com a cadeia no SAN caráter a caráter, porque um ponto final ou um espaço extra é suficiente.

Os carateres universais são apenas uma conveniência DNS e seguem as suas próprias regras de correspondência, o que é outra razão pela qual um perfil baseado em IP nunca deve depender deles.

Descubra onde cada cliente guarda a expectativa

No strongSwan, o valor comparado com o certificado vem da definição de identidade do par: rightid na configuração clássica, ou o id de uma secção de ligação remota em swanctl. A documentação sobre interoperabilidade com Apple IKEv2 é útil aqui porque explica as convenções de identidade usadas por um cliente orientado por perfil, e essas convenções explicam uma classe de incompatibilidades que parece aleatória na rede.

Os perfis de configuração da Apple contêm um campo de identificador remoto, e o valor aí é o que o cliente verifica, não o endereço do servidor nas definições de ligação. Os clientes Windows e de equipamentos têm cada um o seu campo com o seu valor predefinido, e o valor predefinido segue muitas vezes o endereço que escreveu. Onde dois campos discordam, vence o que o cliente realmente lê, e raramente é o que editou.

Repare o perfil ou o certificado, deliberadamente

Antes de alterar qualquer coisa, inspecione o certificado do par com ferramentas aprovadas e liste as entradas SAN com os respetivos tipos. Essa inspeção não requer chave privada nem envio, e resolve a questão em segundos. Se a implementação pretende uma única identidade DNS, o certificado tem de a conter como entrada dNSName, e se a implementação pretende um endereço, o certificado precisa de uma entrada iPAddress exatamente para esse endereço.

Quando o certificado está errado, peça ao operador um corrigido com o identificador esperado específico. Quando o perfil está errado, corrija o perfil e deixe o certificado em paz. Desativar a validação de identidade faz o erro desaparecer e remove a verificação de que o túnel está a falar com o par pretendido.

Documente a identidade esperada por plataforma de cliente, porque um valor que um cliente deriva automaticamente pode ter de ser explícito noutro.

Dê quatro factos ao pedido de renovação

Anote o identificador esperado e o seu tipo, as entradas SAN que o certificado atual realmente tem, o cliente e a versão que fazem a verificação, e o texto exato do erro. Um pedido de renovação construído a partir dessas quatro linhas obtém o certificado certo à primeira, em vez de outro com o mesmo nome de ficheiro familiar.