Générateur de clé Web Bot Auth pour signatures HTTP (RFC 9421)

Dans un paysage numérique où les bots et les agents d’intelligence artificielle (IA) jouent un rôle croissant, les méthodes traditionnelles d’identification, comme les chaînes User-Agent ou les listes d’adresses IP, montrent leurs limites. Ces signaux sont faciles à falsifier ou à usurper, ce qui complique la distinction entre un crawler légitime et un acteur malveillant. C’est ici qu’intervient Web Bot Auth, un mécanisme en cours de standardisation par l’IETF (Internet-Drafts basés sur la RFC 9421), qui propose une solution cryptographique pour authentifier les requêtes HTTP.

L’idée est simple : au lieu de se fier à des informations potentiellement trompeuses, chaque requête envoyée par un bot est signée numériquement à l’aide d’une clé privée. Le serveur destinataire peut alors vérifier cette signature en utilisant la clé publique correspondante, publiée dans un répertoire accessible via une URL bien connue (/.well-known/http-message-signatures-directory). Cette approche offre plusieurs avantages :

• Sécurité renforcée : La signature cryptographique est bien plus difficile à falsifier qu’un User-Agent ou une IP.
• Transparence : Les clés publiques sont accessibles à tous, ce qui permet aux sites de vérifier l’identité des bots sans dépendre de listes centralisées.
• Flexibilité : Les signatures peuvent inclure des métadonnées comme un horodatage (created), une date d’expiration (expires), ou un identifiant de clé (keyid), ce qui facilite la gestion des rotations de clés.

Cependant, il est important de noter que Web Bot Auth en est encore au stade de brouillon à l’IETF. Bien que les spécifications soient stables et utilisées par certains acteurs, elles pourraient évoluer avant leur adoption définitive. Pour les développeurs souhaitant tester ce mécanisme dès aujourd’hui, le Générateur de clé d’authentification Web Bot Auth offre une solution clé en main, sans nécessiter de connaissances avancées en cryptographie.

En combinant Web Bot Auth avec d’autres outils comme Générateur de robots.txt pour crawlers IA (pour définir les règles d’accès via robots.txt) ou Générateur de llms.txt (pour spécifier les préférences des agents IA via llms.txt), les opérateurs de bots peuvent adopter une approche moderne et sécurisée pour interagir avec les sites web.

Le Générateur de clé d’authentification Web Bot Auth est conçu pour simplifier la mise en œuvre de Web Bot Auth en produisant tous les éléments nécessaires en un seul clic. Contrairement à d’autres outils qui se contentent de générer une paire de clés, il fournit un kit complet, prêt à être déployé. Voici ce que vous obtenez à la fin du processus :

1. *L’identifiant de clé (key ID) : Calculé selon la RFC 8037 et la RFC 7638, cet identifiant est une empreinte SHA-256 de la clé publique, encodée en base64url. Il sert de référence unique pour la clé et est inclus dans chaque signature sous le paramètre keyid*.

1. Le répertoire de clés au format JSON : Ce fichier, destiné à être hébergé à l’adresse /.well-known/http-message-signatures-directory, contient uniquement la clé publique (sans le paramètre d privé). Il peut inclure des champs optionnels comme nbf (not before) et exp (expiration), utiles pour la rotation des clés. Le générateur fournit également les en-têtes HTTP recommandés pour la réponse, ainsi qu’un exemple de signature valide pour 24 heure.

3. La clé privée : Disponible sous deux formats : - *JWK (JSON Web Key) : Un objet JSON contenant tous les paramètres de la clé, y compris le secret d. Ce format est pratique pour une intégration directe dans des bibliothèques JavaScript ou des outils comme Décodeur JWT. - PKCS#8 PEM : Un format texte standardisé, compatible avec la plupart des bibliothèques cryptographiques (OpenSSL, Python cryptography*, etc.).

