AEM-Lösung für 421-TLS-SAN-Inkongruenzen mit kundenverwalteten CDNs
Fehler wegen nicht übereinstimmender HTTP 421 TLS-SANs können auftreten, wenn ein vom Kunden verwaltetes CDN, ein Proxy oder WAF die falsche Host-Kopfzeile oder den falschen SNI-Wert an die Adobe-Eingangs-Domain für Adobe Experience Manager as a Cloud Service sendet. In vielen Fällen schlägt die Anfrage auch fehl, weil erforderliche weitergeleitete Kopfzeilen fehlen oder unvollständig sind. Durch die Aktualisierung der Ursprungskonfiguration, sodass das CDN die Adobe-Eingangs-Domain für Host und SNI verwendet, während die ursprüngliche Website-Domain und alle erforderlichen Authentifizierungskopfzeilen weitergeleitet werden, wird das Problem in der Regel behoben.
Beschreibung description
Umgebung
Adobe Experience Manager as a Cloud Service
Problem/Symptome
Dieses Problem kann auftreten, wenn ein vom Kunden verwaltetes CDN, ein WAF, ein Proxy oder ein Load-Balancer eine Host-Kopfzeile oder einen SNI-Wert weiterleitet, die bzw. der nicht mit der Adobe-Eingangs-Domain für den AEM-Veröffentlichungsursprung übereinstimmt.
- Die Anfrage schlägt fehl, bevor sie die Veröffentlichungsebene erreicht, und gibt eine fehlgeleitete HTTP 421-Anfrage zurück.
- In der Antwort kann angegeben werden, dass der angeforderte Host nicht mit den alternativen Namen des Zertifikatsubjekts übereinstimmt.
- In einigen Proxy-basierten Bereitstellungen wird stattdessen möglicherweise eine Meldung angezeigt, die angibt, dass der Host nicht mit SNI übereinstimmt.
- Sie können das Problem bestätigen, indem Sie die Einstellungen der Ursprungsanfrage mit der Adobe-Eingangs-Domain vergleichen und die Herkunft direkt testen. Eine korrekt erstellte Anfrage gibt normalerweise HTTP 200 oder 301 zurück, während ein nicht übereinstimmender Host- oder SNI-Wert HTTP 421 zurückgeben kann.
Lösung resolution
Führen Sie die folgenden Schritte aus, um das Problem zu lösen:
- Identifizieren Sie die Adobe-Eingangs-Domain für die betroffene Veröffentlichungsumgebung in Cloud Manager und verwenden Sie die Veröffentlichungs-Domain im Format
publish-p<program>-e<environment>.adobeaemcloud.comals Ursprungsziel. Dadurch wird sichergestellt, dass Sie Anfragen an den richtigen Adobe-Endpunkt für die Umgebung weiterleiten. Überprüfen Sie den Wert, indem Sie die Eingangs-Domain direkt testen und bestätigen, dass eine korrekt formatierte Anfrage eine HTTP-Antwort von 200 oder 301 zurückgibt. - Konfigurieren Sie Ihr CDN, Ihren Proxy oder WAF so, dass die Adobe-Eingangs-Domain als Ursprungs-SNI-Wert verwendet wird. Dadurch kann der TLS-Handshake das Zertifikat verwenden, das der Adobe-Eingangs-Domain entspricht. Überprüfen Sie die Konfiguration in der CDN- oder Proxy-Debugausgabe und stellen Sie sicher, dass der SNI-Wert genau mit der Adobe-Eingangs-Domain übereinstimmt.
- Legen Sie für die Ursprungs-Host-Kopfzeile dieselbe Adobe-Eingangs-Domain fest. Auf diese Weise kann die Anfrage dem Zertifikat und dem Routing-Ziel entsprechen, die von der von Adobe verwalteten CDN-Infrastruktur erwartet werden. Überprüfen Sie die Änderung, indem Sie die Anfrage erneut testen und bestätigen, dass der vorherige Fehler wegen nicht übereinstimmender Hosts oder Zertifikate nicht mehr auftritt.
- Leiten Sie die ursprüngliche Website-Domain im
X-Forwarded-Hostweiter, damit AEM die eingehende Domain korrekt auflösen kann, nachdem die Anfrage die Quelle erreicht hat. Dadurch wird sichergestellt, dass das Host-basierte Routing für die kundenorientierte Domain weiterhin wie erwartet funktioniert. Überprüfen Sie das Verhalten, indem Sie bestätigen, dass die Anfrage zum erwarteten Standort oder virtuellen Host aufgelöst wird. - Wenn Ihr Setup die vom Kunden verwaltete CDN-Authentifizierung verwendet, konfigurieren Sie den für die Umgebung in Cloud Manager definierten
X-AEM-Edge-Keyund senden Sie ihn. Dadurch können von Adobe verwaltete CDN-Services die Anfrage als vertrauenswürdig erkennen und die weitergeleiteten Header korrekt verarbeiten. Überprüfen Sie die Konfiguration, indem Sie bestätigen, dass die Anfrage nicht mehr aufgrund einer fehlenden Edge-Authentifizierung fehlschlägt. - Testen Sie die Anfrage von Anfang bis Ende erneut. Wenn Sie cURL für die Validierung verwenden, wählen Sie die Adobe-Eingangs-Domain aus und schließen Sie die erforderlichen
Host,X-Forwarded-Hostund, falls erforderlich,X-AEM-Edge-KeyKopfzeilen ein. Das erwartete Ergebnis ist, dass die Anfrage HTTP 200 oder 301 anstelle von HTTP 421 zurückgibt. Überprüfen Sie das Ergebnis, indem Sie bestätigen, dass sowohl der Browser- als auch der cURL-Test erfolgreich zur erwarteten Site weitergeleitet wurden.
Wenn die folgenden Symptome auftreten und die Schritte zur Fehlerbehebung zu den folgenden Ergebnissen führen, senden Sie ein Ticket an den Adobe-Support:
- HTTP 421 wird fortgesetzt, nachdem die Ursprungs-Domain, die Host-Kopfzeile und der SNI-Wert alle mit der Adobe-Eingangs-Domain übereinstimmen.
- Die Anfrage schlägt nach der Weiterleitung von
X-Forwarded-Hostund, falls erforderlich, einer gültigenX-AEM-Edge-Keyimmer noch fehl. - CDN, Proxy oder WAF können die Host-Kopfzeile oder den SNI-Wert für Ursprungsanfragen nicht überschreiben.
Öffnen Sie Fall und geben Sie den genauen Fehlertext, die betroffene Domain, die Adobe-Eingangs-Domain, bereinigte Testergebnisse und alle relevanten CDN-Debugausgaben an.