- Problem: Es wird eine nicht vertrauenswürdige Zertifizierungsstelle oder ein selbstsigniertes Zertifikat verwendet.
Korrektur: Verwende ein von einer öffentlichen Zertifizierungsstelle ausgestelltes SSL-Zertifikat für den Webhook-Rückrufserver.
Neue Funktionen
Erste Schritte
Verwaltung
Senden, Signieren und Verwalten von Vereinbarungen
Erweiterte Vereinbarungsfunktionen und Workflows
Integration in andere Produkte
Acrobat Sign-Entwickler
Support und Fehlerbehebung
Zwei-Wege-SSL, oft auch als clientseitiges SSL oder „Mutual TLS“ bezeichnet, ist ein SSL-Modus, bei dem sowohl der Server als auch der Client (Webbrowser) Zertifikate zur Identifizierung vorlegen.
Kontoadministrator*innen können ein clientseitiges Zertifikat auf der Seite Sicherheitseinstellungen konfigurieren.
Acrobat Sign überprüft die SSL-Zertifikate bei der Bereitstellung von Payloads an die Webhook-URL. Webhooks, die nicht erfolgreich auf SSL-Zertifikate geprüft werden, stellen die JSON-Nutzlast nicht erfolgreich zu.
Verwende Zwei-Wege-SSL zur Authentifizierung des Clients (Acrobat Sign) und des Listening-Service, um sicherzustellen, dass nur Acrobat Sign deine Webhook-URL abrufen kann.
Wenn der Webhook von einer Partneranwendung erstellt wurde, verwendet der Webhook ein Clientzertifikat (falls verfügbar) aus dem Konto der Partneranwendung, um sich beim Senden von Webhook-Benachrichtigungen zu identifizieren.
Im Folgenden findest du die häufigsten Fragen sowohl zur Überprüfung des Webservers als auch zur Überprüfung der Clientzertifizierung.
Während der Registrierung eines Webhooks überprüft Acrobat Sign die URL des Webhook-Servers.
Du kannst den Webhook nicht registrieren, wenn die Verbindung mit der Webhook-Rückruf-URL von Acrobat Sign nicht abgeschlossen werden kann.
Nein.
Für die Webhook-Callback-URL kann nur HTTPS auf Port 443 oder 8443 verwendet werden.
Acrobat Sign blockiert ausgehenden HTTPS-Traffic für alle anderen Ports.
Eine gute Möglichkeit, das Serverzertifikat zu überprüfen, ist die Verwendung des DigiCert® SSL-Installationsdiagnosetools.
Gib nur den Hostnamen ein, z. B.: www.digicert.com.
Häufige Probleme:
Korrektur: Verwende ein von einer öffentlichen Zertifizierungsstelle ausgestelltes SSL-Zertifikat für den Webhook-Rückrufserver.
Korrektur: Installiere die Intermediate-Zertifikate auf dem Webhook-Rückrufserver.
Weitere Informationen findest du unter https://www.digicert.com/kb/ssl-certificate-installation.htm.
Um Zwei-Wege-SSL für einen Webhook einzurichten, müssen Admins eine P12- (oder PFX-)Datei hochladen, die den privaten Schlüssel enthält. Die Datei wird sicher im Nutzungskonto gespeichert und die Admins können sie jederzeit wieder entfernen.
In einem bidirektionalen Webhook-Setup ist Acrobat Sign der Anrufer/Client und benötigt den privaten Schlüssel, um nachzuweisen, dass der Anruf von Acrobat Sign im Namen des Nutzungskontos erfolgt.
Stelle sicher, dass Zwei-Wege-SSL aktiviert ist.
Zwei-Wege-SSL muss auf dem Webhook-Rückrufserver aktiviert sein.
Stelle mit einem beliebigen Webbrowser eine Verbindung zur Webhook-Rückruf-URL her. Die folgende Meldung sollte angezeigt werden:
400 Bad Request No required SSL certificate sent
Dies bedeutet, dass der Server vom Client erwartet, dass dieser Clientzertifikate sendet (d. h. Zwei-Wege-SSL ist für den Server aktiviert).
Wenn die obige Meldung nicht angezeigt wird, ist Zwei-Wege-SSL nicht aktiviert.
Du kannst mit Postman eine POST-Anfrage an die Webhook-Rückruf-URL durchführen. Du solltest ein ähnliches Ergebnis erhalten.
Die Clientanmeldedaten können entweder ein selbstsigniertes Zertifikat oder ein von einer Zertifizierungsstelle ausgestelltes Zertifikat sein. Sie müssen jedoch mindestens den folgenden X.509 v3-Erweiterungen entsprechen:
X.509 v3-Erweiterung |
Wert |
---|---|
ExtendedKeyUsage |
clientAuth (OID: 1.3.6.1.5.5.7.3.2) |
KeyUsage |
digitalSignature |
Das Clientzertifikat muss eine PKCS12-Datei mit der Erweiterung .p12 oder .pfx sein und Folgendes enthalten: das Clientzertifikat (damit der Server die Identität des Clients überprüfen kann) und den privaten Schlüssel des Clients (damit der Client Nachrichten digital signieren kann, die der Server während des SSL-Handshakes überprüfen kann).
Verwende den Befehl openssl zum Überprüfen der P12- bzw. PFX-Datei:
openssl pkcs12 -info -in outfile.p12
Die Passphrase für den privaten Schlüssel muss angefordert werden. Die Ausgabe muss sowohl Zertifikate als auch einen verschlüsselten privaten Schlüssel enthalten wie zum Beispiel:
Bag Attributes localKeyID: 9D BD 22 80 E7 B2 B7 58 9E AE C8 42 71 F0 39 E1 E7 2B 57 DB subject=/C=US/ST=California/L=San Jose/O=Adobe Inc./CN=sp.adobesignpreview.com issuer=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1 -----BEGIN CERTIFICATE----- MIIGwDCCBaigAwIBAgIQAhJSKDdyQZjlbYO5MJAYOTANBgkqhkiG9w0BAQsFADBP MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSkwJwYDVQQDEyBE ... JAKQLQ== -----END CERTIFICATE----- Bag Attributes: <No Attributes> subject=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1 issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA -----BEGIN CERTIFICATE----- MIIEvjCCA6agAwIBAgIQBtjZBNVYQ0b2ii+nVCJ+xDANBgkqhkiG9w0BAQsFADBh MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 ... -----END CERTIFICATE----- Bag Attributes localKeyID: 9D BD 22 80 E7 B2 B7 58 9E AE C8 42 71 F0 39 E1 E7 2B 57 DB Key Attributes: <No Attributes> -----BEGIN ENCRYPTED PRIVATE KEY----- MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQI7eNh2qlsLPkCAggA ... FHE= -----END ENCRYPTED PRIVATE KEY-----
Die Zertifikate müssen mindestens das End Entity-Zertifikat und die Intermediate-Zertifikate enthalten. Idealerweise ist auch das Root-CA-Zertifikat enthalten.
Stelle sicher, dass die P12- oder PFX-Datei durch eine Passphrase geschützt ist.
Erstelle ein selbstsigniertes Clientzertifikat (optional).
Clientzertifikate können je nach Bedarf von einer Zertifizierungsstelle ausgestellt oder selbstsigniert sein.
Zum Generieren eines selbstsignierten Clientzertifikats verwendest du den folgenden openssl-Befehl:
openssl req -newkey rsa:4096 -keyform PEM -keyout ca.key -x509 -days 3650 -outform PEM -out ca.cer
Achte darauf, dass die resultierenden Dateien geheim bleiben, da es sich um deine selbstsignierten CA-Zertifikate handelt.
Generiere als Nächstes die P12-Datei des Clients:
openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.req
openssl x509 -req -in client.req -CA ca.cer -CAkey ca.key -set_serial 101 -extensions client -days 365 -outform PEM -out client.cer
openssl pkcs12 -export -inkey client.key -in client.cer -out client.p12
rm client.key client.cer client.req
Sende nach der Konfiguration eine POST-Anforderung an die Webhook-Rückruf-URL.
Du solltest eine 200-Antwort erhalten.
Warum lehnt Acrobat Sign meine PFX-Datei ab, obwohl ich sie mit Postman überprüft habe?
Wenn du den oben beschriebenen Vorgang zur Überprüfung der PFX-Datei ausgeführt hast und Acrobat Sign die PFX-Datei immer noch ablehnt, wurde die Datei wahrscheinlich von einem Microsoft-Tool generiert, das eine nicht standardmäßige PKCS12-Datei erstellen kann.
Verwende in diesem Fall die folgenden openssl-Befehle, um die Zertifikate und den privaten Schlüssel aus der PFX-Datei zu extrahieren und dann eine ordnungsgemäß formatierte PKCS12-Datei zu generieren:
// Zertifikate und privaten Schlüssel aus der PFX-Datei extrahieren openssl pkcs12 -info -in microsoftclientssl.pfx -passin pass:"" -out clientcert.crt -nokeys openssl pkcs12 -info -in microsoftclientssl.pfx -passin pass:"" -out clientcert.key -nodes -nocerts // Neue PKCS12-Datei erstellen openssl pkcs12 -export -inkey clientcert.key -in clientcert.crt -out clientcert.pfx