1. La clé publique au format SPKI PEM : Un format largement utilisé pour échanger des clés publiques, notamment dans les environnements où les outils attendent un format PEM plutôt qu’un JWK.

1. Un exemple de requête signée : Le générateur produit une requête HTTP complète, incluant les en-têtes Signature et Signature-Input, ainsi qu’une commande curl prête à l’emploi. Cette requête couvre les composants obligatoires comme @authority et signature-agent, et utilise le tag web-bot-auth. La signature expire après 5 min, ce qui permet de tester rapidement le mécanisme sans risque de réutilisation.

1. La base de signature exacte : Il s’agit du texte précis qui est signé par la clé privée. Ce document est essentiel pour déboguer les signatures, car la moindre différence (un espace, une virgule mal placée) invalidera la vérification. Le générateur affiche cette base ligne par ligne, ce qui facilite la comparaison avec une implémentation personnalisée.

Tous ces éléments sont générés directement dans votre navigateur grâce à l’API Web Crypto, ce qui garantit que votre clé privée ne quitte jamais votre appareil. Aucun téléchargement n’est effectué vers un serveur, et une simple actualisation de la page efface toutes les données. Pour conserver votre clé, il est indispensable de la télécharger immédiatement après la génération.

Une fois que vous avez généré votre paire de clés avec le Générateur de clé d’authentification Web Bot Auth, l’étape suivante consiste à publier le répertoire de clés publiques sur votre serveur. Ce répertoire est essentiel, car il permet aux sites web de vérifier les signatures de vos requêtes. Voici comment procéder :

1. Choisir l’emplacement : Le répertoire doit être accessible à l’URL https://votre-domaine.com/.well-known/http-message-signatures-directory. Cette convention, définie par la RFC 8615, permet aux serveurs de localiser automatiquement les informations d’authentification. Assurez-vous que votre serveur HTTPS est correctement configuré et que le chemin ne contient aucun segment supplémentaire (pas de sous-dossiers).

1. Configurer le type MIME : Le fichier JSON doit être servi avec l’en-tête Content-Type: application/json. Si vous utilisez un serveur Apache, vous pouvez ajouter cette directive dans un fichier .htaccess :

   <Files "http-message-signatures-directory">
       ForceType application/json
   </Files>

Pour Nginx, ajoutez cette ligne dans la configuration du serveur :

   location = /.well-known/http-message-signatures-directory {
       default_type application/json;
   }

1. Héberger le fichier JSON : Le contenu du répertoire est fourni par le générateur sous forme de fichier JSON. Voici un exemple de structure :

   {
     "keys": [
       {
         "kty": "OKP",
         "crv": "Ed25519",
         "kid": "z6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V",
         "x": "oB1vj2J5Ym5vj2J5Ym5vj2J5Ym5vj2J5Ym5vj2J5Ym4"
       }
     ]
   }

Si vous avez choisi une durée de validité, les champs nbf (not before) et exp (expiration) seront également inclus. Ces champs permettent de planifier une rotation des clés sans interruption de service.

1. Signer la réponse du répertoire : Bien que le générateur fournisse un exemple de signature pour la réponse du répertoire, il est crucial de ne pas utiliser cet exemple en production. En effet, la signature doit être générée à la volée par votre serveur pour garantir sa fraîcheur. Les en-têtes Signature et Signature-Input doivent être calculés à chaque requête, avec un horodatage (created) et une expiration (expires) actualisés. Voici un exemple d’en-têtes valides :

   Signature-Input: sig1=("@method" "@target-uri" "content-type");created=[timestamp];expires=[timestamp+24h];keyid="votre-keyid";alg="ed25519";tag="web-bot-auth"
   Signature: sig1=:base64(signature):

1. Gérer la rotation des clés : Si vous avez défini une durée de validité pour votre clé, prévoyez un processus de rotation. Par exemple, pour une clé valide 90 jour, générez une nouvelle paire 30 jour avant l’expiration et publiez-la dans le répertoire avec un nouvel identifiant. Les sites pourront ainsi basculer progressivement vers la nouvelle clé sans interruption.

