FR 3145253 A1 20240726 FR 2300702 A 20230125 Procédé de révocation d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants L’invention concerne une solution permettant de révoquer un certificat fourni à un équipement dans un environnement de type « edge computing ». Les solutions d’authentification existantes, ne sont pas bien adaptées au contexte du « edge computing » car elles ne peuvent répondre aux besoins que requiert la gestion de ces équipements qui peuvent être déployés dans des infrastructures distribuées mais qui surtout peuvent être reconfigurés, suspendus, supprimés, rétablis, voire réaffectés à un autre nœud maitre en fonctions des besoins à satisfaire. La solution objet de la présente invention, permet, en réutilisant des composants déjà présents dans un réseau de communication, de révoquer un certificat dont l’intégrité ne saurait être remise en cause puisque le tiers de confiance émetteur du certificat est l’opérateur gestionnaire du réseau de communication. FIGURE 5 Procédé de révocation d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants Domaine de l'invention Le domaine de l'invention est celui de la certification d’un équipement raccordé à un réseau de communication. Plus précisément, l'invention concerne une solution de gestion de la révocation d’un certificat associé à un équipement dans un environnement de type « edge computing » ou informatique en périphérie de réseau. Art antérieur et ses inconvénients Une nouvelle étape du développement du « cloud computing », ou informatique en nuage, a vu le jour ces dernières années. Ce nouveau développement est nommé « edge computing » ou informatique en périphérie de réseau et consiste à traiter les données à la périphérie du réseau au plus près de la source des données. L’« edge computing » permet ainsi de minimiser les besoins en bande passante entre des équipements, tels que des capteurs, et les centres de traitement des données en entreprenant les analyses au plus près des sources de données. Cette approche nécessite la mobilisation de ressources qui peuvent ne pas être connectées en permanence à un réseau, tels que des ordinateurs portables, des smartphones, des tablettes ou des capteurs. L’« edge computing » a aussi une place de choix dans les solutions d’ingestion et de livraison de contenus. A cet égard, de nombreuses architectures de réseaux de livraison de contenus ou CDN ( Content Delivery Network ) reposent sur des architectures de type « edge computing ». Une mise en œuvre connue d’une telle architecture de type « edge computing » est une architecture connue sous l’appellation Kubernetes. La présente de manière simplifiée l’architecture d’une grappe de nœuds 1 conforme à la solution Kubernetes. La grappe de nœuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « workers node », 11 i , i , N étant un entier naturel. Le nœud de gestion 10 comprend un contrôleur 101, un module API ( Application Programming Interface ou interface de programmation d’applications) 102 et une base de données 103 dite ETCD (nom de la base de données principale de Kubernetes, stockant les configurations des systèmes ou clusters de machines distribués) qui consiste en un registre dynamique de configuration des nœuds de calculs 11 i . Un nœud de calcul 11 i comprend M conteneurs ou « pods » 110 j , j , M étant un entier naturel. Chaque conteneur 110 j est doté de ressources permettant l’exécution d’une ou de plusieurs tâches. Une tâche lorsqu’elle est exécutée contribue à la mise en œuvre d’un service ou d’une fonction réseau, telle qu’une fonction DHCP ( Dynamic Host Configuration Protocol ou protocole de configuration dynamique des hôtes) par exemple. Dans un souci de réduction des coûts et d’amélioration de la flexibilité des infrastructures réseaux, les architectures d’« edge computing » sont le plus souvent des architectures multi-sites dans lesquelles les nœuds constitutifs des grappes de nœuds peuvent être non co-localisés. Par exemple un nœud de gestion 10 et deux nœuds de calcul 11 1 , 11 2 d’une grappe de nœuds 1 sont situés sur un site A alors que trois autres nœuds de calculs 11 3 , 11 4 , 11 5 sont quant à eux situés sur un site B distant. Les solutions d’authentification existantes, telles que le protocole https ( HyperText Transfer Protocol Secure ou protocole de transfert hypertextuel sécurisé) qui repose sur l’introduction d’une couche de chiffrement conforme à la famille de protocoles TLS ( Transport Layer Security ou sécurité de la couche transport) ne sont pas bien adaptées au contexte du « edge computing ». Cette famille comporte les protocoles SSL (Secure Socket Layer ou sécurité de la couche socket), les variantes de TLS, cTLS, QUIC, MASQUE, DTLS, LAKE EDDOC, TLS sur COAP…), etc. Le protocole https permet à un équipement d’un visiteur, tel qu’un ordinateur personnel, de vérifier l'identité d’un site internet auquel le visiteur souhaite accéder à partir de son équipement. Ainsi, l’équipement vérifie l’identité d’un serveur hébergeant le site internet, grâce à un certificat public d'authentification de type X509 émis par une autorité tierce, réputée fiable, à un serveur fournissant un service. Un tel certificat garantit la confidentialité et l'intégrité des données transmises par le visiteur à destination du serveur fournissant un service. Un tel mode de fonctionnement, à savoir la vérification de l’identité d’un équipement avec lequel une session de communication est destinée à être établie, ne peut répondre aux besoins que requiert la gestion des nœuds de calculs. En effet une telle gestion s’avère complexe car les nœuds de calculs peuvent être déployés dans des infrastructures distribuées, voire privées ou même mobiles, mais surtout ils peuvent être reconfigurés, suspendus, supprimés, rétablis, voire réaffectés à une autre grappe de nœuds en fonctions des besoins à satisfaire. Chacune de ces opérations peut remettre en cause la validité des certificats associés aux nœuds de calculs. De plus, les nœuds de calculs correspondent, d’un point de vue protocolaire, à l’équipement visiteur décrit dans l’exemple décrit ci-dessus. On voit, par conséquent, que l’application de la solution https à une architecture de « edge computing » n’est pas adaptée. Il existe donc un besoin de proposer une solution de gestion des équipements appartenant à une architecture de type « edge computing » ne présentant pas tout ou partie des inconvénients précités. L'invention répond en partie à ce besoin en proposant un procédé de révocation d’un premier jeton de certification correspondant à un premier certificat, ledit premier jeton de certification permettant d’authentifier l’établissement d’une connexion entre un équipement raccordé à au moins un réseau de communication et au moins un serveur d’un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés à partir d’un condensé d’une adresse physique dudit équipement, d’un certificat associé à un serveur de configuration d’adresses réseau et d’au moins une adresse réseau allouée audit équipement par ledit serveur de configuration d’adresses réseau. Un tel procédé est particulier en ce qu’il comprend les étapes suivantes mises en œuvre par un module de gestion de certificats : - révocation dudit premier jeton de certification déclenchée par l’obtention d’une information relative à une condition de révocation dudit premier jeton de certification , -transmission, à destination d’un serveur de noms de domaines, d’une demande de révocation d’une association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part au moins un nom de domaine La solution objet de la présente invention, permet de révoquer un certificat de manière systématique lorsque l’équipement est reconfiguré, lorsque son certificat est suspendu, corrompu, lorsqu’un bail associé à l’adresse réseau allouée à l’équipement arrive à expiration ou encore lorsqu’une association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part au moins un nom de domaine arrive elle-aussi à expiration. La présente solution propose de révoquer un jeton de certification correspondant à un certificat associé à l’équipement permettant de réduire le nombre des échanges relatifs à la gestion de ce certificat pour un tel équipement ce qui est particulièrement intéressant dans un contexte de « edge computing » où l’agilité est de rigueur. Un tel module de gestion de certificat peut être co-localisé avec le serveur de configuration ou avec le serveur de noms de domaines, dans lequel une association dudit certificat avec au moins un nom de domaine fourni par le serveur de configuration est mémorisée. Enfin, sachant que l’équipement peut se voir allouer une pluralité d’adresses réseau, ou "pool d'adresses", le premier jeton de certification est associé à tout ou partie de ce pool d’adresses. De la même manière, un même équipement peut disposer simultanément de plusieurs certificats et des jetons de certification correspondant. Un tel jeton de configuration permet de vérifier l’authenticité et l’intégrité d’un certificat associé à l’équipement et ainsi autoriser l’établissement d’une connexion avec l’équipement. L’établissement d’une telle connexion correspond par exemple à l’intégration de l’équipement dans une architecture Kubernetes en tant que nœud de calcul. Selon une particularité du procédé de révocation, ladite condition de révocation dudit premier jeton de certification appartient à un groupe comprenant : - une demande de révocation dudit premier jeton de certification, ladite demande de révocation étant émise par l’équipement, - une demande de révocation dudit premier jeton de certification, ladite demande de révocation étant émise par un équipement du réseau - une expiration d’une durée d’allocation de l’adresse réseau allouée à l’équipement, - une expiration d’une durée de vie du premier jeton de certification, - un conflit d’usage dans un plan d’adressage, - une information relative à une compromission du premier jeton de certification, - une information relative à un piratage du premier jeton de certification. Dans un exemple d’implémentation, lorsque l’information relative à une condition de révocation dudit premier certificat est une information relative à l’expiration de la durée de l’association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part au moins un nom de domaine, le procédé de révocation comprend préalablement à l’étape de révocation du premier jeton de certification, les étapes suivantes de : - transmission d’une demande de révocation d’une association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part le serveur de configuration d’adresses réseau, - réception d’une demande de révocation dudit premier jeton de certification émise par ledit serveur de configuration d’adresses réseau suite à la révocation de l’association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part le serveur de configuration d’adresses réseau. Dans un tel exemple d’implémentation, la révocation du jeton de certification intervient lorsqu’une résolution du nom de domaine est requise. Ceci contribue à réduire la charge du réseau de communication. Une fois le jeton de certification révoqué, le procédé de révocation met en œuvre une étape de transmission, à destination du serveur de configuration d’adresses réseau, d’un message d’acquittement de la révocation dudit premier jeton de certification par le module de gestion de certificats. Ainsi, le serveur de configuration d’adresses réseau peut libérer l’adresse réseau associée à l’équipement dont le jeton de certification vient d’être révoqué. Le procédé de révocation peut également comprendre les étapes suivantes lorsque la condition de révocation dudit premier jeton de certification est assortie d’une demande de remplacement dudit premier jeton de certification : - génération d’un deuxième certificat associé audit équipement et d’un deuxième jeton de certification correspondant, - transmission, à destination dudit serveur de noms de domaines, d’une demande d’association dudit deuxième certificat et dudit deuxième jeton de certification audit nom de domaine précédemment associé au premier certificat et au premier jeton de certification correspondant, - transmission dudit deuxième jeton de certification à destination dudit équipement. Un tel exemple présente un intérêt quand la validité du jeton de certification arrive à expiration mais aussi lorsque le certificat associé à l’équipement est corrompu ou a été piraté. Dans un tel cas de figure, la connexion établie entre l’équipement et le serveur du fournisseur de service est maintenue et le deuxième jeton de certification est transmis à l’équipement au travers de cette connexion rendant l’opération transparente pour un utilisateur de l’équipement. La génération de ce deuxième jeton de certification en remplacement du premier jeton de certification active un mécanisme spécifique de gestion de la connexion comme la surveillance de l’utilisation de ce deuxième jeton de certification dont le but est de suivre et d’examiner les échanges intervenant entre l’équipement et le serveur du fournisseur de services afin de déterminer le caractère corrompu de la connexion. Cela se traduit par exemple par un ralentissement des échanges initiés par le serveur au travers de la connexion afin de maintenir celle-ci active plus longtemps afin de pouvoir l’observer sur une durée plus longue. Toujours dans cet exemple, le deuxième jeton de certification peut également offrir un accès restreint aux ressources du serveur d’un fournisseur de services. Ainsi, le deuxième jeton de certification contribue à la mise en place d’une « sandbox » en limitant l’accès de l’équipement à certains services ou en isolant le trafic lié à ce service à destination ou en provenance de l’équipement. Afin d’isoler encore davantage le trafic lié à l’équipement, le procédé comprend en outre une étape d’émission, à destination du serveur de configuration d’adresses réseau, d’une demande de fourniture, audit équipement, d’au moins une adresse réseau pointant vers une machine hôte agissant comme un serveur fictif du fournisseur. Dans ce cas de figure, l’adresse réseau fournie à l’équipement est une adresse réseau dite « black hole » qui ne permet pas l’acheminement du trafic vers l’équipement ou ne permet pas la transmission du trafic depuis l’équipement vers le serveur du fournisseur de services mais indique à un routeur que ce trafic peut être acheminé vers un autre équipement dédié adapté à traiter des données issues de/destinées à un équipement potentiellement corrompu, ou que ce trafic peut ne pas être acheminé du tout. L’invention concerne également un module de gestion de certificats adapté pour révoquer un premier jeton de certification correspondant à un premier certificat, ledit premier jeton de certification permettant d’authentifier l’établissement d’une connexion entre un équipement raccordé à au moins un réseau de communication et au moins un serveur d’un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de gestion de certificats à partir d’un condensé d’une adresse physique dudit équipement, d’un certificat associé à un serveur de configuration d’adresses réseau et d’au moins une adresse réseau allouée audit équipement par ledit serveur de configuration d’adresses réseau, ledit module de gestion de certificats comprenant au moins un processeur configuré pour : - révoquer ledit premier jeton de certification suite à l’obtention d’une information relative à une condition de révocation dudit premier jeton de certification , -transmettre, à destination d’un serveur de noms de domaines, une demande de révocation d’une association établie entre le premier certificat, le premier jeton de certification et au moins un nom de domaine. L’invention a encore pour objet un serveur de configuration d’adresses réseau comprenant au moins un module de gestion de certificats adapté pour révoquer un premier jeton de certification correspondant à un premier certificat, ledit premier jeton de certification permettant d’authentifier l’établissement d’une connexion entre un équipement raccordé à au moins un réseau de communication et au moins un serveur d’un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de gestion de certificats à partir d’un condensé d’une adresse physique dudit équipement, d’un certificat associé audit serveur de configuration d’adresses réseau et d’au moins une adresse réseau allouée audit équipement par ledit serveur de configuration d’adresses réseau, ledit module de gestion de certificats comprenant au moins un processeur configuré pour : - révoquer ledit premier jeton de certification suite à l’obtention d’une information relative à une condition de révocation dudit premier jeton de certification , -transmettre, à destination d’un serveur de noms de domaines, une demande de révocation d’une association établie entre le premier certificat, le premier jeton de certification et au moins un nom de domaine. L’invention concerne enfin un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé tel que décrit précédemment, lorsqu’il est exécuté par un processeur. L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé selon l’invention tel que décrit ci-dessus. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé objet de l’invention précité. Liste des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : : cette figure représente de manière simplifiée l’architecture d’une grappe de nœuds 1 conforme à la solution Kubernetes, : cette figure représente un système dans lequel la présente solution peut être mise en œuvre, : cette figure représente les différentes étapes mises en œuvre lors de l’exécution d’un premier mode de réalisation des procédés objets de la présente invention conduisant à l’obtention du jeton de certification au sein du système de la , : cette figure représente les différentes étapes mises en œuvre lors de l’exécution d’un deuxième mode de réalisation des procédés objets de la présente invention conduisant à l’obtention du jeton de certification au sein du système de la , : cette figure représente la suite des étapes des procédés relatifs à l’utilisation du jeton de certification CNT par un équipement appartenant au système de la , : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la dans un premier mode de réalisation du procédé de révocation d’un jeton de certification selon l’invention, : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la dans un deuxième mode de réalisation du procédé de révocation d’un jeton de certification selon l’invention, : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la dans un troisième mode de réalisation du procédé de révocation d’un jeton de certification selon l’invention, : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la dans un quatrième mode de réalisation du procédé de révocation d’un jeton de certification selon l’invention, : cette figure représente un équipement apte à mettre en œuvre le procédé d’établissement authentifié d’une connexion entre un équipement raccordé à au moins un réseau de communication et un serveur d’un fournisseur de services objet de la présente invention, : cette figure représente un module de gestion apte à mettre en œuvre les différents procédés objets de la présente invention. Description détaillée de modes de réalisation de l’invention Le principe général de l'invention concerne la gestion d’un certificat, notamment mais non exclusivement, pour un équipement localisé dans un environnement de type « edge computing » ou informatique en périphérie de réseau au cours du fonctionnement dudit équipement. L’invention propose un mécanisme de révocation d’un jeton de certification correspondant à un certificat associé audit équipement. Ce mécanisme de révocation permet de révoquer un certificat associé à l’équipement par exemple lorsque l’équipement est reconfiguré, lorsque son certificat est suspendu, corrompu, lorsqu’un bail associé à l’adresse réseau allouée à l’équipement arrive à expiration ou encore lorsqu’une association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part au moins un nom de domaine arrive elle-aussi à expiration, etc. Une telle solution présente l’avantage d’être rapide ce qui la rend particulièrement intéressante pour des architectures nécessitant des configurations dynamiques fréquentes. En effet, cela permet de réduire le nombre des échanges et la quantité de traitements relatifs à la gestion de ce certificat pour un tel équipement ce qui est particulièrement intéressant dans un contexte de « edge computing » où l’agilité est de rigueur. On présente désormais, en relation avec la un système dans lequel la présente solution peut être mise en œuvre. Un tel système comprend au moins un équipement 10 raccordé à au moins un réseau de communication (non représenté sur les figures), au moins un serveur de configuration d’adresses réseau 11, tel qu’un serveur DHCP ( Dynamic Hosts Configuration Protocol ou protocole de configuration dynamique d’hôtes), au moins un module de gestion de certificats 12, au moins un serveurs de noms de domaines 13 tel qu’un serveur DNS et au moins un serveur d’un fournisseur de services 14 indépendant, ou non, de l'opérateur du réseau de communication. L’équipement 10 peut aussi bien être un terminal mobile, qu’un serveur, qu’un nœud , ou un conteneur selon la solution Kubernetes, ou encore un capteur. Il peut s’agir également d’un équipement virtualisé. Dans la suite du document, le serveur de configuration 11 à pour identifiant ‘srvcfg11’ et appartient à un réseau de communication dont le nom de domaine est ‘example.com’, le « Common Name » CN ou le « Fully Qualified Domain Name » FQDN associé au certificat CertDHCP du serveur de configuration 11 est ‘srvcfg11.example.com’. Dans un exemple d’implémentation, le serveur de configuration 11 et le module de gestion de certificats 12 peuvent être co-localisés dans un même équipement 100 comme représenté sur la . Dans un autre exemple d’implémentation, le module de gestion de certificats 12 peut être co-localisé avec le serveur de noms de domaines 13 ou intégré dans celui-ci. Dans encore un autre exemple d'implémentation, le module de gestion de certificats 12 peut être séparé physiquement du serveur de configuration 11 et du serveur de noms de domaines 13. En référence au système décrit à la , on décrit maintenant une première partie du déroulement des procédés conduisant à l’obtention d’un tel jeton de certification puis du procédé de révocation du jeton de certification objet de l’invention. Les différentes étapes mises en œuvre lors de l’exécution d’un premier mode de réalisation des procédés conduisant à l’obtention du jeton de certification au sein du système précédemment décrit sont représentées sous forme de diagramme dans la . Dans une étape E1, l’équipement 10 cherche à se connecter à un réseau de communication. A cette fin, l’équipement 10 envoie une requête DHCP Discover à destination du serveur de configuration 11 afin que ce dernier lui alloue une ou plusieurs adresses réseau telle que des adresses IPv4 ou IPv6. Dans une étape E2, à réception de la requête DHCP Discover émise par l’équipement 10, le serveur de configuration 11 propose, de manière classique, une ou plusieurs adresses réseau à l’équipement 10 via l’émission d’un message de type DHCP offer. Dans un autre exemple, le serveur de configuration 11 peut mettre en œuvre une méthode de délégation de type ACME-STAR ou une méthode dite “ Delegated Credentials ” à la réception de la requête DHCP Discover émise par l’équipement 10. Ces méthodes sont décrites dans le document référencé Acme-Star RFC 8739 publié par l’IETF. Elles permettent ainsi à l’équipement délégataire 10 de recevoir, ici dans un message de type DHCP Offer , un certificat temporaire éventuellement condensé calculé sur la base d’une clé privée du serveur de configuration délégant 11. Dans une étape E3, l’équipement 10 valide la proposition d’allocation d’adresses réseau reçue au cours de l’étape E2 et transmet, au serveur de configuration 11, une requête DHCP Request validant des adresses réseau parmi celles proposées et comprenant des paramètres relatifs à la création d’un certificat. De tels paramètres comprennent entre autres : une clé publique PUB_KEY_CPE de l’équipement 10, un condensé ou « hash » HASH_CPE d’une adresse physique de l’équipement 10 telle qu’une adresse MAC ( Medium Access Control ou contrôle d’accès au support) ainsi qu'un paramètre TYP_HASH sur la manière dont le condensé HASH_CPE est calculé. Ces différents paramètres peuvent être transmis sous forme d’un certificat pouvant être condensé. A réception de la requête DHCP Request , dans une étape E4, le serveur de configuration 11 traite les informations relatives à l’allocation d’adresses réseau comprises dans cette requête de manière classique. Lors du traitement de cette requête DHCP Request, le serveur de configuration 11 détectant la présence de paramètres relatifs à la création d’un certificat dans un champ de la requête DHCP Request , c’est-à-dire la clé publique PUB_KEY_CPE, le condensé HASH_CPE ou le paramètre TYP_HASH, extrait ces informations et génère une demande de création d’un certificat DCC associé à l’équipement 10. La demande de création d’un certificat DCC comprend : la clé publique PUB_KEY_CPE de l’équipement 10, le condensé HASH_CPE d’une adresse physique de l’équipement 10, un certificat CertDHCP associé au serveur de configuration 11, au moins une adresse réseau IP_CPE allouée audit équipement 10 par le serveur de configuration 11 au cours de l’étape E4 (ou un pool d’adresses réseau POOL_IP_CPE allouées à l’équipement 10), et enfin le paramètre TYP_HASH sur la manière dont le condensés HASH_CPE est calculé. La demande de création d’un certificat DCC peut aussi comprendre un nom de domaine, par exemple « 4d2a.37f78dd8d99b3c75ddde3624155.example.com », avec lequel le certificat est destiné à être associé. Dans une étape E5, le serveur de configuration transmet la demande de création d’un certificat DCC au module de gestion de certificats 12. A réception de la demande de création d’un certificat associé à l’équipement 10, le module de gestion de certificats 12 génère, au cours d’une étape E6, un certificat CERT_CPE associé à l’équipement 10 à partir des informations comprises dans la demande de création DCC. Un tel certificat CERT_CPE correspond à une adresse réseau allouée à l’équipement 10. Ainsi, le module de gestions de certificats 12 crée autant de certificats CERT_CPE associés à l’équipement 10 que celui-ci a d’adresses réseau. Dans un autre exemple d’implémentation, le module de gestions de certificats 12 crée un unique certificat CERT_CPE associé à l’équipement 10 qui s’applique au pool d’adresses réseau POOL_IP_CPE alloué à l’équipement 10. Un tel certificat CERT_CPE inclue les valeurs de l'adresse physique de l’équipement 10 et d'une ou plusieurs adresses réseau choisies au cours de l’étape E3 par l’équipement 10, dans des champs du certificat CERT_CPE tels que les champs Common Name (CN) ou SAN par exemple. Le module de gestion de certificats 12 génère également un jeton de certification CNT ( Certificat Network Token ) correspondant au certificat CERT_CPE associé à la connectivité de l’équipement 10 au réseau de 11. Un tel jeton de certification CNT est une forme compacte du certificat CERT_CPE associé à l’équipement 10. Plus particulièrement, ce jeton de certification CNT comprend entre autres des informations relatives au condensé HASH_CPE de l’adresse physique de l’équipement 10, au condensé HASH_CERT_CPE du certificat CERT_CPE associé à l’équipement 10, et un identifiant CN_CM du module de gestion de certificats 12.C’est le jeton de certification CNT ou un condensé HASH_CNT du jeton de certification CNT qui sera utilisé par l’équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d’authentification pour accéder à un service. Le jeton de certification CNT étant une forme compacte du certificat CERT_CPE associé à l’équipement 10, il peut être introduit dans de nombreux messages existant sans augmenter la charge utile de ces derniers de manière préjudiciable. Afin de limiter encore la charge utile des messages existants, l’équipement 10 peut transmettre le condensé du jeton de certification HASH_CNT en lieu et place du jeton de certification CNT. Ainsi, l’implémentation de la solution objet de la présente invention n’introduit pas une charge trop lourde dans un réseau de communication. Le condensé du jeton de certification HASH_CNT est calculé au moyen d’un paramètre TYP_HASH_CNT. Dans la suite du document, le condensé du jeton de certification HASH_CNT a pour valeur a pour valeur « 37f78dd8d99b3c75ddde3624155 », et le paramètre TYP_HASH_CNT a pour valeur 4D2A. Ainsi, par exemple, le jeton de certification CNT correspondant au certificat CERT_CPE de l’équipement 10 a pour valeur « 4D2A.37f78dd8d99b3c75ddde3624155 », et le champ Common Name (CN) du certificat CERT_CPE de l’équipement 10 comprend les valeurs « 4D2A .37f78dd8d99b3c75ddde3624155.srvcfg1.example.com ». Dans une étape E7, le module de gestions de certificats 12 transmet une demande d’association DAss du certificat CERT_CPE associé à l’équipement 10 ainsi généré avec le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » avec lequel le certificat CERT_CPE est destiné à être associé à destination du serveur de noms de domaines 13. Une telle demande d’association DAss comprend : le certificat CERT_CPE associé à l’équipement 10, le jeton de certification CNT correspondant, un condensé HASH_CNT du jeton de certification CNT et un paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Dans un exemple de réalisation, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé peut comprendre une clé publique du module de gestion de certificats 12. Dans une étape E8, le serveur de noms de domaines 12 enregistre l’ensemble des informations comprises dans la demande d’association DAss dans une table et les associe au nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com ». Optionnellement, une fois l’association entre l’ensemble des informations comprises dans la demande d’association DAss et le nom de domaine effectuée, le serveur de noms de domaines 13 en informe le module de gestion de certificats 12 dans une étape E9. A son tour, le module de gestion de certificats 12 informe le serveur de configuration 11 de la création du certificat CERT_CPE associé à l’équipement 10 dans une étape E10. Pour cela, le module de gestion de certificats 12 transmet au serveur de configuration 11 un message MSG1 comprenant le jeton de certification CNT correspondant au certificat CERT_CPE associé à l’équipement 10, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Une telle étape E10 est optionnelle. Enfin, le serveur de configuration 11 envoie, dans une étape E11, un message d’affectation d’une adresse réseau ou de mise à jour , par exemple DHCP ‘renew’, ou un nouveau message DHCP ‘update’, contenant le CNT. Dans un champ existant ou nouveau de ce message DHCP , le serveur de configuration 11 ajoute le jeton de certification CNT correspondant au certificat CERT_CPE associé à l’équipement 10, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Dans un autre exemple de mise en œuvre de l’étape E11, le serveur de configuration 11 transmet seulement le condensé du jeton de certification HASH_CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé dans le message d’affectation. A l’issue de l’étape E11, l’équipement 10 dispose ainsi d’un jeton de certification CNT qui sera utilisé par l’équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d’authentification pour accéder à un service. On remarquera que l’équipement 10 n’est pas en possession de son certificat CERT_CPE et ne connaît pas le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » associé à son certificat CERT_CPE. Ces deux informations ne sont mémorisées que dans le serveur de nom de domaines 12. En référence au système décrit à la , on décrit maintenant une première partie du déroulement des procédés conduisant à l’obtention d’un tel jeton de certification puis du procédé de révocation du jeton de certification objet de l’invention. Les différentes étapes mises en œuvre lors de l’exécution d’un deuxième mode de réalisation des procédés conduisant à l’obtention du jeton de certification au sein du système précédemment décrit sont représentées sous forme de diagramme dans la . Dans une étape E1’, l’équipement 10 cherche à se connecter à un réseau de communication. A cette fin, l’équipement 10 envoie une requête DHCP Discover à destination du serveur de configuration 11 afin que ce dernier lui alloue une ou plusieurs adresses réseau telle que des adresses IPv4 ou IPv6. La requête DHCP Discover comprend des paramètres relatifs à la création d’un certificat. De tels paramètres comprennent entre autres : une clé publique PUB_KEY_CPE de l’équipement 10, un condensé ou « hash » HASH_CPE d’une adresse physique de l’équipement 10 telle qu’une adresse MAC ( Medium Access Control ou contrôle d’accès au support) ainsi qu'un paramètre TYP_HASH sur la manière dont le condensé HASH_CPE est calculé. Ces différents paramètres peuvent être transmis sous forme d’un certificat pouvant être condensé. Dans une étape E2’ le serveur de configuration 11 sélectionne au moins une adresse réseau à allouer audit équipement 10 et met en œuvre une méthode de délégation de type ACME-STAR ou une méthode dite “ Delegated Credentials ” dès la réception de la requête DHCP Discover émise par l’équipement 10. De telles méthodes sont décrites dans les documents référencés Acme-Star RFC 8739 et « draft-ietf-tls-subcerts-15 - Delegated Credentials for (D)TLS » publiés par l’IETF. A réception de la requête DHCP Request , dans une étape E3’, le serveur de configuration 11 traite les informations relatives à l’allocation d’adresses réseau comprises dans cette requête de manière classique. Lors du traitement de cette requête DHCP Request, le serveur de configuration 11 détectant la présence de paramètres relatifs à la création d’un certificat dans un champ de la requête DHCP Request , c’est-à-dire la clé publique PUB_KEY_CPE, le condensé HASH_CPE et le paramètre TYP_HASH, extrait ces informations et génère un certificat CERT_CPE associé à l’équipement 10 sur la base de ces informations. Un tel certificat CERT_CPE correspond à une adresse réseau allouée à l’équipement 10. Ainsi, le serveur de configuration 11 crée autant de certificats CERT_CPE associés à l’équipement 10 que celui-ci a d’adresses réseau. Dans un autre exemple d’implémentation, le serveur de configuration 11 crée un unique certificat CERT_CPE associé à l’équipement 10 qui s’applique au pool d’adresses réseau POOL_IP_CPE alloué à l’équipement 10. Un tel certificat CERT_CPE inclue les valeurs de l'adresse physique de l’équipement 10 et d'une ou plusieurs adresses réseau sélectionnées au cours de l’étape E3’ par serveur de configuration 11, dans un champ du certificat CERT_CPE tels que le champ SAN par exemple. Le serveur de configuration 11 génère également un jeton de certification CNT ( Certificat Network Token ) correspondant au certificat CERT_CPE associé à la connectivité de l’équipement 10 au réseau de communication. Un tel jeton de certification CNT est une forme compacte du certificat CERT_CPE associé à l’équipement 10. Plus particulièrement, ce jeton de certification CNT comprend entre autres des informations relatives au condensé HASH_CPE de l’adresse physique de l’équipement 10, au condensé HASH_CERT_CPE du certificat CERT_CPE associé à l’équipement 10, et un identifiant CN_DHCP du serveur de configuration 11. Le serveur de configuration 11 détermine également un condensé du jeton de certification HASH_CNT au moyen d’un paramètre TYP_HASH_CNT. Comme déjà précisé, le condensé du jeton de certification HASH_CNT a pour valeur a pour valeur « 37f78dd8d99b3c75ddde3624155 », et le paramètre TYP_HASH_CNT a pour valeur 4D2A. Ainsi, par exemple, le jeton de certification CNT correspondant au certificat CERT_CPE de l’équipement 10 a pour valeur « 4D2A.37f78dd8d99b3c75ddde3624155 », et le champ Common Name (CN) du certificat CERT_CPE de l’équipement 10 comprend les valeurs « 4D2A .37f78dd8d99b3c75ddde3624155.srvcfg1.example.com ». C’est le jeton de certification CNT ou un condensé HASH_CNT du jeton de certification CNT qui sera utilisé par l’équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d’authentification pour accéder à un service. Le jeton de certification CNT étant une forme compacte du certificat CERT_CPE associé à l’équipement 10, il peut être introduit dans de nombreux messages existant sans augmenter la charge utile de ces derniers de manière préjudiciable. Afin de limiter encore la charge utile des messages existants, l’équipement 10 peut transmettre le condensé du jeton de certification HASH_CNT en lieu et place du jeton de certification CNT. Ainsi, l’implémentation de la solution objet de la présente invention n’introduit pas une charge trop lourde dans un réseau de communication. Dans une étape E4’, le serveur de configuration 11 transmet le certificat CERT_CPE ainsi créé au module de gestion de certificats 12 accompagné de son jeton de certification CNT, du condensé HASH_CNT du jeton de certification CNT, du paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé et d’un certificat CertDHCP associé au serveur de configuration 11. La transmission du certificat CERT_CPE peut aussi comprendre un nom de domaine, par exemple « 4d2a.37f78dd8d99b3c75ddde3624155.example.com », avec lequel le certificat est destiné à être associé. Le serveur de configuration 11 émet, au cours d’une étape E5’ qui peut être mise en œuvre préalablement, concomitamment ou après l’étape E4’, un message de type DHCP Offer à destination de l’équipement 10 comprenant le jeton de certification CNT correspondant ainsi que la ou les adresses réseaux que le serveur de configuration 11 lui a alloué au cours de l’étape E3’. Dans une étape E6’, le module de gestions de certificats 12 transmet une demande d’association DAss du certificat CERT_CPE associé à l’équipement 10 avec le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » avec lequel le certificat CERT_CPE est destiné à être associé à destination du serveur de noms de domaines 13. Une telle demande d’association DAss comprend : le certificat CERT_CPE associé à l’équipement 10, le jeton de certification CNT correspondant, du condensé HASH_CNT du jeton de certification CNT et du paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Dans un exemple de réalisation, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé peut comprendre une clé publique du serveur de configuration 11. Dans une étape E7’, le serveur de noms de domaines 13 enregistre l’ensemble des informations comprises dans la demande d’association DAss dans une table et les associe au nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com ». Optionnellement, une fois l’association entre l’ensemble des informations comprises dans la demande d’association DAss et le nom de domaine effectuée, le serveur de noms de domaines 13 en informe le module de gestion de certificats 12 dans une étape E8’. A son tour, le module de gestion de certificats 12 informe le serveur de configuration 11 l’association entre l’ensemble des informations comprises dans la demande d’association DAss et le nom de domaine dans une étape E9’. A l’issue de l’étape E9’, l’équipement peut utiliser le jeton de certification CNT dans toutes les situations où ce dernier devra fournir du matériel d’authentification pour accéder à un service. On remarquera que l’équipement 10 n’est pas en possession de son certificat CERT_CPE et ne connaît pas le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » associé à son certificat CERT_CPE. Ces deux informations ne sont mémorisées que dans le serveur de nom de domaines 12. Maintenant que l’équipement 10 est doté d’un jeton de certification CNT et/ou d’un condensé du jeton de certification HASH_CNT, il peut établir une connexion avec un serveur d’un fournisseur de services 14. La représente la suite des étapes des procédés relatifs à l’utilisation du jeton de certification CNT par l’équipement 10. L’équipement 10 souhaitant établir une connexion avec le serveur d’un fournisseur de services 14 transmet à ce dernier un message client Hello TLS au cours d’une étape G1. Dans un champ existant de ce message client Hello TLS , ou dans une extension TLS_CNT, l’équipement 10 ajoute le jeton de certification CNT, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. En pratique le jeton de certification CNT peut être transporté par tout protocole d’échange sécurisé de la famille de TLS ou autre, dans un champ de tout protocole applicatif comme HTTP transporté au-dessous de toute combinaison de protocoles garantissant l’intégrité de l’échange, mais également dans un champ OAM (iOAM) décrit dans https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-17.txt. Ainsi le jeton de certification CNT peut être transporté, voir mis à jour à n’importe quel moment de la vie d’une session d’échange entre 10 et 14. Dans une étape G2, le serveur d’un fournisseur de services 14 obtient la clé publique PUB_KEY_CM du module de gestion de certificats 12. La clé publique PUB_KEY_CM est par exemple un champ public du certificat X509 du module de gestion de certificats 12 obtenu, après l'étape G1 ou préalablement, par exemple à l’établissement d’un tunnel sécurisé établi entre le serveur d’un fournisseur de services 14 et le module de gestion de certificats 12, ou encore pré-enregistré dans le serveur d’un fournisseur de services 14. A l’aide de la clé publique PUB_KEY_CM du module de gestion de certificats 12, le serveur d’un fournisseur de services 14 procède, au cours d’une étape G3, à la vérification de l’authenticité du jeton de certification CNT au moyen de la clé publique PUB_KEY_CM du module de gestion de certificats 12 et du condensé HASH_CNT du jeton de certification CNT et des informations TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Une fois cette vérification effectuée, le serveur d’un fournisseur de services 14 demande, dans une étape G4, au serveur de noms de domaines de lui fournir le certificat CERT_CPE associé au jeton certification CNT qu’il vient de vérifier. Pour cela, le serveur d’un fournisseur de services 14 émet un message de type DNS Query comprenant, dans un champ existant, le jeton certification CNT. Dans une étape G5, le serveur de noms de domaines 13 retourne le certificat CERT_CPE correspondant au jeton de certification CNT reçu. Dans une étape G6, le serveur d’un fournisseur de services 14 vérifie alors que le certificat CERT_CPE correspond à la ou les adresses réseau fournies dans le message client Hello TLS sachant qu’un tel certificat CERT_CPE est délivré pour une ou plusieurs adresses réseau allouées à l’équipement 10. Une fois l’équipement 10 authentifié, le serveur d’un fournisseur de services 14 émet un message Server Hello à destination de l’équipement 10 finalisant ainsi l’établissement de la connexion entre ce dernier et le serveur d’un fournisseur de services 14 dans une étape G6. Le serveur de services 14 ajoute également l’information ‘UE authentifié’ dans l’extension TLS_CNT du message Server Hello indiquant ainsi que l’équipement 10 est authentifié. La représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la dans un premier mode de réalisation du procédé de révocation d’un jeton de certification CNT associé à l’équipement 10. La mise en œuvre de ce procédé de révocation peut ou non intervenir suite à l’exécution de l’étape G6 au cours de laquelle une connexion est établie entre l’équipement 10 et le serveur d’un fournisseur de services 14. Dans une première implémentation, l’équipement 10 émet, à destination du serveur de configuration 11, un message demandant la libération de la ou des adresses réseaux qui lui sont allouées au cours d’une étape H1. L’envoi d’un tel message à destination du serveur de configuration 11 peut être déclenché lorsque l’équipement 10 quitte la zone de couverture d’un premier nœud d’accès, comme par exemple un nœud d’accès Wi-Fi, pour s’attacher à un deuxième nœud d’accès telle qu’une station de base. Un tel changement de réseau d’accès nécessite la libération de l’adresse réseau allouée à l’équipement 10, entrainant la révocation du jeton de certification associé à l’équipement 10 qui a été généré au moyen de cette adresse réseau. Dans un premier exemple, un tel message est un message de type DHCP Release comprenant le jeton de certification CNT, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Dans un deuxième exemple, l’équipement 10 émet un nouveau type de message, appelé DHCP Revoke. Un tel message DHCP Revoke comprend, lui aussi, le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. A réception du message DHCP Release ou DHCP Revoke, dans une étape H2, le serveur de configuration 11 traite les informations relatives à la libération des adresses réseau comprises dans cette requête de manière classique. Lors du traitement du message DHCP Release , le serveur de configuration 11 détectant la présence de paramètres relatifs au certificat CERT_CPE dans un champ du message, c’est-à-dire au moins le jeton de certification CNT correspondant, ou le condensé HASH_CNT du jeton de certification CNT, voir en plus et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, extrait ces informations et génère une demande de révocation du jeton de certification CNT associé à l’équipement 10 et au certificat CERT_CPE. Lors du traitement du message DHCP Revoke , la nature même du message indique au serveur de configuration 11 qu’il doit extraire les paramètres relatifs au certificat CERT_CPE compris dans un champ du message DHCP Revoke, c’est-à-dire le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, et générer une demande de révocation du jeton de certification CNT associé à l’équipement 10 et au certificat CERT_CPE. Dans une deuxième implémentation, la révocation du jeton de certification CNT associé à l’équipement 10 et au certificat CERT_CPE est à l’initiative du réseau, un tel changement de réseau peut aussi être détecté et signifié par le point d’accès radio auquel l’équipement 10 est attaché, tel qu’une station de base ou un point d’accès Wi-Fi. Dans cette deuxième implémentation, l’émission du message DHCP Release ou du message DHCP Revoke est à l’initiative du réseau et est déclenchée, par exemple, par la détection d’une inactivité de l’équipement 10 par le réseau, la détection d’un routage défectueux du trafic en provenance ou à destination de l’équipement 10, la détection d’une nouvelle association entre une adresse réseau allouée à l’équipement 10 et une nouvelle adresse physique (MAC pour « M edium A ccess C ontrol » en langue anglaise), etc. La demande de révocation du jeton de certification CNT comprend : le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé et le certificat CertDHCP associé au serveur de configuration 11. La demande de révocation du jeton de certification CNT peut aussi comprendre le nom de domaine, par exemple « 4d2a.37f78dd8d99b3c75ddde3624155.example.com », avec lequel le certificat CERT_CPE a été associé au cours de l’étape E8 décrite en référence à la . Quelle que soit l’implémentation mise en œuvre, le serveur de configuration 11 transmet, dans une étape H3, la demande de révocation du jeton de certification CNT au module de gestion de certificats 12. A réception de la demande de révocation du jeton de certification CNT, le module de gestion de certificats 12 procède de manière optionnelle, dans une étape H4, à la vérification de l’authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11. Une fois l’authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11 vérifiée, le module de gestion de certificats 12 supprime le certificat CERT_CPE associé à l’équipement 10 et le jeton de certification CNT correspondant dans une étape H5. Dans le cas où l’étape H4 n’est pas mise en œuvre, l’exécution de l’étape H5 est déclenchée par la réception de la demande de révocation du jeton de certification émise par le serveur de configuration 11. Une fois cette vérification effectuée, le module de gestion de certificats 12 transmet, dans une étape H5, une demande de révocation DRev de l’association du certificat CERT_CPE associé à l’équipement 10 avec le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l’étape E8 décrite en référence à la , à destination du serveur de noms de domaines 13. Une telle demande de révocation DRev comprend : le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de gestion de certificats 12. Parallèlement, le module de gestion 12 supprime d’une base de données le certificat CERT_CPE et le jeton de certification CNT correspondant. Dans une étape H6, le serveur de noms de domaines 13 extrait l’ensemble des informations comprises dans la demande de révocation DRev et révoque l’association établie entre d’une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d’autre part le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com ». Une fois l’association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine révoquée, le serveur de noms de domaines 13 en informe le module de gestion de certificats 12 dans une étape H7. Dans une implémentation particulière, l’opération de suppression du certificat CERT_CPE et du jeton de certification CNT correspondant d’une base de données du module de gestion 12 est déclenchée par la réception de l’information relative à la révocation de l’association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine reçue à l’étape H7. A son tour, le module de gestion de certificats 12 informe le serveur de configuration 11 de la révocation de l’association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape H8. A l’issue de l’étape H8, l’équipement 10 souhaitant établir une connexion avec le serveur d’un fournisseur de services 14 transmet à ce dernier un message client Hello TLS classique, c’est-à-dire ne comprenant pas de jeton de certification CNT puisque celui-ci a été révoqué. Le serveur d’un fournisseur de services 14 ne trouvant pas de jeton de certification CNT dans le message Hello TLS , il ne peut vérifier la validité d’un quelconque certificat relatif à l’équipement 10. Le serveur d’un fournisseur de services 14 émet alors un message Server Hello à destination de l’équipement 10 indiquant que le certificat associé à l’équipement 10 n’est pas valide et qu’une connexion ne peut pas être établie avec l’équipement 10. Ces échanges de messages client Hello TLS classique et Server Hello entre l’équipement 10 et le serveur 14 ne sont pas représentés à la . Si d’aventures, l’équipement 10 a besoin d’obtenir un nouveau certificat et le jeton de certification correspondant, il doit alors mettre de nouveau en œuvre les étapes E1 à E11. La représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la dans un deuxième mode de réalisation du procédé de révocation d’un jeton de certification CNT associé à l’équipement 10. La mise en œuvre de ce procédé de révocation peut ou non intervenir suite à l’exécution de l’étape G6 au cours de laquelle une connexion est établie entre l’équipement 10 et le serveur d’un fournisseur de services 14. Dans ce deuxième mode de réalisation, l’équipement 10 émet, à destination du serveur de configuration 11, un message demandant la libération de la ou des adresses réseaux qui lui sont allouées au cours d’une étape P1. L’envoi d’un tel message à destination du serveur de configuration 11 peut être déclenché lorsque l’équipement 10 quitte la zone de couverture d’un premier nœud d’accès, comme par exemple un nœud d’accès Wi-Fi, pour s’attacher à un deuxième nœud d’accès telle qu’une station de base. La libération de l’adresse réseau allouée à l’équipement 10, entraine la révocation du jeton de certification associé à l’équipement 10 qui a été généré au moyen de cette adresse réseau. Dans un premier exemple, un tel message est un message de type DHCP Release comprenant le jeton de certification CNT, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. A réception du message DHCP Release, dans une étape P2, le serveur de configuration 11 traite les informations relatives à la libération des adresses réseau comprises dans cette requête de manière classique. A un instant donné, intervenant après la demande de libération de la ou des adresses réseaux allouées à l’équipement 10 et sans corrélation avec l’émission de cette demande de libération, le serveur d’un fournisseur de services 14 émet une requête en résolution de noms de domaine RQT-DNS à destination du serveur de noms de domaines 13 par exemple pour le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » associé au certificat CERT_CPE de l’équipement 10, dans une étape P3. Lorsque le serveur de noms de domaines 13 constate que l’association existant entre le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » et le certificat CERT_CPE a expiré, le serveur de noms de domaines 13 émet, dans une étape P4, un message MSG-TTL indiquant que l’association existant entre le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » et le certificat CERT_CPE a expiré à destination du module de gestion de certificats 12. Un tel message MSG-TTL comprend au moins le jeton de certification CNT. Un tel message MSG-TTL est par exemple implémenté en ajoutant un nouveau message id-pkix-ocsp-cnt à la définition du protocole OCSP (Online Certificate Status Protocol) tel que défini en ASN.1 dans le document publié à l’adresse suivante :https://www.rfc-editor.org/rfc/rfc6960#appendix-B.1: Un exemple de message MSG-TTL qui attend une réponse contentant un jeton de certification CNT comprend une identification du -type de message « id-pkix-ocsp-cn »t dans son champ « AcceptableResponse s ». A réception de ce message MSG-TTL, le module de gestion de certificats 12 émet un message d’information MSG-Inf à destination du serveur de configuration 11 l’informant que l’association existant entre le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » et le certificat CERT_CPE a expiré, dans une étape P5. Un tel message MSG-Inf est par exemple implémenté en utilisant le message conforme au protocole OCSP instanciant une extension ‘ ServiceLocator ’ du protocole OCSP (voir la section 4.4.6 du document RFC6960 publié par l’IETF), un tel message comprenant des identifiants du serveur de configuration 11 et du module de gestion de certificats 12 : ServiceLocator := SEQUENCE { issuer ‘172.3.2.1’, locator ‘172.3.2.2’} où le champ « service locator » comprend soit l’adresse réseau ‘172.3.2.2’ du serveur de configuration 11 ou l’soit son « common name » ‘srvcfg11.example.com’, et le champ « issuer » comprend l’adresse réseau 172.3.2.1’ ou l’identifiant CN_CM du module de gestion de certificats 12. En réponse au message MSG-Inf et sachant que l’équipement 10 et, dans une étape P6, une demande de révocation du jeton de certification CNT à destination du module de gestion de certificats 12. Une telle demande de révocation comprend : le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé et le certificat CertDHCP associé au serveur de configuration 11. La demande de révocation du jeton de certification CNT peut aussi comprendre le nom de domaine, par exemple « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » . A réception de la demande de révocation du jeton de certification CNT, le module de gestion de certificats 12 procède de manière optionnelle, dans une étape P7, à la vérification de l’authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11. Une fois l’authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11 vérifiée, le module de gestion de certificats 12 supprime le certificat CERT_CPE associé à l’équipement 10 et le jeton de certification CNT correspondant dans une étape P8. Dans le cas où l’étape P7 n’est pas mise en œuvre, l’exécution de l’étape P8 est déclenchée par la réception de la demande de révocation du jeton de certification émise par le serveur de configuration 11. Une fois cette vérification effectuée, le module de gestion de certificats 12 transmet, dans une étape P9 une demande de révocation DRev de l’association du certificat CERT_CPE associé à l’équipement 10 avec le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » , à destination du serveur de noms de domaines 13. Une telle demande de révocation DRev comprend : le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de gestion de certificats 12. Parallèlement, le module de gestion de certificats 12 supprime d’une base de données le certificat CERT_CPE et le jeton de certification CNT correspondant. Dans une étape P10, le serveur de noms de domaines 13 extrait l’ensemble des informations comprises dans la demande de révocation DRev et révoque l’association établie entre d’une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d’autre part le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com ». Une fois l’association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine révoquée, le serveur de noms de domaines 13 en informe le module de gestion de certificats 12 dans une étape P11 qui peut être optionnelle. Dans une implémentation particulière, l’opération de suppression du certificat CERT_CPE et du jeton de certification CNT correspondant d’une base de données du module de gestion 12 est déclenchée par la réception de l’information relative à la révocation de l’association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine reçue à l’étape P11. A son tour, le module de gestion de certificats 12 informe, de manière optionnelle, le serveur de configuration 11 de la révocation de l’association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape P12. A l’issue de l’étape P10, l’équipement 10 souhaitant établir une connexion avec le serveur d’un fournisseur de services 14 transmet à ce dernier un message client Hello TLS classique, c’est-à-dire ne comprenant pas de jeton de certification CNT puisque celui-ci a été révoqué. Le serveur d’un fournisseur de services 14 ne trouvant pas de jeton de certification CNT dans le message Hello TLS , il ne peut vérifier la validité d’un quelconque certificat relatif à l’équipement 10. Le serveur d’un fournisseur de services 14 émet alors un message Server Hello à destination de l’équipement 10 indiquant que le certificat associé à l’équipement 10 n’est pas valide ou ne permet pas d’identifier l’équipement 10 et/ou son fournisseur de services et qu’une connexion ne peut pas être établie avec l’équipement 10. Ces échanges de messages client Hello TLS classique et Server Hello entre l’équipement 10 et le serveur 14 ne sont pas représentés à la . Si d’aventures, l’équipement 10 a besoin d’obtenir un nouveau certificat et le jeton de certification correspondant, il doit alors mettre de nouveau en œuvre les étapes E1 à E11. La représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la dans un troisième mode de réalisation du procédé de révocation d’un jeton de certification CNT associé à l’équipement 10. La mise en œuvre de ce procédé de révocation peut ou non intervenir suite à l’exécution de l’étape G6 au cours de laquelle une connexion est établie entre l’équipement 10 et le serveur d’un fournisseur de services 14. Dans une étape S1, l’expiration d’une durée de vie associée à une ou plusieurs adresses réseau allouées à l’équipement 10 déclenche la libération de ces adresses réseau par le serveur de configuration 11. Dans un autre exemple, le serveur de configuration 11 reçoit une demande de libération des adresses réseau allouées à l’équipement 10 suite à une décision de l’opérateur gestionnaire du réseau. Dans une étape S2, le serveur de configuration 11 transmet une demande de révocation du jeton de certification CNT au module de gestion de certificats 12. Une telle demande de révocation comprend le jeton de certification CNT et un code indiquant les raisons de cette demande de suspension. Parallèlement à l’étape S2, le serveur de configuration 11 émet un message DHCP NACK à destination de l’équipement 10 dans une étape S3. Un tel message DHCP NACK indique à l’équipement 10 qu’il n’est plus autorisé à utiliser les adresses réseau qui lui étaient allouées. Le message DHCP NACK comprenant également le jeton de certification CNT, l’équipement 10 comprend également qu’il n’est plus autorisé à utiliser ce jeton de certification CNT. Une telle étape S3 peut intervenir dans certains modes de réalisation avant la mise en œuvre de l’étape S2 ou avant la mise en œuvre de l’étape S1. A réception de la demande de révocation du jeton de certification CNT, le module de gestion de certificats 12 procède de manière optionnelle, dans une étape S4, à la vérification de l’authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11. Une fois cette vérification effectuée, le module de gestion de certificats 12 transmet, dans une étape S5, une demande de révocation DRev de l’association du certificat CERT_CPE associé à l’équipement 10 avec le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l’étape E8 à destination du serveur de noms de domaines 13. Une telle demande de révocation DRev comprend au moins le jeton de certification CNT correspondant, et optionnellement le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de gestion de certificats 12. Une telle demande de révocation comprend également le code indiquant les raisons de cette demande de suspension. Parallèlement, le module de gestion de certificats 12 supprime d’une base de données le certificat CERT_CPE et le jeton de certification CNT correspondant. Dans une étape S6, le serveur de noms de domaines 13 extrait l’ensemble des informations comprises dans la demande de révocation DRev et révoque l’association établie entre d’une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d’autre part le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com ». Une fois l’association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine révoquée, le serveur de noms de domaines 13 en informe le module de gestion de certificats 12 dans une étape S7 qui peut être optionnelle. Dans une implémentation particulière, l’opération de suppression du certificat CERT_CPE et du jeton de certification CNT correspondant d’une base de données du module de gestion 12 est déclenchée par la réception de l’information relative à la révocation de l’association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine reçue à l’étape S7. A son tour, le module de gestion de certificats 12 informe, de manière optionnelle, le serveur de configuration 11 de la révocation de l’association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape S8. A l’issue de l’étape S8, l’équipement 10 souhaitant établir une connexion avec le serveur d’un fournisseur de services 14 transmet à ce dernier un message client Hello TLS classique, c’est-à-dire ne comprenant pas de jeton de certification CNT puisque celui-ci a été révoqué dans une étape S9. Ces échanges de messages client Hello TLS classique et Server Hello entre l’équipement 10 et le serveur 14 ne sont pas représentés à la . Si d’aventures, l’équipement 10 a besoin d’obtenir un nouveau certificat et le jeton de certification correspondant, il doit alors mettre de nouveau en œuvre les étapes E1 à E11. La représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la dans un quatrième mode de réalisation du procédé de révocation d’un jeton de certification CNT associé à l’équipement 10. La mise en œuvre de ce procédé de révocation intervient suite à l’exécution de l’étape G6 au cours de laquelle une connexion est établie entre l’équipement 10 et le serveur d’un fournisseur de services 14. Dans une étape F1, le module de gestion 12 reçoit une demande de révocation d’un premier jeton de certification CNT1 associé à l’équipement 10 en provenance de l’opérateur gestionnaire du réseau. Une telle demande de révocation t peut être émise pour plusieurs raisons : le premier jeton de certification CNT1 est un jeton de certification temporaire qui doit être remplacé car il arrive à expiration, le premier jeton de certification CNT1 est corrompu ou sa corruption est suspectée, le premier jeton de certification CNT1 est piraté ou son piratage est suspecté, etc. Dans l’exemple d’implémentation décrit ci-après, la demande de révocation comprend une demande de remplacement du premier jeton de certification CNT1 associé à l’équipement 10. Néanmoins, ce quatrième mode de réalisation peut s’appliquer à une demande de révocation d’un jeton de certification ne comprenant pas de demande de remplacement de ce dernier. De même, bien que les premier, deuxième et troisième modes de réalisation du procédé de révocation ont été décrits avec une demande de révocation d’un jeton de certification ne comprenant pas de demande de remplacement de ce dernier, ils peuvent bien entendu traiter de manière similaire à celle décrite ci-dessous en référence au quatrième mode de réalisation, une demande de révocation d’un jeton de certification comprenant une demande de remplacement de ce dernier. Dans une étape F2, le module de gestion de certificats 12 révoque le premier jeton de certification CNT1 et le premier certificat CERT1_CPE correspondant. Dans une étape F3 effectuée avant, après ou concomitamment à l’étape F2, le module de gestion de certificats 12 génère un deuxième certificat CERT2_CPE associé à l’équipement 10. Si le deuxième certificat CERT2_CPE est un certificat classique, ce dernier est généré à partir des informations suivantes : la clé publique PUB_KEY_CPE de l’équipement 10, le condensé HASH_CPE d’une adresse physique de l’équipement 10, un certificat CertDHCP associé au serveur de configuration 11, au moins une adresse réseau IP_CPE allouée audit équipement 10 par le serveur de configuration 11 au cours de l’étape E4 décrite en référence à la (ou un pool d’adresses réseau POOL_IP_CPE allouées à l’équipement 10), et enfin le paramètre TYP_HASH sur la manière dont le condensés HASH_CPE est calculé. Si le certificat CERT2_CPE est un certificat à accès restreint, ou certificat « black hole », celui-ci est généré à partir d’informations n’ayant pas de lien avec l’équipement 10 afin d’isoler celui-ci. Quel que soit le type de certificat généré, le module de gestion de certificats 12 génère également un jeton de certification CNT2 ou CNTbh correspondant au certificat CERT2_CPE associé à l’équipement 10. Un tel jeton de certification CNT2, CNTbh est une forme compacte du certificat CERT2_CPE associé à l’équipement 10. C’est ce jeton de certification CNT2, CNTbh qui sera dorénavant utilisé par l’équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d’authentification pour accéder à un service. Pour cela, le module de gestion 12 transmet, au cours d’une étape F4, le deuxième jeton de certification CNT2, CNTbh à destination du serveur de configuration 11 afin que ce dernier remplace le premier jeton de certification CNT1 associé à l’équipement 10 par le deuxième jeton de certification CNT2, CNTbh. Dans une implémentation particulière, la réception par le serveur de configuration 11 du deuxième jeton de certification CNTbh déclenche, dans une étape F5, l’allocation d’une nouvelle adresse réseau, dite adresse « black hole », à. l’équipement 10. L’utilisation d’une telle adresse « black hole » dans les échanges en provenance ou à destination de l’équipement 10 permet d’isoler les données échangées par l’équipement 10 avec d’autres équipements et particulièrement le serveur d’un fournisseur de service 14. Plus particulièrement, les données transmises depuis ou à destination de l’équipement 10 au moyen de cette adresse « black hole » peuvent dans un premier cas ne pas être livrées ou livrées à un serveur émulant le serveur d’un fournisseur de service 14, dans un second cas être routées vers un équipement dédié afin de les étudier en vue de confirmer la corruption de l’équipement 10. Parallèlement à l’exécution de l’étape F4, le module de gestion 12 transmet, dans une étape F6, une demande de révocation DRemp du certificat CERT1_CPE associé à l’équipement 10 avec le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com », cette demande demandant la suppression de l’association établie entre d’une part le certificat CERT1_CPE et le jeton de certification CNT1 correspondant et d’autre part le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » et son remplacement par le deuxième certificat CERT2_CPE à destination du serveur de noms de domaines 13. Une telle demande de révocation DRemp comprend : le premier jeton de certification CNT1, le premier certificat CERT1_CPE, le deuxième jeton de certification CNT2, CNTbh, le deuxième certificat CERT2_CPE et la clé publique PUB_KEY_CM du module de gestion de certificats 12. Parallèlement, le module de gestion 12 mémorise dans une base de données que le premier certificat CERT1_CPE et le premier jeton de certification CNT1 correspondant sont révoqués et remplacés par le deuxième certificat CERT2_CPE et le deuxième jeton de certification CNT2, dit CNTbh correspondant. Dans une étape F7, le serveur de noms de domaines 13 extrait l’ensemble des informations comprises dans la demande de révocation DRemp, révoque l’association du premier certificat CERT1_CPE et du premier jeton de certification CNT1 correspondant avec le nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » et procède à l’association du nom de domaine « 4d2a.37f78dd8d99b3c75ddde3624155.example.com » avec le deuxième certificat CERT2_CPE et le deuxième jeton de certification CNT2, CNTbh correspondant. Dans une étape F8 qui peut être mise en œuvre avant, après ou en même temps que les étapes F6 et F7, le serveur de configuration 11 transmet un message DHCP ACK à destination de l’équipement 10. Un tel message DHCP ACK comprend le deuxième jeton de certification CNT2, CNTbh. Le message DHCP ACK comprenant le deuxième jeton de certification CNT2, CNTbh, l’équipement 10 comprend qu’il n’est plus autorisé à utiliser le premier jeton de certification CNT1 qui a été révoqué et qu’il doit dorénavant utiliser le deuxième jeton de certification CNT2, CNTbh. Si l’étape F5 a été mise en œuvre par le serveur de configuration 11, alors le message DHCP ACK comprend également l’adresse « black hole ». A l’issue de l’étape F8, l’équipement 10 souhaitant établir une connexion avec le serveur d’un fournisseur de services 14, car la connexion établie à l’issue de l’étape G6 a été interrompue, transmet à ce dernier un message client Hello comprenant le jeton de certification CNT2, CNTbh dans une étape F9. A réception de ce message client Hello TLS, le serveur d’un fournisseur de services 14 transmet un message de type DNS Query comprenant le jeton de certification CNT2, CNTbh à destination du serveur de noms de domaines 13 dans une étape F10. Le serveur de noms de domaines 13 vérifie alors, au cours d’une étape F11, la validité du jeton de certification CNT2, CNTbh et revoie, au cours d’une étape F12 un message indiquant que le jeton de certification CNT2, CNTbh est valide mais qu’il n’offre un accès restreint aux ressources du serveur d’un fournisseur de services 14. Le serveur d’un fournisseur de services 14 émet ensuite, un message Server Hello à destination de l’équipement 10 indiquant que le certificat associé à l’équipement 10 est valide et indiquant que l’accès à ses ressources est restreint, établissant ainsi une connexion avec l’équipement 10. La représente un équipement 10 apte à mettre en œuvre le procédé d’établissement authentifié d’une connexion entre un équipement raccordé à au moins un réseau de communication et un serveur d’un fournisseur de services objet de la présente invention. Un équipement 10 peut comprendre au moins un processeur matériel 1001, une unité de stockage 1002, une interface 1003, et au moins une interface de réseau 1004 qui sont connectés entre eux au travers d’un bus 1005. Bien entendu, les éléments constitutifs de l’équipement 10 peuvent être connectés au moyen d’une connexion autre qu’un bus. Le processeur 1001 commande les opérations de l’équipement 10. L'unité de stockage 1002 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 1001, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 1001, des données intermédiaires de calculs effectués par le processeur 1001, etc. Le processeur 1001 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 1001 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement ( Central Processing Unit ) qui exécute un programme stocké dans une mémoire de celui-ci. L'unité de stockage 1002 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 1002 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture. L'interface 1003 fournit une interface entre l’équipement 10 et un serveur de configuration d’adresses réseau 11. L’interface réseau 1004 fournit quant à elle une connexion entre l’équipement 10 et un au moins un serveur d’un fournisseur de services avec lequel il souhaite établir de manière authentifiée une connexion. La représente un module de gestion 12 apte à mettre en œuvre les différents procédés objets de la présente invention. Un module de gestion 12 peut comprendre au moins un processeur matériel 1201, une unité de stockage 1202, une interface 1203, et au moins une interface de réseau 1204 qui sont connectés entre eux au travers d’un bus 1205. Bien entendu, les éléments constitutifs du module de gestion 12 peuvent être connectés au moyen d’une connexion autre qu’un bus. Dans un exemple de réalisation, le module de gestion de certificats 12 est embarqué dans le serveur de configuration 11. Le processeur 1201 commande les opérations du module de gestion 12. L'unité de stockage 1202 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 1201, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 1201, des données intermédiaires de calculs effectués par le processeur 1201, etc. Le processeur 1201 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 1201 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement ( Central Processing Unit ) qui exécute un programme stocké dans une mémoire de celui-ci. L'unité de stockage 1202 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 1202 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture. L'interface 1203 fournit une interface entre le module de gestion 12 et au moins un équipement 10 souhaitant se raccorder à un réseau de communication. L’interface réseau 1204 fournit quant à elle une connexion entre le module de gestion 12 et un serveur de noms de domaines 13. Procédé de révocation d’un premier jeton de certification (CNT, CNT1) correspondant à un premier certificat (CERT_CPE, CERT1_CPE), ledit premier jeton de certification permettant d’authentifier l’établissement d’une connexion entre un équipement (10) raccordé à au moins un réseau de communication et au moins un serveur d’un fournisseur de services (14), ledit premier jeton de certification et ledit premier certificat étant générés à partir d’un condensé (HASH_CPE) d’une adresse physique dudit équipement, d’un certificat (CertDHCP) associé à un serveur de configuration d’adresses réseau (11) et d’au moins une adresse réseau (IP_CPE) allouée audit équipement par ledit serveur de configuration d’adresses réseau, le procédé comprenant les étapes suivantes mises en œuvre par un module de gestion de certificats (12) : - révocation dudit premier jeton de certification déclenchée par l’obtention d’une information relative à une condition de révocation dudit premier jeton de certification , - transmission, à destination d’un serveur de noms de domaines (13), d’une demande de révocation (DRev) d’une association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part au moins un nom de domaine. Procédé de révocation d’un jeton de certification selon la revendication 1, dans lequel ladite condition de révocation dudit premier jeton de certification appartient à un groupe comprenant : - une demande de révocation dudit premier jeton de certification, ladite demande de révocation étant émise par l’équipement, - une demande de révocation dudit premier jeton de certification, ladite demande de révocation étant émise par un équipement du réseau, - une expiration d’une durée d’allocation de l’adresse réseau allouée à l’équipement, - une expiration d’une durée de vie du premier jeton de certification, - une expiration d’une durée de l’association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part au moins un nom de domaine, - un conflit d’usage dans un plan d’adressage - une information relative à une compromission du premier jeton de certification, - une information relative à un piratage du premier jeton de certification. Procédé de révocation d’un jeton de certification selon la revendication 2 qui, lorsque l’information relative à une condition de révocation dudit premier certificat est une information relative à l’expiration de la durée de l’association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part au moins un nom de domaine, comprend préalablement à l’étape de révocation du premier jeton de certification, les étapes suivantes de : - transmission d’une demande de révocation d’une association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part le serveur de configuration d’adresses réseau, - réception d’une demande de révocation dudit premier jeton de certification émise par ledit serveur de configuration d’adresses réseau suite à la révocation de l’association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part le serveur de configuration d’adresses réseau. Procédé de révocation d’un jeton de certification selon la revendication 3 comprenant en outre une étape de transmission, à destination du serveur de configuration d’adresses réseau, d’un message d’acquittement de la révocation dudit premier jeton de certification par le module de gestion de certificats. Procédé de révocation d’un jeton de certification selon l’une quelconque des revendications 1 à 4 comprenant en outre les étapes suivantes lorsque la condition de révocation dudit premier jeton de certification est assortie d’une demande de remplacement dudit premier jeton de certification : - génération d’un deuxième certificat (CERT2_CPE) associé audit équipement et d’un deuxième jeton de certification (CNT2) correspondant, - transmission, à destination dudit serveur de noms de domaines, d’une demande d’association entre d’une part ledit deuxième certificat et ledit deuxième jeton de certification et d’autre part ledit nom de domaine précédemment associé au premier certificat et au premier jeton de certification correspondant, - transmission dudit deuxième jeton de certification à destination dudit équipement. Procédé de révocation d’un jeton de certification selon la revendication 5 dans lequel le deuxième jeton de certification offre un accès restreint aux ressources du serveur d’un fournisseur de services. Module de gestion de certificats (12) adapté pour révoquer un premier jeton de certification (CNT, CNT1) correspondant à un premier certificat (CERT_CPE, CERT1_CPE), ledit premier jeton de certification permettant d’authentifier l’établissement d’une connexion entre un équipement (10) raccordé à au moins un réseau de communication et au moins un serveur d’un fournisseur de services (14), ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de gestion de certificats à partir d’un condensé (HASH_CPE) d’une adresse physique dudit équipement, d’un certificat (CertDHCP) associé à un serveur de configuration d’adresses réseau (11) et d’au moins une adresse réseau (IP_CPE) allouée audit équipement par ledit serveur de configuration d’adresses réseau, ledit module de gestion de certificats comprenant au moins un processeur configuré pour : - révoquer ledit premier jeton de certification suite à l’obtention d’une information relative à une condition de révocation dudit premier jeton de certification , -transmettre, à destination d’un serveur de noms de domaines (13), une demande de révocation (DRev) d’une association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre au moins un nom de domaine. Serveur de configuration d’adresses réseau (11) comprenant au moins un module de gestion de certificats (12) adapté pour révoquer un premier jeton de certification (CNT, CNT1) correspondant à un premier certificat (CERT_CPE, CERT1_CPE), ledit premier jeton de certification permettant d’authentifier l’établissement d’une connexion entre un équipement (10) raccordé à au moins un réseau de communication et au moins un serveur d’un fournisseur de services (14), ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de gestion de certificats à partir d’un condensé (HASH_CPE) d’une adresse physique dudit équipement, d’un certificat (CertDHCP) associé audit serveur de configuration d’adresses réseau (11) et d’au moins une adresse réseau (IP_CPE) allouée audit équipement par ledit serveur de configuration d’adresses réseau, ledit module de gestion de certificats comprenant au moins un processeur configuré pour : - révoquer ledit premier jeton de certification suite à l’obtention d’une information relative à une condition de révocation dudit premier jeton de certification , -transmettre, à destination d’un serveur de noms de domaines (13), une demande de révocation (DRev) d’une association établie entre d’une part le premier certificat et le premier jeton de certification et d’autre part au moins un nom de domaine. Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de révocation d’un premier jeton de certification selon la revendication 1, lorsqu’il est exécuté par un processeur.