Partager via

Renouvellement du certificat

Le certificat client inscrit expire après une période d’utilisation. La date d’expiration du certificat est spécifiée par le serveur. Pour garantir un accès continu aux applications d’entreprise, Windows prend en charge un processus de renouvellement de certificat déclenché par l’utilisateur. L’utilisateur est invité à fournir le mot de passe actuel pour le compte d’entreprise. Le client d’inscription obtient un nouveau certificat client du serveur d’inscription et supprime l’ancien certificat. Le client génère une nouvelle paire de clés privée/publique, génère une requête PKCS#7 et signe la demande PKCS#7 avec le certificat existant. Dans Windows, le renouvellement automatique du certificat client MDM est également pris en charge.

Remarque

Assurez-vous que l’EntDMID dans le fournisseur de services de configuration DMClient est défini avant le déclenchement de la demande de renouvellement de certificat.

Demande de renouvellement automatique de certificat

Windows prend en charge le renouvellement automatique des certificats, également appelé Robo (Renew On Behalf Of), qui ne nécessite aucune interaction de l’utilisateur. Pour le renouvellement automatique, le client d’inscription utilise le certificat client MDM existant pour effectuer le protocole TLS (Transport Layer Security) du client. Le jeton de sécurité utilisateur n’est pas nécessaire dans l’en-tête SOAP. Par conséquent, le serveur d’inscription de certificat MDM est requis pour prendre en charge le protocole TLS client pour l’authentification cliente basée sur les certificats pour le renouvellement automatique des certificats.

Remarque

Le renouvellement du certificat d’inscription via ROBO est pris en charge uniquement avec l’infrastructure À clé publique Microsoft.

Le renouvellement automatique des certificats est la seule méthode de renouvellement de certificat client MDM prise en charge pour un appareil inscrit à l’aide de l’authentification WAB. Cela signifie que la stratégie AuthPolicy est définie sur Fédérée. Cela signifie également que si le serveur prend en charge l’authentification WAB, le serveur d’inscription de certificat MDM DOIT également prendre en charge le protocole TLS client pour renouveler le certificat client MDM.

Pour les appareils Windows, pendant la phase d’inscription du certificat client MDM ou pendant la section gestion MDM, le serveur d’inscription ou le serveur MDM peut configurer l’appareil pour prendre en charge le renouvellement automatique du certificat client MDM à l’aide du nœud ROBOSupport du fournisseur de services de configuration CertificateStore sousCertificateStore/My/WSTEP/Renew l’URL.

Avec le renouvellement automatique, le contenu du message PKCS#7 n’est pas codé en base64 séparément. Avec le renouvellement manuel du certificat, l’encodage en base64 pour le contenu des messages PKCS#7 est requis.

Pendant le processus de renouvellement automatique du certificat, si l’appareil n’approuve pas le certificat racine, l’authentification échoue. Utilisez l’un des certificats racines préinstallés de l’appareil ou configurez le certificat racine sur une session DM à l’aide du fournisseur csp CertificateStore.

Pendant le processus de renouvellement automatique du certificat, l’appareil refuse la demande de redirection HTTP du serveur. Il ne refuse pas la demande si la même URL de redirection que celle acceptée par l’utilisateur lors du processus d’inscription mdm initial est utilisée.

L’exemple suivant montre les détails d’une demande de renouvellement automatique.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
   xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <s:Header>
      <a:Action s:mustUnderstand="1">
         http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RST/wstep</a:Action>
      <a:MessageID>urn:uuid:61a17f2c-42e9-4a45-9c85-f15c1c8baee8</a:MessageID>
      <a:ReplyTo>
         <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
      </a:ReplyTo>
      <a:To s:mustUnderstand="1">
         https://dm.contoso.com/EnrollmentService/DeviceEnrollmentService.svc</a:To>
      <o:Security s:mustUnderstand="1" xmlns:o=
         "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <u:Timestamp u:Id="_0">
            <u:Created>2011-07-11T19:49:08.579Z</u:Created>
            <u:Expires>2011-07-11T19:54:08.579Z</u:Expires>
         </u:Timestamp>
         <o:UsernameToken u:Id="uuid-2a734df6-b227-4e60-82a8-ed53c574b718-5">
            <o:Username>user@contoso.com</o:Username>
            <o:Password o:Type=
               "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
            </o:Password>
         </o:UsernameToken>
      </o:Security>
   </s:Header>
   <s:Body>
      <RequestSecurityToken xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
         <TokenType>
    http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken
         </TokenType>
         <RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Renew</RequestType>
         <BinarySecurityToken
            ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#PKCS7"
            EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary"
            xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            BinarySecurityTokenInsertedHere
         </BinarySecurityToken>
         <AdditionalContext xmlns="http://schemas.xmlsoap.org/ws/2006/12/authorization">
            <ContextItem Name="DeviceType">
               <Value>WindowsPhone</Value>
            </ContextItem>
            <ContextItem Name="ApplicationVersion">
               <Value>5.0.7616.0</Value>
            </ContextItem>
         </AdditionalContext>
      </RequestSecurityToken>
   </s:Body>