1. Tester l’accès : Une fois le répertoire publié, vérifiez qu’il est accessible et correctement formaté en utilisant un outil comme curl :

   curl -i https://votre-domaine.com/.well-known/http-message-signatures-directory

La réponse doit inclure le fichier JSON avec les en-têtes appropriés. Si vous utilisez Testeur de robots.txt, vous pouvez également tester l’interprétation des règles robots.txt pour vous assurer que votre bot est autorisé à accéder aux ressources souhaitées.

La signature d’une requête HTTP selon les spécifications de Web Bot Auth (basées sur la RFC 9421) repose sur un processus précis qui garantit l’authenticité et l’intégrité des données échangées. Voici comment cela fonctionne, étape par étape :

1. Sélection des composants couverts : Une signature Web Bot Auth ne couvre pas l’intégralité de la requête, mais uniquement certains en-têtes et éléments spécifiques. Les composants obligatoires incluent : - @method : La méthode HTTP (GET, POST, etc.). - @target-uri : L’URL complète de la requête. - @authority : Le nom d’hôte et le port (par exemple, www.example.com:443). - signature-agent : Un en-tête personnalisé qui identifie l’agent signataire (par exemple, Web Bot Auth).

D’autres composants peuvent être ajoutés selon les besoins, comme content-type ou date. Le choix des composants est spécifié dans l’en-tête Signature-Input.

1. Construction de la base de signature : La base de signature est une chaîne de caractères construite à partir des composants couverts, dans un format strictement défini. Voici un exemple de base pour une requête GET :

   "@method": GET
   "@target-uri": https://www.example.com/api/data
   "@authority": www.example.com
   "signature-agent": Web Bot Auth
   "content-type": application/json

Chaque ligne est suivie d’un saut de ligne (\n), et les valeurs sont encadrées de guillemets. Le Générateur de clé d’authentification Web Bot Auth fournit cette base exacte, ce qui permet de la comparer avec une implémentation personnalisée pour éviter les erreurs.

3. Paramètres de la signature : L’en-tête Signature-Input contient les métadonnées de la signature, sous la forme d’une liste de paramètres : - created : Un horodatage Unix (en secondes) indiquant quand la signature a été générée. - expires : Un horodatage Unix indiquant quand la signature expire (par exemple, 5 min après created). - keyid : L’identifiant de la clé publique, calculé comme une empreinte JWK. - alg : L’algorithme utilisé pour la signature (ed25519 dans le cas de Web Bot Auth). - nonce : Un jeton unique optionnel pour éviter les attaques par rejeu. - tag : Un identifiant pour le type de signature (web-bot-auth pour Web Bot Auth).

Voici un exemple d’en-tête Signature-Input :

   Signature-Input: sig1=("@method" "@target-uri" "@authority" "signature-agent");created=1712345678;expires=1712346278;keyid="z6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V";alg="ed25519";tag="web-bot-auth"

1. Calcul de la signature : La base de signature est hachée avec l’algorithme SHA-512, puis signée à l’aide de la clé privée Ed25519. Le résultat est encodé en base64url et ajouté à l’en-tête Signature :

   Signature: sig1=:base64(signature):

1. Vérification par le serveur : Lorsqu’un serveur reçoit une requête signée, il récupère la clé publique depuis le répertoire /.well-known/http-message-signatures-directory en utilisant le keyid fourni. Il reconstruit ensuite la base de signature à partir des composants couverts, puis vérifie la signature avec la clé publique. Si la signature est valide et que les horodatages created et expires sont cohérents, la requête est considérée comme authentique.

Le Générateur de clé d’authentification Web Bot Auth inclut un exemple complet de requête signée, avec une commande curl prête à l’emploi. Cela permet de tester rapidement le mécanisme sans avoir à implémenter soi-même la logique de signature. Pour les développeurs souhaitant intégrer ce processus dans leur code, il est recommandé d’utiliser des bibliothèques compatibles avec la RFC 9421, comme http-message-signatures pour Node.js ou PyHTTPMessageSignatures pour Python.

