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

Lesedauer: 7 Minute
0

Mein benutzerdefinierter Amazon-API-Gateway-Domänenname, für den die gegenseitige Transport-Layer-Security-Authentifizierung (TLS) aktiviert ist, gibt HTTP-403-Forbidden-Fehler zurück. Ich weiß nicht, warum das passiert.

Kurzbeschreibung

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

Die folgenden Bedingungen führen dazu, dass API Gateway die TLS-Verbindung nicht herstellen kann und einen Statuscode 403 zurückgibt:

  • 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-API-Operationen

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, das 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.   Schalten Sie die CloudWatch-Protokollierung für Ihre REST-API ein. Konfigurieren Sie anschließend die Ausführungs- und Zugriffsprotokollierung.

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 Domänenname, der gegenseitiges TLS erfordert, einen 403-Forbidden-Fehler zurückgibt.
  • Sie erleichtern die Identifizierung des Anrufers, der versucht hat, Ihre API-Operation aufzurufen, wenn Sie Ihre CloudWatch Logs ü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-Forbidden-Fehler verursacht, indem Sie die Ausführungsprotokolle Ihrer REST-API in CloudWatch anzeigen. Wenn ein 403-Forbidden-Fehler im Zusammenhang mit dem gegenseitigen TLS protokolliert wird, erhalten Sie eine Fehlermeldung ähnlich der folgenden:

Beispiel für eine CloudWatch-Logs-Fehlermeldung, wenn ein benutzerdefinierter Domänenname, der gegenseitiges TLS erfordert, einen 403-Forbidden-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

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

Wenn der Aussteller des Client-Zertifikats nicht im erforderlichen Truststore enthalten ist, gibt der Befehl den folgenden Fehler zurück: „Fehler X bei Y depth lookup: Lokales Ausstellerzertifikat kann nicht abgerufen werden“

Ü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 die folgende Fehlermeldung: 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: Wenn ihre Zertifikatskette erhalten bleibt, akzeptiert API-Gateway Client-Zertifikate, die direkt von der Stammzertifizierungsstelle oder einer anderen Zwischenzertifizierungsstelle signiert wurden. 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, 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 Ausgabemodulus in eine kryptographische Hash-Funktion PIPE einfügen. Sehen Sie sich das folgende openssl-sha1-Beispiel an:

$ 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 werden:

$ diff client.crt bundle.crt

Weitere Informationen finden Sie unter Konfigurieren des Truststores.


AWS OFFICIAL
AWS OFFICIALAktualisiert vor einem Jahr