Cycle de vie et renouvellement des certificats

Les paires certificat-clé du 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 des certificats 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 du serveur RADIUS, et les certificats clients, qui sont utilisés dans l’authentification des appareils, nécessitent des approches différentes pour la 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 autorité de certification différente-, les appareils Azure Sphere ne peuvent plus authentifier le serveur d’authentification RADIUS. Les appareils doivent cependant continuer à fonctionner.

Sur un réseau sans fil classique, il n’est pas possible d’effectuer un basculement « au couteau » : vous ne pouvez pas mettre à jour tous les appareils Azure Sphere au moment précis où l’autorité de certification racine devient non valide. Les appareils peuvent être hors connexion au moment critique ou la précision de l’horloge 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 l’expiration ou la modification du certificat actuel, afin que le nouveau certificat soit prêt à être utilisé quand c’est nécessaire.

L’approche recommandée est de créer et d’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. Quand le certificat d’autorité de certification racine existant échoue sur le réseau d’origine, le système d’exploitation essaye automatiquement de se connecter au deuxième réseau. L’application peut alors 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 alors se connecter en utilisant le réseau d’origine, qui a maintenant 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 sans interruption une mise à jour du certificat d’autorité de certification racine :

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

2. Environ 90 jours avant l’expiration de l’autorité de certification racine, l’appareil reçoit une notification cloud-à-appareil indiquant qu’un nouveau certificat d’autorité de certification racine pour le serveur RADIUS sera exigé prochainement. 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 message cloud-à-appareil Azure IoT Hub ou Azure IoT Central.

   L’administrateur réseau est responsable de la mise à jour du certificat sur le serveur RADIUS et de la mise à jour de façon appropriée des appareils Azure Sphere.

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

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

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

   Si la vérification quotidienne du réseau connecté échoue, l’erreur peut être due à un problème de certificat côté serveur ou côté appareil, ou bien à un autre problème. Consultez résoudre les problèmes réseau pour obtenir de l’aide.

   Si l’appareil est connecté au réseau 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 au réseau Network2.

   Si l’appareil est connecté au réseau 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 est en mesure d’authentifier le serveur en utilisant l’autorité de certification racine Root CA2.

6. Quand l’appareil fonctionne correctement avec le réseau Network2, l’application effectue les modifications de la configuration réseau :

   • Elle renomme l’autorité de certification racine Root CA2 en Root CA1 en appelant CertStore_MoveCertificate. Cette fonction remplace l’autorité de certification racine Root CA1 expirée par le contenu de Root CA2.
   • Elle recharge la configuration du réseau Network1 en appelant WifiConfig_ReloadConfig. La configuration du réseau Network1 correspond maintenant au réseau actuel.
   • Elle supprime la configuration du réseau Network2 en appelant WifiConfig_ForgetNetworkById.

Mettre à jour un certificat client

Le certificat client comprend la paire de clés publique et privée utilisées pour authentifier l’appareil Azure Sphere. À l’instar du certificat d’autorité de certification racine, le certificat client expire de temps en temps, et l’appareil doit être en mesure de présenter un nouveau certificat. Votre application de haut niveau est responsable de l’obtention du 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, comme ClientCert1 et ClientCert2, au lieu de créer un nom unique pour chaque nouveau certificat. En outre, il ne nécessite pas de changer de réseau ni de nettoyer les certificats clients.

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

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

2. L’application appelle CertStore_GetCertificateNotAfter à intervalles réguliers pour déterminer à quel moment le certificat client va expirer. L’application pourrait aussi stocker la date d’expiration dans un stockage modifiable : elle devrait néanmoins continuer à vérifier la date d’expiration quotidiennement 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 au cours d’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 de votre choix. En guise de bonne 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 de réseau ou de serveur répétés. Plus tôt vous vérifiez, plus vous aurez de temps pour résoudre les problèmes.

3. L’application obtient un nouveau certificat auprès de l’émetteur de certificats approprié. Le choix d’un émetteur de certificats est de la responsabilité de l’administrateur du réseau local.

4. L’application enregistre le nouveau certificat en tant que ClientCert2 en appelant CertStore_InstallClientCertificate, puis l’ajoute à la configuration Wi-Fi du réseau Network1 en appelant WifiConfig_SetClientCertStoreIdentifier.

5. L’application recharge la configuration Wi-Fi en appelant WifiConfig_ReloadConfig. Cette étape rend ClientCert2 disponible sur 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 en ClientCert1 en appelant CertStore_MoveCertificate.

     • Désactivez le réseau Network1 en appelant WifiConfig_SetNetworkEnabled pour définir l’état Activé du réseau sur false, puis réactivez le réseau Network1 en appelant WifiConfig_SetNetworkEnabled pour définir l’état Activé sur true. La désactivation et la réactivation de la configuration rend 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 certificat ClientCert1, qui a été remplacé par ClientCert2. Si la connexion a échoué, la configuration rechargée utilise ClientCert1.