La clé privée générée par le Générateur de clé d’authentification Web Bot Auth est l’élément le plus sensible de votre configuration. Contrairement à la clé publique, qui est destinée à être partagée, la clé privée doit rester strictement confidentielle. Voici les bonnes pratiques pour la protéger :

1. Génération locale et stockage temporaire : Le générateur utilise l’API Web Crypto de votre navigateur pour créer la paire de clés directement sur votre appareil. Aucune donnée n’est envoyée vers un serveur, ce qui élimine les risques de fuite pendant la génération. Cependant, cette approche a une contrepartie : la clé privée est perdue si vous actualisez la page ou fermez l’onglet. Il est donc impératif de la télécharger immédiatement après la génération.

2. Formats de téléchargement : Le générateur propose deux formats pour exporter la clé privée : - *JWK (JSON Web Key) : Ce format est pratique pour une intégration directe dans des applications JavaScript ou des outils comme Décodeur JWT. Cependant, il contient le paramètre d en clair, ce qui le rend vulnérable s’il est stocké sans protection. - PKCS#8 PEM : Ce format est plus universel et compatible avec la plupart des bibliothèques cryptographiques (OpenSSL, cryptography en Python, etc.). Il est également plus facile à protéger avec des outils comme GPG* ou des gestionnaires de secrets.

3. Stockage sécurisé : Une fois téléchargée, la clé privée doit être stockée dans un endroit sécurisé. Voici quelques options : - Gestionnaires de secrets : Des outils comme HashiCorp Vault, AWS Secrets Manager, ou Azure Key Vault permettent de stocker et de gérer les clés privées de manière centralisée. Ces solutions offrent des fonctionnalités avancées comme la rotation automatique des clés et l’audit des accès. - Fichiers chiffrés : Si vous préférez une solution locale, vous pouvez chiffrer le fichier contenant la clé privée avec GPG ou OpenSSL. Par exemple, pour chiffrer un fichier private_key.pem avec OpenSSL :

     openssl enc -aes-256-cbc -salt -in private_key.pem -out private_key.pem.enc

Pour le déchiffrer :

     openssl enc -d -aes-256-cbc -in private_key.pem.enc -out private_key.pem

• Environnements sécurisés : Si votre bot s’exécute dans un environnement cloud (AWS Lambda, Google Cloud Functions, etc.), utilisez les variables d’environnement chiffrées ou les services de gestion des secrets intégrés.

1. Accès restreint : Limitez l’accès à la clé privée aux seules personnes et systèmes qui en ont besoin. Appliquez le principe du moindre privilège : un développeur n’a pas besoin d’accéder à la clé privée pour tester les signatures, et un serveur de staging n’a pas besoin de la clé de production.

1. Rotation des clés : Même avec une clé privée bien protégée, il est recommandé de la remplacer périodiquement. Le générateur propose des durées de validité (30 jour, 90 jour, ou 365 jour), ce qui facilite la planification des rotations. Lorsque vous générez une nouvelle clé, publiez-la dans le répertoire /.well-known/http-message-signatures-directory avant d’expirer l’ancienne. Cela permet aux sites de basculer progressivement vers la nouvelle clé sans interruption.

1. Jamais de publication : La clé privée ne doit jamais être publiée, que ce soit dans un dépôt Git, un fichier de configuration accessible en ligne, ou un message de log. Vérifiez régulièrement que le paramètre d (dans le format JWK) ou la section PRIVATE KEY (dans le format PEM) n’apparaît pas dans des endroits non sécurisés.

1. Sauvegardes : Si vous sauvegardez la clé privée, assurez-vous que les sauvegardes sont elles aussi chiffrées et stockées dans un endroit sécurisé. Évitez les sauvegardes en clair sur des services cloud non sécurisés ou des disques durs non chiffrés.

