# Encodeur Web Push : requête RFC 8030 + VAPID + chiffrement RFC 8291

Encode un envoi Web Push complet : chiffrement aes128gcm (RFC 8291), JWT ES256 VAPID (RFC 8292), en-têtes RFC 8030, correspondance APNs/FCM et vérification par déchiffrement aller-retour.

> Page canonique: https://elysiatools.com/fr/tools/web-push-rfc8030-vapid-rfc8291-payload-encrypted-content-encoder

- **Catégorie:** Format Conversion

- **Mots-clés:** chiffrement web push, rfc 8291 aes128gcm, jwt vapid, rfc 8292, en-têtes rfc 8030, p256dh auth secret, ecdh p-256 hkdf, en-têtes apns, collapse key fcm, vérification aller-retour

## Présentation

Le chiffrement suit la RFC 8291 à la lettre : ECDH sur P-256 entre une clé éphémère du serveur applicatif et la clé p256dh de l’abonnement, combinaison HKDF-SHA256 avec le secret d’auth (contexte « WebPush: info »), sel aléatoire de 16 octets, dérivation CEK/nonce via les contextes « Content-Encoding » et AES-128-GCM avec l’en-tête binaire RFC 8188 (sel + taille d’enregistrement + id de clé). L’implémentation reproduit octet par octet les exemples de la RFC 8291 §5 et du draft-ietf-webpush-encryption-04.

## Entrées

- **Charge utile (texte clair)** (textarea): Message body sent to the user agent, e.g. {"title":"Order shipped"}
- **Codage de contenu** (select)
- **p256dh de l’abonnement (base64url)** (text): uncompressed P-256 point from subscription.keys.p256dh
- **Secret d’auth de l’abonnement (base64url)** (text): 16-byte secret from subscription.keys.auth
- **Clé privée du récepteur (base64url, optionnel — active la vérification)** (text): user-agent P-256 scalar, only if you own the subscription keys
- **Clé privée éphémère du serveur (base64url)** (text): 32-byte P-256 scalar; generate fresh per send in production
- **Sel (base64url, 16 octets)** (text): random 16 bytes per message in production
- **Octets de bourrage** (number)
- **TTL en secondes (RFC 8030)** (number)
- **Urgence (RFC 8030)** (select)
- **Sujet (RFC 8030, optionnel)** (text): coalescing key, e.g. new-message
- **Hôte du service de push** (text)
- **Chemin de l’endpoint** (text)
- **Construire l’en-tête VAPID Authorization (RFC 8292)** (checkbox)
- **VAPID sub (contact)** (text)
- **VAPID aud (origine du service)** (text)
- **VAPID exp (secondes unix)** (number)
- **Clé privée de signature VAPID (base64url)** (text): P-256 scalar, MUST differ from the encryption key

## Quand l'utiliser

- Lors du débogage d'une implémentation de serveur d'application Web Push générant des erreurs 400 ou 401 sur les passerelles FCM, Mozilla Push ou Apple Web Push.
- Pour valider manuellement les étapes intermédiaires de cryptographie ECDH P-256 et de dérivation HKDF-SHA256 (IKM, CEK, nonce).
- Pour préparer et tester des charges utiles chiffrées avec des paramètres personnalisés de TTL, d'urgence et d'identifiant de regroupement (Topic).

## Fonctionnement

- Saisissez la charge utile en clair ainsi que les clés de souscription du client (`p256dh` et `auth`) fournies par l'API Push du navigateur.
- Renseignez la clé privée éphémère du serveur applicatif, le sel de 16 octets et les informations d'authentification VAPID (clé de signature, contact `sub` et audience `aud`).
- Configurez les paramètres de transport RFC 8030 tels que l'urgence, le TTL et le topic de remplacement.
- Générez le rapport complet affichant les en-têtes HTTP, la trace des dérivations cryptographiques RFC 8291, le corps chiffré binaire et la vérification de déchiffrement.

## Cas d'usage

- Vérification octet par octet d'une bibliothèque backend Web Push par comparaison avec les vecteurs de test officiels.
- Construction de requêtes HTTP/2 Push prêtes à être envoyées via curl ou des clients REST de test.
- Diagnostic d'incompatibilité de jetons VAPID ou de format de clé publique entre différents navigateurs clients.

## Questions fréquentes

### Quelle est la différence entre les codages aes128gcm et aesgcm ?

aes128gcm est le standard officiel de la RFC 8291 incluant les métadonnées de chiffrement dans l'en-tête binaire RFC 8188 du corps, tandis qu'aesgcm est l'ancienne spécification draft-04 utilisant les en-têtes HTTP Encryption et Crypto-Key.

### À quoi sert la clé privée du récepteur (uaPrivateKey) ?

Elle est facultative et sert uniquement à exécuter un déchiffrement aller-retour immédiat pour valider que le client recevra et décodera fidèlement le message original.

### La clé privée VAPID peut-elle être identique à la clé éphémère du serveur ?

Non, la RFC 8292 impose que la paire de clés VAPID soit distincte des clés éphémères générées pour le chiffrement ECDH de la charge utile.

### Comment le champ Topic est-il géré par les services de push ?

Le champ Topic sert de clé d'écrasement (coalescing key) : un nouveau message portant le même topic remplace un message en attente non encore délivré sur le terminal.

### Quelles correspondances sont fournies pour APNs et FCM ?

L'outil traduit automatiquement les en-têtes RFC 8030 (TTL, Urgency, Topic) en leurs équivalents respectifs pour Apple Push Notification service (apns-expiration, apns-priority, apns-collapse-id) et Firebase Cloud Messaging.

