Erreur de confiance IKEv2 sur Android : envoyez le CA intermédiaire, pas une racine

Le téléphone refuse de se connecter et affiche No trusted RSA public key found for vpn.example.net, alors que le même certificat de passerelle fonctionne depuis un ordinateur portable sur le même réseau. La tentation est de réémettre le certificat. Avant cela, déterminez laquelle des trois défaillances vous avez, car une seule concerne le contenu du certificat.

Trois défaillances derrière un message

Android construit une chaîne du certificat de passerelle jusqu’au CA choisi dans le profil VPN, puis compare le nom du serveur au profil. La notification rapporte le résultat, pas l’étape. Une défaillance de confiance signifie que la chaîne n’a pas pu être complétée avec les certificats remis dans l’échange ; une défaillance d’identité, que la chaîne est valide mais que le nom ne correspond pas ; une défaillance d’algorithme, que l’appareil ou le profil n’accepte pas le type de clé ou la signature.

Décidez sur preuves plutôt qu’en essayant les réparations dans l’ordre. Une tentative au niveau 2 du journal sur le démon vous dit à quelle ligne vous êtes, et coûte moins qu’une réémission d’un certificat qui n’a jamais été faux.

Décidez d’abord : la chaîne entière est-elle arrivée ?

strongSwan envoie le certificat configuré pour cette connexion, et les certificats intermédiaires sont des justificatifs distincts. Ils doivent être chargés comme certificats CA avant que le démon puisse les placer dans une charge utile, donc une disposition où le certificat serveur est signé par un intermédiaire, où la racine est l’ancre de confiance et où l’intermédiaire ne vit que dans le répertoire de build du CA produit exactement cette défaillance : seule la feuille sur le fil, et la chaîne qui s’arrête tôt sur le téléphone.

Vérifiez ce que le démon détient avec swanctl --list-certs sur un déploiement swanctl, ou ipsec listcerts avec l’ancien starter. L’intermédiaire doit apparaître comme certificat CA avec la racine au-dessus. S’il manque, aucune option côté client n’aidera ; s’il est présent, passez à la question suivante.

Vérifiez ensuite s’il serait envoyé. La référence swanctl.conf documente send_cert, dont la valeur par défaut ifasked n’envoie des certificats que si le pair l’a demandé, tandis que always envoie toujours. L’équivalent ancien est leftsendcert=always dans ipsec.conf. Ce réglage contrôle l’envoi, pas la disponibilité : il ne compense pas un intermédiaire que le démon n’a jamais chargé.

Si la chaîne est courte, chargez l’intermédiaire là où le démon cherche

Placez l’intermédiaire dans le répertoire CA, pas à côté de la feuille : /etc/ipsec.d/cacerts pour une disposition avec ipsec.conf, /etc/swanctl/x509ca pour swanctl, ou le chemin que votre paquet substitue. Rechargez la configuration et listez à nouveau les certificats. Certaines versions envoient aussi un paquet contenant la chaîne dans le fichier feuille, mais le répertoire CA est la disposition portable entre versions et paquets.

Vérifiez aussi côté client. Le téléphone ne voit que ce que l’échange a transporté, donc le journal du démon au niveau 2 doit montrer l’intermédiaire parmi les certificats envoyés. Si le journal le montre et que le téléphone échoue encore, vous êtes dans une autre ligne du tableau, et ajuster les fichiers CA ne changera pas le résultat.

Si la chaîne est complète, cessez de modifier les certificats

Une défaillance d’identité est un désaccord entre le nom du profil VPN et le nom du certificat. Android compare l’identité serveur que vous avez configurée au certificat qu’il a validé, donc un profil pointant vers une adresse alors que le certificat nomme un nom d’hôte, ou un profil nommant un nom d’hôte que le certificat ne couvre pas, échoue après une validation de chaîne réussie. Corrigez le côté fautif et gardez profil et certificat alignés.

Une défaillance d’algorithme apparaît avec une chaîne valide et un nom concordant. Les versions d’Android diffèrent par les types de clés et les schémas de signature acceptés, et le type de profil lui-même limite les options. Si la passerelle utilise une combinaison ancienne ou inhabituelle, comparez-la à ce que l’appareil prend en charge avant de supposer le certificat corrompu. Le journal montrera que la poignée de main avance plus loin que dans le cas de confiance, le signal que la chaîne n’est plus le problème.

N’installez pas l’intermédiaire comme racine utilisateur sur le téléphone

Installer l’intermédiaire manquant comme certificat utilisateur sur le téléphone fait disparaître l’avertissement et change le modèle de confiance du téléphone pour chaque application qui accepte des racines installées par l’utilisateur. Cela masque aussi un défaut de livraison qui frappera le prochain client et laisse la passerelle envoyer une chaîne incomplète à chaque futur appareil. La réparation durable est sur le serveur, une fois, pour tous les clients.

Gardez les trois décisions séparées dans le journal des changements : quels certificats ont été transmis, quelle identité a été comparée et quel algorithme a été négocié. Une passerelle qui envoie toujours sa chaîne complète, un profil qui nomme correctement le certificat et un type de clé pris en charge par le parc sont trois petits faits, et ils font toute cette défaillance.