En suivant ces bonnes pratiques, vous minimisez les risques de compromission de votre clé privée, ce qui garantit l’intégrité et la fiabilité de vos signatures Web Bot Auth. Pour aller plus loin, combinez cette approche avec des outils comme Générateur de robots.txt pour crawlers IA pour définir des règles d’accès claires via robots.txt, ou Testeur de robots.txt pour tester l’interprétation de ces règles par votre bot.

Depuis des décennies, les sites web s’appuient sur deux méthodes principales pour identifier les bots : les chaînes User-Agent et les listes d’adresses IP. Bien que ces approches soient simples à mettre en œuvre, elles présentent des limites majeures, surtout dans un contexte où les bots deviennent de plus en plus sophistiqués. Web Bot Auth, en revanche, propose une solution cryptographique qui comble ces lacunes, mais avec une complexité accrue. Voici une comparaison détaillée :

1. User-Agent : simple mais facile à falsifier Le User-Agent est une chaîne de caractères envoyée par le client pour s’identifier auprès du serveur. Par exemple, un crawler Google se présente souvent avec un User-Agent comme Googlebot/2.1.

• Avantages :
• Facile à implémenter : il suffit de lire un en-tête HTTP.
• Pas besoin de configuration serveur avancée.
• Permet de distinguer rapidement les navigateurs des bots.

• Limites :
• Falsification aisée : N’importe quel client peut envoyer un User-Agent falsifié. Par exemple, un acteur malveillant peut se faire passer pour Googlebot en modifiant simplement cette chaîne.
• Maintenance complexe : Les listes de User-Agent légitimes doivent être mises à jour régulièrement, car de nouveaux bots apparaissent constamment.
• Manque de granularité : Le User-Agent ne fournit aucune information sur les intentions du bot (crawling, scraping, test, etc.).

2. Vérification par IP : plus robuste, mais fragile Pour contrer la falsification des User-Agent, certains sites vérifient également l’adresse IP du client en la comparant à une liste d’IP connues (par exemple, les plages d’IP de Google ou de Bing).

• Avantages :
• Plus difficile à falsifier qu’un User-Agent : usurper une IP nécessite des techniques avancées comme l’usurpation d’adresse (IP spoofing), qui ne fonctionne pas pour les requêtes TCP bidirectionnelles.
• Permet de bloquer des plages d’IP entières en cas d’abus.

• Limites :
• Brittleness : Les plages d’IP des bots légitimes changent fréquemment, ce qui oblige les sites à mettre à jour leurs listes en permanence. Une IP non mise à jour peut bloquer un bot légitime ou, pire, autoriser un acteur malveillant.
• Coût opérationnel : Maintenir une liste d’IP à jour nécessite des ressources et une veille constante.
• Problèmes de confidentialité : Les adresses IP sont considérées comme des données personnelles dans de nombreuses juridictions (comme le RGPD en Europe), ce qui complique leur stockage et leur traitement.
• Limitations pour les bots distribués : Les bots modernes utilisent souvent des réseaux de proxies ou des services cloud (AWS, Google Cloud), ce qui rend la vérification par IP inefficace.

3. Web Bot Auth : une solution cryptographique moderne Contrairement aux méthodes précédentes, Web Bot Auth repose sur des signatures numériques, ce qui élimine la plupart des problèmes de falsification et de maintenance.

• Avantages :
• Preuve cryptographique : Une signature Web Bot Auth ne peut être générée que par quelqu’un possédant la clé privée correspondante. Cela rend la falsification pratiquement impossible sans compromettre la clé.
• Transparence : Les clés publiques sont publiées dans un répertoire accessible à tous (/.well-known/http-message-signatures-directory), ce qui permet aux sites de vérifier les signatures sans dépendre de listes centralisées.
• Flexibilité : Les signatures peuvent inclure des métadonnées comme un horodatage (created), une expiration (expires), ou un identifiant de clé (keyid), ce qui facilite la gestion des rotations de clés et des sessions.
• Adapté aux bots distribués : Peu importe l’IP utilisée par le bot, tant que la signature est valide, la requête est acceptée.