## Outils associés

- [Générateur de Data URI](https://elysiatools.com/fr/tools/data-uri-generator): Convertit les fichiers en Data URI (Base64 ou pourcentage-encodé) pour intégrer images, polices et ressources directement dans HTML, CSS ou Markdown
- [Comparateur d’algorithmes de hachage](https://elysiatools.com/fr/tools/hash-algorithm-comparator): Hache la même entrée avec MD5, SHA-1, SHA-256, SHA-512, BLAKE2b et BLAKE3 et les compare : longueur, digest hex/Base64, statut de sécurité (cassé/moderne) et benchmark de vitesse relatif. Idéal pour l’enseignement, le choix d’algorithme ou la vérification de checksums.
- [Chiffrement / Déchiffrement RSA](https://elysiatools.com/fr/tools/rsa-encrypt-decrypt): Chiffre du texte avec une clé publique RSA ou déchiffre le texte chiffré avec la clé privée correspondante, en utilisant le padding OAEP (SHA-1 ou SHA-256). Gère les longs messages par blocs. Les clés et données restent locales. PKCS#1 v1.5 n'est pas proposé (Node le désactive pour le déchiffrement à cause des attaques Bleichenbacher).
- [Validateur de propagation OpenTelemetry W3C traceparent / tracestate / baggage et en-têtes OTLP](https://elysiatools.com/fr/tools/opentelemetry-w3c-traceparent-tracestate-baggage-and-otlp-protobuf-headers-propagation-validator): Valide traceparent selon l'ABNF de W3C Trace Context (version / trace-id 16 octets / parent-id 8 octets / trace-flags 1 octet ; zéros et version ff rejetés, majuscules signalées), tracestate (≤32 membres, clés simples et tenant@système, doublons signalés) et baggage (valeurs percent-encodées avec propriétés opaques) ; vérifie le Content-Type d'export OTLP et le contexte binaire de 25 octets de grpc-trace-context-bin ; corrèle deux traceparent dans un aller-retour simulé (stabilité du trace-id et collision d'un span-id enfant aléatoire) et émet des en-têtes normalisés.
- [Convertisseur Base64](https://elysiatools.com/fr/tools/base64-converter): Encode et décode les données vers/depuis le format Base64 avec options URL-safe
- [Décodeur LTSSM et Lane Margining PCIe](https://elysiatools.com/fr/tools/pcie-link-training-linkstate-and-lane-margining-eye-decode): Décode un journal d’apprentissage de lien PCIe (séquence LTSSM + ensembles ordonnés TS1/TS2) : chronologie Gen1-Gen6, vitesse/largeur négociées, bits d’identifiant de débit, inversions de polarité et de lane, phases d’égalisation et diagnostic des redémarrages ; note aussi les rapports de lane margining (CSV pcilmr) et dessine la carte de chaleur de l’œil.
- [Générateur de PKCE Code Verifier et Challenge](https://elysiatools.com/fr/tools/pkce-code-verifier-generator): Génère, valide et vérifie les paires code_verifier / code_challenge PKCE (RFC 7636) OAuth2 / OIDC. Trois modes : (1) générer une nouvelle paire depuis des octets aléatoires cryptographiques (256/384/512/768 bits), (2) auditer un verifier existant selon le RFC — longueur (43–128), charset \[A-Za-z0-9-._~\] et ≥256 bits d'entropie, et (3) vérifier une paire en recalculant BASE64URL(SHA256(verifier)). Construit en option l'URL complète de requête d'autorisation et le corps d'échange de token. Complète le nonce-generator générique (qui n'émet que la paire) avec l'audit de conformité RFC et la vérification de paire.
- [Générateur de marqueurs de chapitres podcast (ID3 / Podcasting 2.0)](https://elysiatools.com/fr/tools/podcast-chapter-marker-builder): Collez une liste de chapitres horodatés et générez d'un coup tous les formats de livraison : JSON de chapitres Podcasting 2.0 (v1.2.0) et balise RSS podcast:chapters, gravure optionnelle des trames ID3v2.4 CHAP+CTOC dans un MP3 téléversé (millisecondes en uint32 big-endian simple, offsets 0xFFFFFFFF, sous-trame TIT2 par chapitre, trames existantes préservées), paires de commentaires Vorbis CHAPTER001 (OGG/Opus), texte mp4chaps, bloc d'horodatages pour la description YouTube et sidecar SRT, plus la matrice réelle de support des lecteurs (Apple accepte le JSON via RSS depuis 2025 ; Pocket Casts/Overcast ne lisent que l'ID3 embarqué ; Spotify ignore les deux).

## Exemples

- [Exemples de Traitement d'Images Web Python](https://elysiatools.com/fr/samples/web-image-processing-python): Exemples de traitement d'images Web Python utilisant PIL/Pillow incluant la lecture, l'enregistrement, le redimensionnement et la conversion de format
- [Exemples de Traitement d'Images Web Rust](https://elysiatools.com/fr/samples/web-image-processing-rust): Exemples de traitement d'images Web Rust incluant lecture/écriture, redimensionnement et conversion de format
- [Exemples de Traitement d'Images Web TypeScript](https://elysiatools.com/fr/samples/web-image-processing-typescript): Exemples de traitement d'images Web TypeScript incluant lecture/sauvegarde, redimensionnement et conversion de format
- [Exemples d'Opérations sur Fichiers Web Go](https://elysiatools.com/fr/samples/web-file-operations-go): Exemples d'opérations sur fichiers Web Go incluant lecture/écriture de fichiers texte, copier/déplacer, parcours de répertoires et validation de fichiers