</s:Envelope>

Configuration de la planification de renouvellement de certificat

Dans Windows, la période de renouvellement ne peut être définie que pendant la phase d’inscription mdm. Windows prend en charge une période de renouvellement de certificat et une nouvelle tentative de renouvellement. Elles sont configurables à la fois par le serveur d’inscription MDM et ultérieurement par le serveur d’administration MDM à l’aide des nœuds RenewPeriod et RenewInterval du csp CertificateStore. L’appareil peut réessayer de renouveler le certificat automatique plusieurs fois jusqu’à ce que le certificat expire. Pour le renouvellement manuel du certificat, l’appareil Windows rappelle à l’utilisateur une boîte de dialogue à chaque nouvelle tentative de renouvellement jusqu’à l’expiration du certificat.

Pour plus d’informations sur les paramètres, consultez le fournisseur de services de configuration CertificateStore.

Contrairement au renouvellement de certificat manuel, l’appareil n’effectue pas de renouvellement automatique de certificat client MDM si le certificat a déjà expiré. Pour vous assurer que l’appareil dispose de suffisamment de temps pour se renouveler automatiquement, nous vous recommandons de définir une période de renouvellement de quelques mois (40 à 60 jours) avant l’expiration du certificat. Et définissez l’intervalle de nouvelle tentative de renouvellement sur tous les quelques jours, comme tous les 4 à 5 jours au lieu de tous les sept jours (hebdomadaire). Cette modification augmente le risque que l’appareil tente de se connecter à différents jours de la semaine.

Réponse de renouvellement de certificat

Lorsque RequestType est défini sur Renouveler, le service web vérifie les éléments suivants (en plus de l’inscription initiale) :

  • La signature du binarysecurityToken PKCS#7 est correcte
  • Le certificat du client est dans la période de renouvellement
  • Le certificat est émis par le service d’inscription
  • Le demandeur est identique au demandeur pour l’inscription initiale
  • Pour la requête du client standard, le client n’est pas bloqué

Une fois la validation terminée, le service web récupère le contenu PKCS#10 à partir de PKCS#7 BinarySecurityToken. Le reste est identique à l’inscription initiale, sauf que le code XML d’approvisionnement doit uniquement avoir le nouveau certificat émis par l’autorité de certification.

Remarque

La réponse du serveur HTTP ne doit pas être segmentée ; il doit être envoyé sous la forme d’un seul message.

L’exemple suivant montre les détails d’une réponse de renouvellement de certificat.

<wap-provisioningdoc version="1.1">
   <characteristic type="CertificateStore">
   <!-- Root certificate provision is only needed here if it is not in the device already -->
      <characteristic type="Root">
         <characteristic type="System">
            <characteristic type="EncodedRootCertHashInsertedHere ">
               <parm name="EncodedCertificate" value="EncodedCertInsertedHere" />
            </characteristic>
         </characteristic>
      </characteristic>
      <characteristic type="My" >
         <characteristic type="User">
            <characteristic type="EncodedClientCertHashInsertedHere">
               <parm name="EncodedCertificate" value="EncodedCertInsertedHere" />
               <characteristic type="PrivateKeyContainer"/>
            </characteristic>
         </characteristic>
      </characteristic>
   </characteristic>
   <characteristic type="APPLICATION">
      <parm name="PROVIDER-ID" value="TestMDMServer"/>
   </characteristic>
</wap-provisioningdoc>

Remarque

Le client reçoit un nouveau certificat, au lieu de renouveler le certificat initial. L’administrateur contrôle le modèle de certificat que le client doit utiliser. Les modèles peuvent être différents au moment du renouvellement de l’inscription initiale.

Fournisseurs de services de configuration pris en charge lors de l’inscription mdm et du renouvellement de certificat

Les fournisseurs de services de configuration suivants sont pris en charge pendant le processus d’inscription mdm et de renouvellement de certificat.