Digitale Signaturen online verifizieren
HMAC-, RSA- und ECDSA-Signaturen über beliebige Nutzdaten mit öffentlichem Schlüssel oder Shared Secret prüfen — nützlich für API-Integrationen, JWTs und Webhook-Debugging.
Weitere Utilities, die gut zu dieser Anleitung passen:
Warum das wichtig ist
Wenn der Webhook eines Anbieters plötzlich die Verifikation nicht besteht, liegt es fast immer an: falschem Schlüssel, falschem Algorithmus, falscher Kanonisierung oder Kodierung. Statt überall console.log in den Verifier zu streuen: Nachricht und Signatur in einen bekannt guten Verifier einfügen und Ergebnisse vergleichen. So sehen Sie sofort, ob der Fehler im eigenen Code oder in der Nachricht steckt.
Drei echte Szenarien
JWT, öffentlichen Schlüssel einfügen, RS256/ES256/HS256 wählen — „gültig“ oder „ungültig“.
Bug auf Handler isoliert
Mit veröffentlichtem RSA-Public-Key die Binärsignatur bestätigen.
Herkunft verifiziert
Nutzlast mit Secret signieren, Ergebnis mit Header der eingehenden Anfrage vergleichen.
Pfad validiert
Schritt für Schritt
Öffnen Sie den Signatur-Verifier.
Nachricht einfügen
Die exakten Bytes, die signiert wurden. Bei JWT:
header.payload; bei AWS Sig V4 die kanonische Zeichenkette zum Signieren.Signatur einfügen
Hex oder Base64 — Kodierung wie bei der Quelle wählen. Das Tool erkennt gängige Formate automatisch.
Schlüssel angeben
Symmetrisch: Secret-Zeichenkette (oder Base64/Hex). Asymmetrisch: PEM-formatierter öffentlicher Schlüssel.
Algorithmus wählen
HS256 / HS384 / HS512 (HMAC), RS256 / RS512 (RSA-PKCS1), PS256 (RSA-PSS), ES256 / ES384 (ECDSA). Dieselben JWT-
alg-Namen gelten.Urteil lesen
„Valid“ oder „Invalid“ mit einer Zeile Begründung bei Ungültigkeit (Algorithmus passt nicht, Schlüssel-Parse-Fehler, falsche Signaturlänge).
Eingaben
Message: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEifQ
Signature: L6S8LWkLzpcREMa8gxaaZbWwLNk0LgcBh6dRQpfIBrI
Key: MyVeryLongSharedSecretValue1234567890
Algorithm: HS256Ergebnis
Valid signature.
Profi-Tipps
- Immer mit Referenz-Vektoren des Anbieters testen. Viele liefern bekannte Nachricht + Signatur zum Abgleich.
- Bei JWTs den Header kopieren und prüfen, ob
algzum Verifier passt. Unsigned Tokens (alg=none) ignorieren — Angriffsvektor. - PSS für neue RSA-Designs. PKCS#1 v1.5 (RS256) ist ok; die Community bevorzugt RSASSA-PSS (PS256).
- Kanonische Zeichenkette im Blick. Ein fehlendes
\noder kleingeschriebener Headername kippt die Signatur — Diff gegen funktionierenden Mitschnitt.
Typische Stolpersteine
Stolperstein
Öffentlicher Schlüssel im falschen Format
PEM gibt es als BEGIN PUBLIC KEY (SPKI) und BEGIN RSA PUBLIC KEY (PKCS#1). Das Tool akzeptiert beides — aber öffentlichen Schlüssel einfügen (nicht Zertifikat, nicht Private Key).
Stolperstein
Signatur ist Base64URL, wird aber als Base64 gelesen
JWT-Signaturen nutzen Base64URL (ohne Padding, Alphabet -_). Kodierung entsprechend setzen oder Differenz manuell bereinigen.
Stolperstein
Algorithmusname passt nicht
„sha256WithRSAEncryption“ in OpenSSL entspricht JWT „RS256“. Richtigen Alias im Dropdown wählen.
Wann dieses Tool nicht passt
- Zertifikate ausstellen — OpenSSL oder Ihre PKI.
- TLS-Serverzertifikate prüfen — Aufgabe des Browsers; Kettenvalidierung ist komplexer als eine Einzelsignatur.
- Plattform-Binaries code-signieren (Windows Authenticode, Apple Developer ID) — plattformspezifische Tools.
FAQ
Kann ich Stripe-/GitHub-Webhooks hier prüfen?
Ja. HS256 (HMAC-SHA-256), Secret aus dem Dashboard, Roh-Body als Nachricht, Headerwert als Signatur — zeigt Manipulation an.
Unterstützt es Ed25519?
Ed25519-Verifikation ist geplant. Bis dahin z. B. openssl pkeyutl -verify.
Wird mein Schlüssel an einen Server geschickt?
Nein. WebCrypto läuft lokal; Schlüssel verlassen den Browserprozess nicht.
Nächste Schritte
- HMAC-Seite der Gleichung im HMAC-Generator berechnen.
- Nutzlast separat hashen, wenn das Protokoll HMAC über Body-Hash schichtet — Hash-Generator.
- JWT-Segmente mit dem Kodier-/Dekodiertool dekodieren, bevor Sie die Nachricht in den Verifier einfügen.