Wie behebe ich „HTTP 403 Forbidden“-Fehler von einem benutzerdefinierten API-Gateway-Domainnamen, für den gegenseitiges TLS erforderlich ist?

Kurzbeschreibung

**Hinweis:**API Gateway zeigt aus verschiedenen Gründen den Fehler 403 Forbidden an. Dieser Artikel behandelt nur „403 Forbidden"-Fehler, die mit gegenseitigem TLS zu tun haben. Informationen zum Beheben anderer Arten von „403 Forbidden“-Fehlern finden Sie unter Wie behebe ich HTTP-403-Fehler von API Gateway?

Um eine API Gateway API mit einem benutzerdefinierten Domainnamen aufzurufen, der gegenseitiges TLS erfordert, müssen Clients in der API-Anfrage ein vertrauenswürdiges Zertifikat vorlegen. Wenn ein Client die API aufruft, sucht API Gateway in Ihrem Truststore nach dem Aussteller des Client-Zertifikats.
Die folgenden Bedingungen führen dazu, dass API Gateway die TLS-Verbindung fehlschlagen lässt und einen 403-Statuscode anzeigt:

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

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

Wichtig: Wenn die API-Anfrage nach der Aktivierung der Protokollierung keine CloudWatch-Protokolle generiert, bezieht sich der „403 Forbidden“-Fehler nicht auf gegenseitiges TLS.

Für REST-APIs

Wenn Sie die Amazon-CloudWatch-Protokollierung für Ihre REST-API einrichten, 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 Signaturalgorithmus
• Zugriff verweigert. Grund: selbstsigniertes Zertifikat

Für HTTP-API-Vorgänge

HTTP-APIs unterstützen keine Ausführungsprotokollierung. Gehen Sie wie folgt vor, um „403 Forbidden"-Fehlermeldungen zu beheben von einem benutzerdefinierten Domainnamen, der gegenseitiges TLS erfordert und eine HTTP-API aufruft:

1. Erstellen Sie eine neue API-Zuordnung für Ihren benutzerdefinierten Domainnamen, die eine REST-API nur zum Testen aufruft.
   Hinweis: Wenn Sie keine REST-API zum Testen haben, verwenden Sie das Beispiel einer PetStore-REST-API. Stellen Sie dann die Beispiel-API in einer neuen Phase bereit und erstellen Sie eine neue API-Zuordnung, die Ihren benutzerdefinierten Domainnamen verwendet.
2. Folgen Sie den Anweisungen im Abschnitt Behebung dieses Artikels mit der neuen API-Zuordnung, die Sie zu Ihrer REST-API erstellt haben.
3. Leiten Sie die API-Zuordnung für Ihren benutzerdefinierten Domainnamen zurück zu Ihrer HTTP-API um.

Behebung

Bestätigen der Fehlerursache

1. Schalten Sie die CloudWatch-Protokollierung für Ihre REST-API ein.
2. Konfigurieren Sie die Ausführungs- und Zugriffsprotokollierung.
   Hinweis: Wenn Sie die Zugriffsprotokollierung für diesen Anwendungsfall konfigurieren, empfiehlt es sich, die folgenden $context-Variablen zu verwenden:

   { "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" }

   Diese Variablen weisen API Gateway an, CloudWatch-Protokolle zu generieren, wenn Ihr benutzerdefinierter Domainname, der gegenseitiges TLS erfordert, zu einem 403-Fehler führt. Sie erleichtern es auch, den Anrufer zu identifizieren, der versucht hat, Ihren API-Vorgang aufzurufen.
3. Sehen Sie sich die Ausführungsprotokolle Ihrer REST-API in CloudWatch an, um die Ursache des Fehlers zu ermitteln. Wenn ein „403 Forbidden“-Fehler im Zusammenhang mit gegenseitigem TLS protokolliert wird, erhalten Sie eine Fehlermeldung ähnlich der folgenden:

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

Beheben Sie „Zugriff verweigert. Grund: Der Aussteller des Zertifikats konnte nicht gefunden werden“-Fehler.

