Wie behebe ich HTTP 403 Verboten-Fehler von einem benutzerdefinierten API-Gateway-Domänennamen, der gegenseitiges TLS erfordert?

Letzte Aktualisierung: 2021-12-08

Mein benutzerdefinierter Amazon API Gateway-Domainname, für den die gegenseitige Transport Layer Security (TLS)-Authentifizierung aktiviert ist, gibt HTTP 403 Verboten-Fehler zurück. Warum passiert das, und wie kann ich das Problem beheben?

Kurzbeschreibung

Hinweis: API Gateway kann aus verschiedenen Gründen 403 Verboten-Fehler zurückgeben. Dieser Artikel befasst sich ausschließlich mit 403 Verboten-Fehlern im Zusammenhang mit gegenseitigem TLS. Informationen zur Fehlerbehebung bei anderen Arten von 403 Verboten-Fehlern finden Sie unter Wie behebe ich HTTP 403 Verboten-Fehler von API Gateway?

Um eine API-Gateway-API mit einem benutzerdefinierten Domänennamen aufzurufen, der gegenseitiges TLS erfordert, müssen Clients ein vertrauenswürdiges Zertifikat in der API-Anforderung angeben. Wenn ein Client versucht, die API aufzurufen, sucht API Gateway nach dem Aussteller des Client-Zertifikats in Ihrem Truststore.

Wenn eine der folgenden Bedingungen eintritt, schlägt die TLS-Verbindung fehl und API Gateway gibt einen Statuscode 403 zurück:

  • API Gateway kann den Aussteller des Client-Zertifikats nicht in Ihrem Truststore finden.
  • Das Client-Zertifikat verwendet einen unsicheren Signaturalgorithmus.
  • Das Client-Zertifikat ist selbst signiert.

Wenn die Amazon CloudWatch-Protokollierung für Ihre API aktiviert ist, erscheint in Ihren Ausführungsprotokollen eine Fehlermeldung, die die Ursache des Fehlers angibt.

Wichtig: Wenn die API-Anfrage keine CloudWatch-Logs erzeugt, nachdem die Protokollierung aktiviert wurde, dann steht der 403 Verboten-Fehler nicht im Zusammenhang mit gegenseitigem TLS.

Für REST-APIs

Wenn Sie die Amazon CloudWatch-Protokollierung für Ihre REST-API eingerichtet haben, erscheint eine der folgenden Fehlermeldungen auch in Ihren Ausführungsprotokollen:

  • Zugriff verweigert. Grund: Aussteller für Zertifikat konnte nicht gefunden werden
  • Zugriff verweigert. Grund: Client-Zertifikat mit unsicherem Signatur-Algorithmus
  • Zugriff verweigert. Grund: selbstsigniertes Zertifikat

Für HTTP-APIs

HTTP-APIs unterstützen keine Ausführungsprotokollierung. Um 403 Verboten-Fehler zu beheben, die von einem benutzerdefinierten Domänennamen zurückgegeben werden, der gegenseitiges TLS erfordert und eine HTTP-API aufruft, müssen Sie Folgendes tun:

1.    Erstellen Sie ein neues API-Mapping für Ihren benutzerdefinierten Domänennamen, die eine REST-API nur zu Testzwecken aufruft.
Hinweis: Wenn Sie keine REST-API zum Testen zur Verfügung haben, dann verwenden Sie das Beispiel PetStore REST API. Stellen Sie dann die Beispiel-API auf einer neuen Stufe bereit und erstellen Sie ein neues API-Mapping für sie, die Ihren benutzerdefinierten Domänennamen verwendet.

2.    Folgen Sie den Anweisungen im Abschnitt Auflösung dieses Artikels und verwenden Sie das neue API-Mapping, das Sie für Ihre REST-API erstellt haben.

3.    Nachdem der Fehler identifiziert und behoben wurde, leiten Sie das API-Mapping für Ihren benutzerdefinierten Domainnamen zurück zu Ihrer HTTP-API um.

Auflösung

Bestätigen Sie die Fehlerursache

1.    Wenn Sie dies noch nicht getan haben, aktivieren Sie die CloudWatch-Protokollierung für Ihre REST-API. Stellen Sie sicher, dass Sie die Ausführung und Zugriffsprotokollierung konfigurieren.