• Limites :
• Complexité technique : Mettre en œuvre Web Bot Auth nécessite une compréhension des concepts cryptographiques (clés publiques/privées, signatures, empreintes JWK) et une configuration serveur plus avancée.
• Dépendance aux standards : Web Bot Auth est encore au stade de brouillon à l’IETF, ce qui signifie que les spécifications pourraient évoluer avant leur adoption définitive.
• Gestion des clés : La rotation et le stockage sécurisé des clés privées ajoutent une charge opérationnelle. Une clé compromise peut permettre à un acteur malveillant de se faire passer pour votre bot.

Quand utiliser chaque méthode ? - User-Agent : Utile pour un filtrage rapide et peu critique, par exemple pour distinguer les navigateurs des bots dans des logs ou des statistiques. - Vérification par IP : Adaptée aux environnements où les bots légitimes utilisent des plages d’IP stables et connues (par exemple, les moteurs de recherche traditionnels). - Web Bot Auth : Idéal pour les bots modernes, distribués, ou nécessitant un haut niveau de confiance (par exemple, les agents IA, les crawlers d’analyse de données, ou les outils de monitoring).

Pour les opérateurs de bots souhaitant une solution à la fois sécurisée et scalable, Web Bot Auth est clairement l’option la plus prometteuse. Cependant, il est souvent judicieux de combiner plusieurs méthodes : par exemple, utiliser Web Bot Auth pour l’authentification principale, tout en maintenant une liste de User-Agent et d’IP pour les cas d’urgence ou les bots ne supportant pas encore les signatures.

Voici les réponses aux questions les plus courantes sur le Générateur de clé d’authentification Web Bot Auth et son utilisation :

