Cycle de vie et renouvellement du certificat

Les paires certificat-clé client et les certificats d’autorité de certification expirent régulièrement. Votre infrastructure réseau et vos appareils doivent être en mesure de gérer l’expiration du certificat et de présenter un nouveau certificat sans perdre la connectivité. Les certificats d’autorité de certification racine, qui sont utilisés dans l’authentification serveur RADIUS, et les certificats clients, qui sont utilisés dans l’authentification de l’appareil, nécessitent différentes approches de mise à jour.

Mettre à jour un certificat d’autorité de certification racine

Un certificat d’autorité de certification est l’autorité de certification racine du certificat d’authentification sur le serveur RADIUS. Si le certificat d’autorité de certification expire ou si l’infrastructure à clé publique pour le serveur change( par exemple, si le serveur acquiert une nouvelle autorité de certification racine auprès d’une autre autorité de certification), les appareils Azure Sphere ne peuvent plus authentifier le serveur d’authentification RADIUS. Toutefois, les appareils doivent continuer à fonctionner.

Sur un réseau sans fil classique, il n’est pas possible d’effectuer un basculement « couteau-edge » ; autrement dit, vous ne pouvez pas mettre à jour tous les appareils Azure Sphere au moment exact où l’autorité de certification racine devient non valide. Les appareils peuvent être hors connexion au moment critique ou la précision de l’heure peut varier d’une installation à l’autre. Votre application de haut niveau doit être en mesure d’obtenir le nouveau certificat d’autorité de certification racine avant que le certificat actuel n’expire ou change, afin que le nouveau certificat soit prêt à être utilisé si nécessaire.

L’approche recommandée consiste à créer et à activer un deuxième réseau qui a la même configuration que le réseau existant, mais qui utilise le nouveau certificat d’autorité de certification racine. Lorsque le certificat d’autorité de certification racine existant échoue sur le réseau d’origine, le système d’exploitation tente automatiquement de se connecter au deuxième réseau. L’application peut ensuite remplacer le certificat sur le réseau d’origine par la nouvelle autorité de certification racine et supprimer le deuxième réseau. L’appareil peut ensuite se connecter à l’aide du réseau d’origine, qui dispose désormais de la nouvelle autorité de certification racine. La figure suivante résume cette approche.

Une application de haut niveau doit suivre ces étapes pour gérer en toute transparence une mise à jour du certificat d’autorité de certification racine :

1. Dans le cadre d’un fonctionnement normal, l’application configure Network1 de type WifiConfig_Security_Wpa2_EAP_TLS. Ce réseau est lié au certificat client de l’appareil et à l’autorité de certification racine 1, qui est l’autorité de certification racine d’origine pour le serveur RADIUS.

2. Environ 90 jours avant l’expiration de RootCA, l’appareil reçoit une notification cloud-à-appareil indiquant qu’un nouveau certificat d’autorité de certification racine pour le serveur RADIUS sera bientôt requis. La notification peut être déclenchée par un administrateur réseau ou un autre opérateur ; Les mécanismes de notification possibles incluent un Azure IoT Hub ou un message cloud-à-appareil Azure IoT Central.

   L’administrateur réseau est chargé de mettre à jour le certificat sur le serveur RADIUS et de s’assurer que les appareils Azure Sphere seront mis à jour de manière appropriée.

3. L’application acquiert une nouvelle autorité de certification racine et appelle CertStore_InstallRootCACertificate pour l’enregistrer en tant que CA2 racine.

4. L’application crée un réseau, Network2, en appelant WifiConfig_AddDuplicateNetwork pour dupliquer la configuration Network1. Il lie ensuite l’ac ca2 racine au réseau 2 et active Network2. Si Network2 est activé sur l’appareil et peut se connecter à Internet, l’appareil l’utilise si Network1 n’est pas disponible.

5. L’application interroge quotidiennement en appelant WifiConfig_GetConnectedNetworkId pour déterminer le réseau auquel l’appareil est connecté.

   Si la case activée quotidienne du réseau connecté échoue, l’erreur peut provenir d’un problème de certificat côté serveur ou appareil, ou d’un autre problème. Pour obtenir de l’aide, consultez Résolution des problèmes réseau .

   Si l’appareil est connecté à Network1, cela signifie que le certificat n’a pas encore expiré et que tout fonctionne correctement. L’application répète cette étape jusqu’à ce que l’appareil se connecte à Network2.

   Si l’appareil est connecté à Network2, cela signifie que l’ancien certificat a expiré, que l’infrastructure à clé publique mise à jour est configurée sur le serveur RADIUS et que l’appareil peut authentifier le serveur à l’aide de l’autorité de certification racine 2.

