Wie kann ich Probleme mit der Zertifikatskette und selbstsignierten Zertifikaten für Amazon API Gateway mit benutzerdefinierten Domänen und aktiviertem gegenseitigem TLS beheben?
Ich verwende die gegenseitige TLS-Authentifizierung (Transport Layer Security) mit Amazon API Gateway mit einem benutzerdefinierten Domänennamen. Ich erhalte Fehler bei der Zertifikatskette oder beim selbstsignierten Zertifikat. Wie kann ich dieses Problem beheben?
Kurzbeschreibung
Bevor Sie beginnen, stellen Sie sicher, dass Folgendes erledigt ist:
- Richten Sie einen benutzerdefinierten Domänennamen für Amazon API Gateway ein.
- Die Zertifikatskette und das selbstsignierte Zertifikat wurden erstellt.
- Die Zertifikatskette und das selbstsignierte Zertifikat wurden in AWS Certificate Manager (ACM) importiert.
- Sie haben Ihren Truststore konfiguriert und auf einen Amazon Simple Storage Service (Amazon S3) hochgeladen.
Auflösung
Um eine Liste bestimmter Fehlermeldungen beim Aufrufen Ihrer Amazon-API-Gateway-API zu erhalten, führen Sie einen curl-Befehl aus, der dem folgenden ähnelt:
$ curl -v https://mtls.example.info/test-apigw-mtls --key self-signed.key --cert self-signed.pem:"example"
Fehler beim Kunden
„curl: (58) could not load PEM client certificate, OpenSSL error error:02001002:system library:fopen:No such file or directory, (no key found, wrong pass phrase, or wrong file format?“ (curl: (58) konnte das PEM-Client-Zertifikat nicht laden, OpenSSL-Fehler Fehler:02001002:system library:fopen: Keine solche Datei oder Verzeichnis, (kein Schlüssel gefunden, falsche Passphrase oder falsches Dateiformat?)
Dieser Fehler bedeutet, dass die PEM-Datei den falschen Namen, Speicherort oder das falsche Dateiformat hat. Das lokal gespeicherte Zertifikatsdateiformat ist beispielsweise .crt, aber die .pem-Datei wurde stattdessen in der API-Anforderung verwendet. Um dieses Problem zu beheben, stellen Sie sicher, dass das lokale Client-Zertifikat das richtige Format und den richtigen Namen hat.
„curl: (6) Could not resolve host: mtls.example.info“ (curl: (6) Konnte den Host nicht auflösen: mtls.example.info)
Der Client konnte den Domänennamen nicht auflösen. Stellen Sie sicher, dass der Domänenname und die Konfiguration korrekt sind.
„url: (58) schannel: Failed to import cert file self-signed.pem, last error is 0x80092002“ (url: (58) schannel: Import der Zertifikatdatei self-signed.pem fehlgeschlagen, letzter Fehler ist 0x80092002)
Dieser Fehler bedeutet, dass ein Problem mit der .pem-Datei des lokalen Clients vorliegt. Stellen Sie sicher, dass die .pem-Datei den richtigen Namen und das richtige Format enthält.
„curl: (58) unable to set private key file: 'self-signed.key' type PEM“ (curl: (58) Datei des privaten Schlüssels kann nicht festgelegt werden: 'self-signed.key' Typ PEM)
Dieser Fehler bedeutet, dass ein Problem mit der lokalen Client-Datei vorliegt. Stellen Sie sicher, dass der in der HTTP-Anforderung angegebene private Schlüssel nicht fehlt und korrekt ist.
Serverfehler
„Access denied. Reason: self-signed certificate.“ (Zugriff verweigert. Grund: selbstsigniertes Zertifikat.)
Stellen Sie sicher, 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 Hashwert für einen einfacheren Vergleich zu erzeugen, können Sie PIPE verwenden, um den Ausgabemodul an eine kryptografische Hash-Funktion zu senden. 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
Ähnliche Informationen
Einführung der gegenseitigen TLS-Authentifizierung für Amazon API Gateway
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr