Solution AEM pour les erreurs de non-correspondance du SAN TLS 421 avec les réseaux CDN gérés par le client

Des erreurs de non-correspondance du réseau de diffusion de contenu HTTP 421 TLS peuvent se produire lorsqu’un réseau CDN, un proxy ou un WAF géré par le client envoie le mauvais en-tête hôte ou la valeur SNI incorrecte au domaine d’entrée Adobe pour Adobe Experience Manager as a Cloud Service. Dans de nombreux cas, la requête échoue également, car les en-têtes transférés requis sont manquants ou incomplets. La mise à jour de la configuration d’origine afin que le réseau CDN utilise le domaine d’entrée Adobe pour l’hôte et le SNI, tout en transmettant le domaine du site d’origine et tous les en-têtes d’authentification requis, résout généralement le problème.

Description description

Environnement

Adobe Experience Manager as a Cloud Service

Problème/Symptômes

Ce problème peut se produire lorsqu’un réseau CDN, un WAF, un proxy ou une répartition de charge géré par le client transfère une valeur d’en-tête hôte ou SNI qui ne correspond pas au domaine d’entrée Adobe pour l’origine de publication AEM.

  • La requête échoue avant d’atteindre le niveau de publication et renvoie une requête HTTP 421 mal dirigée.
  • La réponse peut indiquer que l’hôte demandé ne correspond pas aux autres noms de l’objet du certificat.
  • Dans certains déploiements basés sur proxy, vous pouvez plutôt voir un message indiquant que l’hôte ne correspond pas au SNI.
  • Vous pouvez confirmer le problème en comparant les paramètres de demande d’origine avec le domaine d’entrée Adobe et en testant directement l’origine. Une requête correctement formée renvoie généralement HTTP 200 ou 301, tandis qu’une valeur d’hôte ou SNI incohérente peut renvoyer HTTP 421.

Résolution resolution

Essayez les étapes suivantes pour résoudre le problème :

  1. Identifiez le domaine d’entrée Adobe pour l’environnement de publication affecté dans Cloud Manager et utilisez le domaine de publication au format publish-p<program>-e<environment>.adobeaemcloud.com comme cible d’origine. Vous vous assurez ainsi que vous acheminez les requêtes vers le point d’entrée Adobe approprié pour l’environnement. Vérifiez la valeur en testant directement le domaine d’entrée et en confirmant qu’une requête correctement formée renvoie une réponse HTTP 200 ou 301.
  2. Configurez votre réseau CDN, proxy ou WAF pour utiliser le domaine d’entrée Adobe comme valeur SNI d’origine. Cela permet à l’établissement de liaison TLS d’utiliser le certificat correspondant au domaine d’entrée Adobe. Vérifiez la configuration dans votre sortie de débogage CDN ou proxy et vérifiez que la valeur SNI correspond exactement au domaine d’entrée Adobe.
  3. Définissez l’en-tête de l’hôte d’origine sur le même domaine d’entrée Adobe. Cela permet à la requête de correspondre au certificat et à la cible de routage attendus par l’infrastructure de réseau CDN gérée par Adobe. Vérifiez la modification en testant à nouveau la requête et en confirmant que l’erreur précédente de non-correspondance du SAN HTTP 421 ne se produit plus en raison d’une incohérence de l’hôte ou du certificat.
  4. Transférez le domaine du site d’origine dans l’en-tête X-Forwarded-Host afin qu’AEM puisse résoudre correctement le domaine entrant une fois que la requête a atteint l’origine. Cela permet de s’assurer que le routage basé sur l’hôte continue de fonctionner comme prévu pour le domaine face au client. Vérifiez le comportement en confirmant que la requête est résolue sur le site ou l’hôte virtuel attendu.
  5. Si votre configuration utilise l’authentification du réseau CDN géré par le client, configurez et envoyez la valeur X-AEM-Edge-Key définie pour l’environnement dans Cloud Manager. Cela permet aux services de réseau CDN gérés par Adobe de reconnaître la demande comme approuvée et de traiter correctement les en-têtes transférés. Vérifiez la configuration en confirmant que la requête n’échoue plus en raison d’une authentification Edge manquante.
  6. Testez à nouveau la requête de bout en bout. Si vous utilisez cURL pour la validation, ciblez le domaine d’entrée Adobe et incluez les en-têtes Host, X-Forwarded-Host et, le cas échéant, X-AEM-Edge-Key. Le résultat attendu est que la requête renvoie HTTP 200 ou 301 au lieu de HTTP 421. Vérifiez le résultat en confirmant que les tests de navigateur et cURL acheminent désormais correctement vers le site attendu.

Si les symptômes ci-dessous apparaissent et que les étapes de dépannage produisent les résultats suivants, envoyez un ticket au support Adobe :

  • Le HTTP 421 se poursuit une fois que le domaine d’origine, l’en-tête de l’hôte et la valeur SNI correspondent tous au domaine d’entrée Adobe.
  • La requête échoue toujours après le transfert de X-Forwarded-Host et, si nécessaire, d’une X-AEM-Edge-Key valide.
  • Votre réseau CDN, proxy ou WAF ne peut pas remplacer l’en-tête hôte ou la valeur SNI pour les requêtes d’origine.

Ouvrez un cas et incluez le texte exact de l’erreur, le domaine affecté, le domaine d’entrée Adobe, les résultats du test assaini et toute sortie de débogage du réseau CDN pertinente.

Lecture connexe

recommendation-more-help
experience-cloud-kcs-help-kbarticles