Hinweis: Bei der Konfiguration der Zugriffsprotokollierung für diesen Anwendungsfall ist es eine bewährte Methode, die folgenden $context-Variablen zu verwenden. Diese Variablen bewirken zwei Dinge:

  • Sie weisen API Gateway an, CloudWatch Logs zu generieren, wenn Ihr benutzerdefinierter Domainname, der gegenseitiges TLS erfordert, einen 403 Verboten-Fehler zurückgibt.
  • Sie erleichtern die Identifizierung des Anrufers, der versucht hat, Ihre API aufzurufen, wenn Sie Ihre CloudWatch-Protokolle überprüfen.

Empfohlene $context-Variablen für die CloudWatch-Zugriffsprotokollierung, die es dem API Gateway ermöglichen, Ausführungs- und Zugriffsprotokolle zu erstellen

{ "accountId":"$context.accountId", "apiId":"$context.apiId", "domainName":"$context.domainName", "domainPrefix":"$context.domainPrefix", "error.message":"$context.error.message", "error.responseType":"$context.error.responseType", "extendedRequestId":"$context.extendedRequestId", "httpMethod":"$context.httpMethod", "identity.sourceIp":"$context.identity.sourceIp", "identity.clientCert.clientCertPem":"$context.identity.clientCert.clientCertPem", "identity.clientCert.subjectDN":"$context.identity.clientCert.subjectDN", "identity.clientCert.issuerDN":"$context.identity.clientCert.issuerDN", "identity.clientCert.serialNumber":"$context.identity.clientCert.serialNumber", "identity.clientCert.validity.notBefore":"$context.identity.clientCert.validity.notBefore", "identity.clientCert.validity.notAfter":"$context.identity.clientCert.validity.notAfter", "identity.userAgent":"$context.identity.userAgent", "path":"$context.path", "protocol":"$context.protocol", "requestId":"$context.requestId", "requestTime":"$context.requestTime", "requestTimeEpoch":"$context.requestTimeEpoch", "resourceId":"$context.resourceId", "resourcePath":"$context.resourcePath", "stage":"$context.stage", "responseLatency":"$context.responseLatency", "responseLength":"$context.responseLength", "status":"$context.status" }

2.    Stellen Sie fest, was die 403 Verboten-Fehler verursacht, indem Sie die Ausführungsprotokolle Ihrer REST-API in CloudWatch anzeigen. Wenn ein 403 Verboten-Fehler im Zusammenhang mit dem gegenseitigen TLS protokolliert wird, erscheint eine Fehlermeldung ähnlich dem folgenden Beispiel.

Beispiel für eine CloudWatch Logs-Fehlermeldung, wenn ein benutzerdefinierter Domain-Name, der gegenseitiges TLS erfordert, einen 403 Verboten-Fehler zurückgibt

Extended Request Id: {extendedRequestId} 
Access denied. Reason: {reason} 
ForbiddenException Forbidden: {requestId}

So lösen Sie "Zugriff verweigert” auf. Grund: Fehler: "Der Aussteller des Zertifikats konnte nicht gefunden werden"

Überprüfen Sie, ob der Aussteller des Client-Zertifikats in der API-Anforderung im Truststore des benutzerdefinierten Domänennamens enthalten ist

Der Aussteller des Client-Zertifikats (client.pem) in der API-Anforderung muss im Truststore Ihres benutzerdefinierten Domänennamens enthalten sein. Der Aussteller muss auch als Teil des Zertifikatsbündels (bundle.pem) in Amazon Simple Storage Service (Amazon S3) enthalten sein.

Um zu überprüfen, ob der Aussteller des Client-Zertifikats im erforderlichen Truststore enthalten ist, führen Sie den folgenden OpenSSL-Befehl aus:

$ openssl verify -CAfile bundle.pem client.pem

-oder-

Wenn das Zertifikatspaket Zwischenzertifizierungsstellen enthält, führen Sie den folgenden OpenSSL-Befehl aus:

$ openssl verify -CAfile rootCA.pem -untrusted intCA.pem client.pem

Der Befehl gibt eine OK-Antwort zurück, wenn der Aussteller des Client-Zertifikats in der API-Anforderung im erforderlichen Truststore enthalten ist.

Der Befehl gibt den folgenden Fehler zurück, wenn der Aussteller des Client-Zertifikats nicht im erforderlichen Truststore enthalten ist: "error X at Y depth lookup: unable to get local issuer certificate"

Überprüfen Sie, ob alle Client-Zertifikate im Truststore Ihres benutzerdefinierten Domänennamens gültig sind

Wenn eines der Client-Zertifikate im Truststore Ihres benutzerdefinierten Domänennamens nicht gültig ist, können einige Clients möglicherweise nicht auf Ihre API zugreifen.