Stellen Sie sicher, dass der Aussteller des Client-Zertifikats in der API-Anfrage im Truststore des benutzerdefinierten Domainnamens enthalten ist

Der Aussteller des Client-Zertifikats (client.pem) in der API-Anfrage muss im Truststore Ihres benutzerdefinierten Domainnamens enthalten sein. Der Aussteller muss auch als Teil des Zertifikatspakets (bundle.pem) in Amazon Simple Storage Service (Amazon S3) enthalten sein.
Führen Sie den folgenden OpenSSL-Befehl aus, um zu überprüfen, ob der Aussteller des Client-Zertifikats im erforderlichen Truststore enthalten ist:

$ 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-Anfrage im erforderlichen Truststore enthalten ist, erhalten Sie auf den Befehl die Antwort OK.

Wenn der Aussteller des Client-Zertifikats nicht im erforderlichen Truststore enthalten ist, führt der Befehl zur folgenden Fehlermeldung: „Fehler X bei Y depth lookup: lokales Ausstellerzertifikat kann nicht abgerufen werden“

Stellen Sie sicher, dass alle Client-Zertifikate im Truststore Ihres benutzerdefinierten Domainnamens gültig sind

Wenn eines der Client-Zertifikate im Truststore Ihres benutzerdefinierten Domainnamens nicht gültig ist, können einige Clients möglicherweise nicht auf Ihre API zugreifen. Gehen Sie wie folgt vor, um zu bestätigen, dass die Client-Zertifikate in Ihrem Truststore gültig sind:

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, dekodieren Sie die Zertifikate in Ihrem Truststore, um festzustellen, welches Zertifikat die Warnung ausgelöst hat.
   Hinweis: Der folgende OpenSSL-Befehl zeigt den Betreff und den Inhalt eines Zertifikats an:

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

5. Aktualisieren oder entfernen Sie die Zertifikate, die die Warnung ausgelöst 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. Verwenden Sie einen auf Anforderungsparametern basierenden AWS Lambda Authorizer, um Client-Zertifikate zu validieren, die nur von der letzten Zwischenzertifizierungsstelle signiert wurden. Sie können Ihren benutzerdefinierten Validierungsalgorithmus auf Lambda-Funktionsebene verwenden. Akzeptieren Sie dazu das Client-Zertifikat als Eingabe aus der API-Anforderung.

Beheben Sie „Zugriff verweigert. Grund: Client-Zertifikat, das einen unsicheren Signaturalgorithmus verwendet“-Fehler

Stellen Sie sicher, dass 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 bestätigen, dass 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 Ihres Truststores.

Beheben Sie „Zugriff verweigert. Grund: selbstsigniertes Zertifikat“-Fehler

Stellen Sie sicher, dass das selbstsignierte Client-Zertifikat in der API-Anfrage nicht geändert oder beschädigt wurde. Die Signaturanforderung für die Client-Zertifizierung (my_client.csr), der private Schlüssel des Client-Zertifikats (my_client.key) und der öffentliche Schlüssel des Client-Zertifikats (my_client.pem) müssen übereinstimmen.

Um Module zu vergleichen, führen Sie diese OpenSSL-Befehle aus:

$ openssl rsa -noout -modulus -in my_client.csr
$ openssl x509 -noout -modulus -in my_client.key
$ openssl x509 -noout -modulus -in my_client.pem

**Hinweis:**Um einen kürzeren Hashwert für einen einfacheren Vergleich zu erzeugen, verwenden Sie eine Pipe auf dem Ausgangsmodul. Sehen Sie sich das folgende openssl sha1-Beispiel an:

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

Ein gültiges Ausgabebeispiel sieht etwa wie folgt aus:

2143831a73a8bb28467860df18550c696c03fbcb2143831a73a8bb28467860df18550c696c03fbcb
2143831a73a8bb28467860df18550c696c03fbcb

Stellen Sie zur Bestätigung der Datenintegrität sicher, dass keine Datenänderungen auf Inhaltsebene vorgenommen wurden. Führen Sie den folgenden diff-Befehl aus:

$ diff client.crt bundle.crt

Weitere Informationen finden Sie unter Konfigurieren Ihres Truststores.