# Web-Push-Encoder: RFC-8030-Anfrage + VAPID + RFC-8291-Verschlüsselung

Kodiert einen vollständigen Web-Push-Versand: aes128gcm-Verschlüsselung nach RFC 8291, VAPID-ES256-JWT nach RFC 8292, RFC-8030-Header, APNs/FCM-Zuordnung und Entschlüsselungs-Roundtrip-Verifikation.

> Kanonische Seite: https://elysiatools.com/de/tools/web-push-rfc8030-vapid-rfc8291-payload-encrypted-content-encoder

- **Kategorie:** Format Conversion

- **Schlagwörter:** web-push-verschlüsselung, rfc 8291 aes128gcm, vapid-jwt, rfc 8292, rfc-8030-header, p256dh auth secret, ecdh p-256 hkdf, apns-header, fcm collapse key, roundtrip-verifikation

## Überblick

Die Verschlüsselung folgt exakt RFC 8291: ECDH über P-256 zwischen einem ephemeralen Application-Server-Schlüssel und dem p256dh-Schlüssel des Abonnements, HKDF-SHA256-Schlüsselkombination mit dem Auth-Secret (Kontext „WebPush: info"), zufälliges 16-Byte-Salt, CEK/Nonce-Ableitung über „Content-Encoding"-Kontexte und AES-128-GCM mit dem RFC-8188-Binärheader (Salt + Record-Größe + Key-ID). Die Implementierung gibt die Beispiele aus RFC 8291 §5 und draft-ietf-webpush-encryption-04 bytegenau wieder.

## Eingaben

- **Nutzdaten (Klartext)** (textarea): Message body sent to the user agent, e.g. {"title":"Order shipped"}
- **Inhaltskodierung** (select)
- **Abonnement-p256dh (base64url)** (text): uncompressed P-256 point from subscription.keys.p256dh
- **Auth-Secret des Abonnements (base64url)** (text): 16-byte secret from subscription.keys.auth
- **Privater Empfängerschlüssel (base64url, optional — aktiviert den Roundtrip)** (text): user-agent P-256 scalar, only if you own the subscription keys
- **Ephemerler privater Server-Schlüssel (base64url)** (text): 32-byte P-256 scalar; generate fresh per send in production
- **Salt (base64url, 16 Bytes)** (text): random 16 bytes per message in production
- **Padding-Bytes** (number)
- **TTL in Sekunden (RFC 8030)** (number)
- **Dringlichkeit (RFC 8030)** (select)
- **Topic (RFC 8030, optional)** (text): coalescing key, e.g. new-message
- **Host des Push-Dienstes** (text)
- **Endpoint-Pfad** (text)
- **VAPID-Authorization-Header bauen (RFC 8292)** (checkbox)
- **VAPID sub (Kontakt)** (text)
- **VAPID aud (Origin des Push-Dienstes)** (text)
- **VAPID exp (Unix-Sekunden)** (number)
- **Privater VAPID-Signierschlüssel (base64url)** (text): P-256 scalar, MUST differ from the encryption key

## Wann verwenden

- Beim Entwickeln und Testen von Push-Servern zur Überprüfung exakter Byte-Ausgaben und Header.
- Beim Debuggen von Verschlüsselungs- und Signierungsfehlern (z. B. Bad Request 400 oder Unauthorized 401 bei Push-Gateways).
- Beim Vergleichen von Standard-aes128gcm-Nachrichten mit Legacy-aesgcm-Formaten (draft-04) und APNs/FCM-Headern.

## Funktionsweise

- Aus dem ephemeren Server-Schlüssel und dem p256dh-Abonnementschlüssel wird per P-256 ECDH ein gemeinsames Geheimnis gebildet und per HKDF-SHA256 mit dem Auth-Secret kombiniert.
- Mit einem 16-Byte-Salt werden Content Encryption Key (CEK) und Nonce abgeleitet, um die Nutzdaten via AES-128-GCM zu verschlüsseln.
- Das Tool generiert ein VAPID-JWT (ES256) mit den Claims sub, aud und exp und setzt die erforderlichen RFC-8030-Header (TTL, Urgency, Topic).
- Ein detaillierter HTML-Bericht listet alle Zwischenschlüssel, Roh-Header, Gateway-Mappings und das Ergebnis der optionalen Entschlüsselungsverifikation auf.

## Anwendungsfälle

- Generierung vollständiger HTTP/2-POST-Payloads für Push-Dienste von Mozilla, Google FCM oder Apple Web Push.
- Kryptografische Verifikation eigener Web-Push-Bibliotheken gegen standardisierte IETF-Testvektoren.
- Zuordnung von RFC-8030-Parametern (wie Urgency und Topic) zu plattformspezifischen APNs- und FCM-Headern.

## Häufig gestellte Fragen

### Was unterscheidet aes128gcm von der aesgcm-Kodierung?

aes128gcm (RFC 8291) bettet Salt und Schlüssel-ID direkt in den Nachrichten-Body (RFC 8188) ein, während Legacy-aesgcm (draft-04) separate HTTP-Header (Encryption und Crypto-Key) nutzt.

### Welche Daten sind aus der Browser-Subscription erforderlich?

Benötigt werden der öffentliche P-256-Schlüssel (p256dh) und das 16-Byte-Authentifizierungsgeheimnis (auth).

### Wozu dient der optionale private Empfängerschlüssel?

Wird der private P-256-Schlüssel des Abonnements angegeben, entschlüsselt das Tool das Chiffrat zur direkten Roundtrip-Verifikation des Klartexts.

### Darf derselbe P-256-Schlüssel für VAPID und die Payload-Verschlüsselung verwendet werden?

Nein, RFC 8291 und RFC 8292 verlangen aus Sicherheitsgründen getrennte Schlüsselpaare für VAPID-Signaturen und die ephemere Nutzdaten-Verschlüsselung.

### Welche VAPID-Claims sind im generierten JWT enthalten?

Das JWT enthält die Ziel-Origin des Push-Dienstes (aud), den Ablaufzeitpunkt in Unix-Sekunden (exp) und eine Kontaktadresse (sub, z. B. mailto:).

## Ähnliche Tools

- [Data-URI-Generator](https://elysiatools.com/de/tools/data-uri-generator): Konvertiert Dateien in Data URIs (Base64 oder prozent-kodiert), um Bilder, Schriftarten und Ressourcen direkt in HTML, CSS oder Markdown einzubetten
- [Hash-Algorithmus-Vergleich](https://elysiatools.com/de/tools/hash-algorithm-comparator): Hasht dieselbe Eingabe mit MD5, SHA-1, SHA-256, SHA-512, BLAKE2b und BLAKE3 und vergleicht sie: Ausgabelänge, Hex/Base64-Digest, Sicherheitsstatus (gebrochen/modern) und relatives Geschwindigkeits-Benchmark. Gut für Lehre, Algorithmuswahl und Prüfsummenkontrolle.
- [RSA Verschlüsseln / Entschlüsseln](https://elysiatools.com/de/tools/rsa-encrypt-decrypt): Verschlüsselt Text mit einem öffentlichen RSA-Schlüssel oder entschlüsselt den Geheimtext mit dem passenden privaten Schlüssel, mit OAEP-Padding (SHA-1 oder SHA-256). Lange Nachrichten werden blockweise verarbeitet. Schlüssel und Daten bleiben lokal. PKCS#1 v1.5 wird bewusst nicht angeboten (Node deaktiviert es für die Entschlüsselung wegen Bleichenbacher-Angriffen).
- [OpenTelemetry-W3C-traceparent-/tracestate-/baggage- und OTLP-Header-Propagierungs-Validator](https://elysiatools.com/de/tools/opentelemetry-w3c-traceparent-tracestate-baggage-and-otlp-protobuf-headers-propagation-validator): Prüft traceparent nach der W3C-Trace-Context-ABNF (Version / 16-Byte-Trace-ID / 8-Byte-Parent-ID / 1-Byte-Trace-Flags; Nullen und Version ff werden abgelehnt, Großschreibung verwarnt), tracestate (≤32 Mitglieder, einfache und tenant@system-Schlüssel, Duplikat-Warnungen) und baggage (prozent-kodierte Werte mit opaken Properties); validiert den OTLP-Export-Content-Type und den 25-Byte-Binärkontext von grpc-trace-context-bin; korreliert zwei traceparent in einem simulierten Round-Trip (Trace-ID-Stabilität und Kollision einer zufälligen Child-Span-ID) und gibt normalisierte Header aus.
- [Base64 Konverter](https://elysiatools.com/de/tools/base64-converter): Kodiert und dekodiert Daten zu/von Base64-Format mit URL-safe Optionen
- [PCIe-LTSSM- und Lane-Margining-Decodierer](https://elysiatools.com/de/tools/pcie-link-training-linkstate-and-lane-margining-eye-decode): Dekodiert ein PCIe-Link-Training-Log (LTSSM-Zustandsfolge + TS1/TS2-Ordered-Sets): Gen1-Gen6-Zeitleiste, ausgehandelte Geschwindigkeit/Breite, Rate-Identifier-Bits, Lane-/Polaritätsinvertierung, Equalization-Phasen und Neustart-Diagnose; bewertet außerdem Lane-Margining-Berichte (pcilmr-CSV) und zeichnet eine Eye-Heatmap.
- [PKCE Code Verifier & Challenge Generator](https://elysiatools.com/de/tools/pkce-code-verifier-generator): Erzeugt, validiert und verifiziert OAuth2-/OIDC-PKCE (RFC 7636) Code-Verifier-/Challenge-Paare. Drei Modi: (1) ein frisches Paar aus kryptografisch sicheren Zufallsbytes (256/384/512/768 Bit) erzeugen, (2) einen eigenen Verifier gegen den RFC prüfen — Länge (43–128), Zeichensatz \[A-Za-z0-9-._~\] und ≥256 Bit Entropie, und (3) ein Paar verifizieren durch Neuberechnung von BASE64URL(SHA256(verifier)). Optional werden die vollständige Autorisierungs-URL und der Token-Austausch-Body gebaut. Ergänzt den generischen Nonce-Generator (der nur das Paar ausgibt) um RFC-Konformitäts-Audit und Paar-Verifikation.
- [Podcast-Kapitelmarken-Generator (ID3 / Podcasting 2.0)](https://elysiatools.com/de/tools/podcast-chapter-marker-builder): Füge eine zeitcodierte Kapitelliste ein und erzeuge alle Auslieferungsformate auf einmal: Podcasting-2.0-Kapitel-JSON (v1.2.0) und RSS-Tag podcast:chapters, optionales Einbrennen der ID3v2.4-CHAP+CTOC-Frames in eine hochgeladene MP3 (Millisekunden als normaler Big-Endian-uint32, Offsets 0xFFFFFFFF, TIT2-Subframe pro Kapitel, bestehende Frames bleiben erhalten), Vorbis-Kommentarpaare CHAPTER001 (OGG/Opus), mp4chaps-Text, Zeitstempelblock für die YouTube-Beschreibung und SRT-Sidecar, plus die echte Player-Supportmatrix (Apple nimmt RSS-JSON seit 2025; Pocket Casts/Overcast lesen nur eingebettetes ID3; Spotify ignoriert beide).

## Beispiele

- [Web Python Bildverarbeitung Beispiele](https://elysiatools.com/de/samples/web-image-processing-python): Web Python Bildverarbeitungsbeispiele mit PIL/Pillow einschließlich Lesen, Speichern, Skalieren und Formatkonvertierung
- [Web Rust Bildverarbeitungsbeispiele](https://elysiatools.com/de/samples/web-image-processing-rust): Web Rust Bildverarbeitungsbeispiele einschließlich Lesen/Schreiben, Skalierung und Formatkonvertierung
- [Web TypeScript Bildverarbeitungsbeispiele](https://elysiatools.com/de/samples/web-image-processing-typescript): Web TypeScript Bildverarbeitungsbeispiele einschließlich Bild-Lesen/Speichern, Skalierung und Formatkonvertierung
- [Web Go Dateioperationsbeispiele](https://elysiatools.com/de/samples/web-file-operations-go): Web Go Dateioperationsbeispiele einschließlich Textdatei-Lesen/Schreiben, Datei-Kopieren/Verschieben, Verzeichnisdurchlauf und Dateivalidierung