Erreur de certificat web sur Access Server : le paquet CA vide

Une page de connexion web qui ne se charge pas alors que le DNS résout correctement n'est généralement pas un problème DNS. Si le journal du service mentionne un chemin de paquet de certificats vide ou un échec d'analyse PEM pour le certificat web et la clé privée, l'écouteur HTTPS n'a aucun matériel utilisable et aucune résolution de nom n'aidera. La réparation tient en trois clés de configuration et n'exige pas de réémettre un seul certificat client VPN.

Ce que désignent réellement les trois clés

L'ensemble de certificats web personnalisé est décrit par cs.cert, cs.priv_key et cs.ca_bundle. Chacune stocke un chemin de fichier, et les trois sont consommées ensemble par le service web. Un certificat avec la mauvaise clé, ou un fichier de chaîne qui est en fait le certificat feuille, échoue comme une valeur vide : l'écouteur ne peut pas construire de chaîne qu'un navigateur accepterait.

Ces clés appartiennent à l'interface web Admin et Client. Elles sont distinctes de la PKI qui délivre les certificats aux clients VPN, donc les remplacer ne demande pas de toucher aux profils clients, à la clé serveur ni à l'autorité de certification. Traiter une panne TLS web comme motif de reconstruire toute la PKI est le faux pas le plus coûteux ici.

Une distinction fait gagner du temps : une valeur personnalisée explicitement vide n'est pas le même état qu'une absence de substitution. La première donne au parseur un chemin vide, c'est ce que dit la ligne de journal. La seconde laisse Access Server sur son propre matériel, d'où des hôtes qui démarrent bien après une mise à niveau et d'autres non.

Pourquoi un fichier existant ne s'analyse pas

Le parseur lit les blocs étiquetés dans le fichier, pas le nom du fichier. Un .crt contenant une clé privée, une chaîne écrite comme un seul bloc concaténé là où un certificat unique était attendu, ou un fichier enregistré avec une dernière ligne tronquée sont tous rejetés. RFC 7468 définit ces étiquettes lisibles parce qu'elles seules indiquent au lecteur quel type d'objet suit.

Inspectez les objets, pas les extensions. Sur un hôte Linux, openssl x509 -noout -subject -issuer -in server.pem et openssl pkey -noout -check -in key.pem répondent aux deux questions qui comptent, et comparer le module ou la clé publique des deux prouve qu'ils vont ensemble. Gardez la sortie de la clé privée hors des tickets et des journaux de discussion ; le contrôle veut une empreinte, pas la clé.

Un chemin vide mérite la même suspicion qu'un fichier mal formé, car les deux produisent des erreurs aval vagues. Si le journal dit que le chemin du paquet est vide, lisez la valeur stockée avant de déboguer le fichier.

Revenir à la solution de repli volontairement

La CLI d'Access Server inclut un contrôle de validation qui prend les trois chemins en arguments et indique si l'ensemble est utilisable. Les chemins ci-dessous sont illustratifs ; remplacez-les par les emplacements protégés de l'hôte :

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Lisez le résultat avant de toucher au service en marche, et seulement ensuite importez les valeurs et appliquez-les via l'opération documentée pour la version installée. Le tutoriel CLI officiel couvre la validation, l'import dans la base de configuration et l'étape d'application, et sa version compte plus que tout résumé.

Vérifiez le nom que les utilisateurs saisissent

Quand le matériel personnalisé est cassé et qu'un repli intégré valide subsiste, la reprise documentée consiste à retirer les trois substitutions personnalisées et laisser Access Server utiliser ce repli. Prévoyez d'abord un accès console et une sauvegarde de la configuration actuelle, car le service que vous redémarrez sert l'interface d'administration.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Vider toute la base de configuration n'est pas une réparation de certificat. Ciblez ces trois clés, appliquez et confirmez que l'interface web répond. Les fichiers auto-signés du répertoire web-ssl sont la ressource de repli, pas un espace de travail : les écraser ou les régénérer peut supprimer le seul matériel fonctionnel.

Attendez-vous à ce que le navigateur affiche un autre certificat une fois le repli actif. C'est le résultat correct, et la réponse est de le vérifier via votre processus administratif de confiance, non d'apprendre aux utilisateurs à ignorer chaque avertissement.

La reprise ne s'achève qu'après une connexion réussie

La reprise n'est pas finie quand un écouteur TCP apparaît. Validez le nom DNS, l'identité du certificat et la chaîne pour ce nom, puis chargez les interfaces web Admin et Client et terminez une connexion. Un test de port ne prouve rien de tout cela.

Access Server 3.1 et ultérieurs peuvent aussi servir des certificats web différents par nom d'hôte SNI. Si c'est configuré, les clés par défaut et les entrées propres au nom sont des ensembles distincts, et un test par adresse IP montre facilement un certificat différent de celui que reçoivent les utilisateurs. Corrigez et validez l'ensemble du nom en échec, puis refaites le test de connexion avant de clore l'incident.