Certificat IKEv2 i SAN: per què falla la comprovació d'identitat

La cadena del certificat arriba a una CA de confiança, les dates són correctes i tot i així el par refusa completar la fase 1 amb una error d'identitat. L'abastiment i una signatura vàlida només són la meitat del que comprova un client IKEv2. L'altra meitat és si la identitat que espera apareix al certificat en el camp correcte, i aquesta expectativa la fixa el perfil, no el nom del fitxer del certificat.

El símptoma sempre té la mateixa forma

Un perfil de connexió es canvia d'un nom d'amfitrió a una adreça IP, o es renova d'un certificat que portava un nom DNS a un que només porta adreces, i el túnel deixa de negociar. Res no ha canviat al camí de xarxa. El client arriba al par, rep un certificat i rebutja la identitat del par perquè l'identificador que li havien dit que esperés no és representat en un camp que accepta. Les renovacions són el desencadenant habitual, ja que el certificat de substitució sovint prové d'una plantilla diferent de la que substitueix.

Aleshores tots dos costats registren alguna cosa inútil, i per això la fallada se sol informar com un problema de certificat. El registre del client pot anomenar la identitat que volia, i aquest nom és la pista que voleu, no la data de caducitat.

Feu coincidir el tipus d'identificador, no només el valor

Un SAN dNSName i un SAN iPAddress són camps diferents amb regles de coincidència diferents, així que un certificat que porti 203.0.113.10 com a cadena DNS no satisfà un client que espera una identitat IP. Els validadors moderns ignoren en gran part el nom comú, així que l'etiqueta amistosa als detalls del certificat no demostra res sobre què coincidirà. Si un nom d'amfitrió s'ha substituït per una adreça durant la resolució de problemes, suposeu que la identitat esperada s'hi ha mogut fins que ho hàgiu comprovat. Compareu la cadena del perfil amb la cadena del SAN caràcter per caràcter, perquè un punt final o un espai de més ja n'hi ha prou.

Els comodins són una comoditat només per a DNS i segueixen les seves pròpies regles de coincidència, que és una altra raó perquè un perfil basat en IP no hi confiï mai.

Trobeu on cada client desa l'expectativa

A strongSwan, el valor que es compara amb el certificat prové de la configuració d'identitat del par: rightid a la configuració clàssica, o l'id d'una secció de connexió remota a swanctl. La documentació sobre interoperabilitat amb Apple IKEv2 és útil aquí perquè detalla les convencions d'identitat que fa servir un client guiat per perfil, i aquestes convencions expliquen una classe de desajustament que a la xarxa sembla aleatori.

Els perfils de configuració d'Apple porten un camp d'identificador remot, i el valor d'allà és el que comprova el client, no l'adreça del servidor a la configuració de connexió. Els clients de Windows i d'aparells tenen cadascun el seu camp amb el seu valor per defecte, i el defecte sovint segueix l'adreça que heu escrit. Quan dos camps discrepen, guanya el que el client llegeix realment, i poques vegades és el que heu editat.

Repareu el perfil o el certificat, deliberadament

Inspeccioneu el certificat del par amb eines aprovades i llisteu les entrades SAN amb els seus tipus abans de canviar res. Aquesta inspecció no necessita cap clau privada ni cap pujada, i resol la qüestió en segons. Si el desplegament pretén una identitat DNS, el certificat l'ha de portar com a entrada dNSName, i si pretén una adreça, el certificat necessita una entrada iPAddress per a exactament aquesta adreça.

Quan el certificat és incorrecte, demaneu-ne un de corregit a l'operador amb l'identificador esperat concret. Quan el perfil és incorrecte, repareu el perfil i deixeu el certificat tranquil. Desactivar la validació d'identitat fa desaparèixer l'error i elimina la comprovació que el túnel parla amb el par que volíeu.

Documenteu la identitat esperada per plataforma de client, perquè un valor que un client deriva automàticament pot caldre que sigui explícit en un altre.

Doneu quatre fets a la sol·licitud de renovació

Anoteu l'identificador esperat i el seu tipus, les entrades SAN que el certificat actual té realment, el client i la versió que fan la comprovació, i el text exacte de l'error. Una sol·licitud de renovació construïda amb aquestes quatre línies obté el certificat correcte a la primera, en lloc d'un altre amb el mateix nom de fitxer familiar.