Um zu überprüfen, ob alle Client-Zertifikate in Ihrem Truststore gültig sind, gehen Sie wie folgt vor:

1.    Öffnen Sie die API-Gateway-Konsole.

2.    Wählen Sie im linken Navigationsbereich Benutzerdefinierte Domainnamen aus. Wählen Sie dann Ihren benutzerdefinierten Domainnamen, für den gegenseitiges TLS erforderlich ist.

3.    Prüfen Sie im Abschnitt Details, ob die folgende Fehlermeldung angezeigt wird: Es gibt ein ungültiges Zertifikat in Ihrem Truststore-Bündel.

4.    Wenn Sie die Fehlermeldung sehen, müssen Sie die Zertifikate in Ihrem Truststore entschlüsseln, um festzustellen, welches Zertifikat die Warnung verursacht hat.
Hinweis: Der folgende OpenSSL-Befehl zeigt den Inhalt eines Zertifikats, einschließlich des Betreffs, an:

$ openssl x509 -in certificate.crt -text -noout

5.    Aktualisieren oder entfernen Sie die Zertifikate, die die Warnung verursacht haben. Laden Sie dann einen neuen Truststore auf Amazon S3 hoch.

Weitere Informationen finden Sie unter Fehlerbehebung bei Zertifikatswarnungen.

Hinweis: API Gateway akzeptiert Client-Zertifikate, die direkt von der Stammzertifizierungsstelle oder einem anderen Zwischenzertifikat signiert sind, wenn die Zertifikatskette erhalten bleibt. Um Client-Zertifikate zu validieren, die nur von der letzten Zwischenzertifizierungsstelle signiert wurden, verwenden Sie einen auf Anfrageparametern basierenden AWS Lambda Authorizer. Sie können Ihren benutzerdefinierten Validierungsalgorithmus auf der Ebene der Lambda-Funktion verwenden, indem Sie das Client-Zertifikat als Eingabe in der API-Anforderung akzeptieren.

So lösen Sie "Zugriff verweigert” auf. Grund: Fehler "Client-Zertifikat verwendet einen unsicheren Signaturalgorithmus"

Überprüfen Sie, ob Ihre Truststore-Textdatei einen unterstützten Hashing-Algorithmus verwendet

API Gateway unterstützt die folgenden Hashing-Algorithmen im Truststore:

  • SHA-256 oder stärker
  • RSA-2048 oder stärker
  • ECDSA-256 oder stärker

Um zu überprüfen, ob Ihre Truststore-Textdatei einen unterstützten Hashing-Algorithmus verwendet oder nicht, führen Sie den folgenden OpenSSL-Befehl aus:

$ openssl x509 -in client.crt -text -noout | grep 'Signature Algorithm'

Die Befehlsantwort gibt den Signaturalgorithmus Ihres Truststores zurück.

Weitere Informationen finden Sie unter Konfigurieren des Truststores.

So lösen Sie "Zugriff verweigert” auf. Grund: Fehler "selbstsigniertes Zertifikat

Überprüfen Sie, dass das selbstsignierte Client-Zertifikat in der API-Anforderung nicht verändert oder beschädigt ist

Die folgenden Angaben müssen genau übereinstimmen:

  • Der Modulus des privaten Schlüssels (private.key), der zum Signieren des selbstsignierten Zertifikats im Truststore in S3 (bundle.crt oder bundle.pem) verwendet wird.
  • Der Modulus aus dem Client-Zertifikat, das in der API-Anforderung übergeben wurde (client.crt).

Um die beiden Moduli zu vergleichen, führen Sie die folgenden OpenSSL-Befehle aus:

$ openssl rsa -noout -modulus -in private.key
$ openssl x509 -noout -modulus -in bundle.crt
$ openssl x509 -noout -modulus -in client.crt

Hinweis: Um einen kürzeren Hash-Wert für einen leichteren Vergleich zu erzeugen, können Sie den Ausgabemodus in eine kryptographische Hash-Funktion PIPE-en. Zum Beispiel: openssl sha1.

$ openssl [operation] -noout -modulus -in [data] | openssl sha1

Beispiele für gültige Befehlsausgaben

2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb

Um die Datenintegrität zu überprüfen, führen Sie den folgenden diff-Befehl aus, um sicherzustellen, dass die Daten auf der Inhaltsebene nicht verändert wurden:

$ diff client.crt bundle.crt

Weitere Informationen finden Sie unter Konfigurieren des Truststores.


War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?