6. Lorsque l’appareil fonctionne correctement avec Network2, l’application effectue les modifications apportées à la configuration réseau :

   • Renomme Root CA2 en Root CA1 en appelant CertStore_MoveCertificate. Cette fonction remplace la racine CA1 expirée par le contenu de Root CA2.
   • Recharge la configuration de Network1 en appelant WifiConfig_ReloadConfig. La configuration de Network1 correspond désormais au réseau actuel.
   • Supprime la configuration Network2 en appelant WifiConfig_ForgetNetworkById.

Mettre à jour un certificat client

Le certificat client comprend la paire de clés publique et privée utilisée pour authentifier l’appareil Azure Sphere. Comme le certificat d’autorité de certification racine, le certificat client expire de temps à autre et l’appareil doit être en mesure de présenter un nouveau certificat. Votre application de haut niveau est chargée d’obtenir le nouveau certificat avant l’expiration du certificat existant. Une application peut obtenir la date et l’heure d’expiration d’un certificat en appelant CertStore_GetCertificateNotAfter.

La figure suivante résume cette procédure. Ce modèle permet à votre code de mise à jour de certificat d’utiliser des ID de certificat constants, tels que ClientCert1 et ClientCert2, au lieu de créer un nom unique pour chaque nouveau certificat. En outre, il ne nécessite aucun échange réseau ni nettoyage de certificat client.

Une application de haut niveau doit suivre ces étapes pour gérer en toute transparence une mise à jour du certificat client :

1. Dans le cadre d’un fonctionnement normal, l’application configure Network1 de type WifiConfig_Security_Wpa2_EAP_TLS. Ce réseau est lié au certificat client de l’appareil (ClientCert1) et à l’autorité de certification racine du serveur RADIUS. Avant de commencer la procédure de mise à jour, l’application vérifie que l’appareil est connecté à Network1 en appelant WifiConfig_GetNetworkIdByConfigName et WifiConfig_GetConnectedNetworkId. Si les ID réseau correspondent, l’application peut être certaine qu’elle est connectée au réseau prévu.

2. L’application appelle CertStore_GetCertificateNotAfter à intervalles réguliers pour déterminer quand le certificat client expirera. L’application peut également stocker la date d’expiration dans un stockage mutable . Toutefois, il doit toujours case activée la date d’expiration tous les jours et après chaque redémarrage.

   L’application compare la date et l’heure d’expiration avec la date et l’heure actuelles. Si le certificat expire dans une période de seuil prédéterminée, l’application obtient un nouveau certificat. La durée de la période de seuil est votre choix. En guise de meilleure pratique, nous vous recommandons d’obtenir un nouveau certificat au moins quatre semaines avant l’expiration si l’appareil est hors connexion pendant une longue période ou rencontre des problèmes réseau ou serveur répétés. Plus vous case activée tôt, plus vous aurez de temps pour résoudre les problèmes.

3. L’application obtient un nouveau certificat de l’émetteur de certificat approprié. Le choix d’un émetteur de certificat incombe à l’administrateur de réseau local.

4. L’application enregistre le nouveau certificat en tant que ClientCert2 en appelant CertStore_InstallClientCertificate et l’ajoute à la configuration network1 Wi-Fi en appelant WifiConfig_SetClientCertStoreIdentifier.

5. L’application recharge la configuration Wi-Fi en appelant WifiConfig_ReloadConfig. Cette étape rend ClientCert2 disponible pour l’appareil pour une utilisation dans les connexions réseau.

6. Vérifiez si la connexion réseau a réussi.

   • Une connexion réussie signifie que ClientCert2 est maintenant valide.

     • Renommez ClientCert2 ClientCert1 en appelant CertStore_MoveCertificate.

     • Désactivez Network1 en appelant WifiConfig_SetNetworkEnabled pour définir l’état Activé du réseau sur false, puis réactivez Network1 en appelant WifiConfig_SetNetworkEnabled pour définir l’état Activé sur true. La désactivation et la réactivation de la configuration rendent le contenu du certificat renommé disponible pour l’application.

   • L’échec de la connexion signifie que ClientCert2 n’est pas encore valide ou qu’une autre erreur s’est produite.

     • Si le certificat n’est pas encore valide, passez à l’étape 7 pour rétablir l’état d’origine de la configuration réseau.
     • Si une autre erreur s’est produite, consultez Résolution des problèmes réseau pour obtenir de l’aide et réessayer la connexion.

7. Que la connexion réseau ait réussi ou non, rechargez la configuration Wi-Fi en appelant WifiConfig_ReloadConfig. Si la connexion a réussi, la configuration rechargée utilise le nouveau ClientCert1, qui a été remplacé par ClientCert2. En cas d’échec de la connexion, la configuration rechargée utilise ClientCert1.