Comment configurer Web Bot Auth pour mon bot ? Pour mettre en place Web Bot Auth, suivez ces trois étapes : 1. Générez une paire de clés avec le générateur. Indiquez l’origine HTTPS où sera hébergé le répertoire de clés (par exemple, https://mon-bot.com), un hôte cible pour l’exemple de signature, et une durée de validité. 2. Publiez le répertoire de clés à l’URL https://votre-domaine.com/.well-known/http-message-signatures-directory. Assurez-vous que le fichier JSON est servi avec le type MIME application/json et que la réponse est signée. 3. Signez chaque requête avec la clé privée. Utilisez les en-têtes Signature et Signature-Input pour inclure la signature, en couvrant les composants obligatoires comme @authority et signature-agent. Le générateur fournit un exemple de requête signée et une commande curl pour vous aider à démarrer.

Le générateur est-il gratuit ? Faut-il créer un compte ? Oui, le Générateur de clé d’authentification Web Bot Auth est entièrement gratuit et ne nécessite aucun compte. Aucune donnée n’est stockée sur un serveur, et la génération des clés se fait localement dans votre navigateur. Vous pouvez l’utiliser autant de fois que nécessaire, sans limitation.

*Qu’est-ce que l’identifiant de clé (key ID) et comment est-il calculé ? L’identifiant de clé (key ID) est une valeur unique qui permet d’identifier une clé publique dans le répertoire. Il est calculé comme suit : 1. La clé publique est convertie au format JWK (JSON Web Key). 2. Les paramètres du JWK sont triés par ordre alphabétique, et les valeurs sont concaténées. 3. Le résultat est haché avec l’algorithme SHA-256. 4. Le hachage est encodé en base64url* pour obtenir l’identifiant final.

Par exemple, pour une clé Ed25519, le key ID ressemble à z6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V. Cet identifiant est utilisé dans le paramètre keyid de chaque signature pour indiquer quelle clé publique doit être utilisée pour la vérification.

Pourquoi l’algorithme Ed25519 est-il utilisé ? Ed25519 est l’algorithme recommandé par les brouillons IETF de Web Bot Auth pour plusieurs raisons : - Taille réduite : Les clés Ed25519 sont plus petites que celles des algorithmes comme RSA, ce qui réduit la taille des signatures et améliore les performances. - Vitesse : Ed25519 est optimisé pour les signatures rapides, ce qui est crucial pour les bots qui envoient un grand nombre de requêtes. - Sécurité : Ed25519 offre un niveau de sécurité élevé avec une taille de clé modeste (256 bits). - Déterminisme : Contrairement à RSA, Ed25519 génère des signatures déterministes, ce qui simplifie le débogage et évite les variations inutiles.

Qu’est-ce que la base de signature ? La base de signature est le texte exact qui est signé par la clé privée pour produire la signature numérique. Elle est construite à partir des composants couverts de la requête (comme @method, @target-uri, ou signature-agent), dans un format strictement défini. Par exemple :

"@method": GET
"@target-uri": https://www.example.com/api/data
"@authority": www.example.com
"signature-agent": Web Bot Auth

La moindre différence (un espace supplémentaire, une virgule mal placée) invalidera la signature. Le générateur affiche cette base ligne par ligne, ce qui permet de la comparer avec une implémentation personnalisée pour identifier les erreurs.

Ma clé privée est-elle envoyée vers un serveur ? Non, votre clé privée n’est jamais envoyée vers un serveur. Le Générateur de clé d’authentification Web Bot Auth utilise l’API Web Crypto de votre navigateur pour générer la paire de clés directement sur votre appareil. Aucune donnée n’est transmise à un serveur externe, et la clé privée est perdue si vous actualisez la page ou fermez l’onglet. Pour conserver votre clé, vous devez la télécharger immédiatement après la génération.

J’ai actualisé la page et ma clé a disparu. Que faire ? C’est un comportement normal du générateur : aucune donnée n’est stockée localement ou sur un serveur. Si vous actualisez la page, la clé est définitivement perdue. Pour éviter cela, téléchargez toujours la clé privée (au format JWK ou PKCS#8 PEM) immédiatement après la génération. Si vous avez perdu votre clé, vous devrez en générer une nouvelle et republier le répertoire de clés.

Mon navigateur ne parvient pas à générer les clés, ou mon origine est rejetée. Pourquoi ? Plusieurs raisons peuvent expliquer ce problème : - Navigateur incompatible : L’API Web Crypto et l’algorithme Ed25519 ne sont pas supportés par tous les navigateurs. Assurez-vous d’utiliser une version récente de Chrome, Firefox, ou Safari. - Origine invalide : L’origine que vous avez saisie doit être une URL HTTPS valide, sans chemin ni fragment. Par exemple, https://mon-bot.com est valide, mais https://mon-bot.com/chemin ou http://mon-bot.com ne le sont pas. - Problème de certificat SSL : Si votre origine utilise un certificat SSL auto-signé ou invalide, le générateur peut la rejeter. Utilisez un certificat valide émis par une autorité reconnue.

Faut-il choisir une durée de validité pour la clé ou opter pour une clé sans expiration ? Le choix dépend de votre tolérance au risque et de votre capacité à gérer les rotations de clés : - Clé sans expiration : Plus simple à gérer, mais si la clé est compromise, elle peut être utilisée indéfiniment par un acteur malveillant. Cette option est adaptée aux environnements où la rotation des clés est difficile à automatiser. - Clé avec expiration : Plus sécurisée, car une clé compromise ne peut être utilisée que pendant une durée limitée. Cependant, cela nécessite de planifier et d’automatiser la rotation des clés. Les durées proposées par le générateur (30 jour, 90 jour, 365 jour) permettent de trouver un équilibre entre sécurité et maintenance.

Pour les bots critiques, il est recommandé d’utiliser une clé avec expiration et de mettre en place un processus de rotation automatique.