Product Documentation

Certificats

Oct 11, 2016

Dans XenMobile, les certificats permettent d'établir des connexions sécurisées et d'authentifier les utilisateurs.

Par défaut, XenMobile est équipé d'un certificat SSL auto-signé qui est généré lors de l'installation afin de sécuriser les communications sur le serveur. Citrix vous recommande de remplacer le certificat SSL avec un certificat SSL approuvé provenant d'une autorité de certification (CA) reconnue.

XenMobile utilise également son propre service d'infrastructure de clé publique (PKI) ou obtient les certificats de l'autorité de certification pour les certificats clients. Tous les produits Citrix prennent en charge les caractères génériques et les certificats SAN. Pour la plupart des déploiements, vous n'aurez besoin que deux caractères génériques ou certificats (SAN).

Pour inscrire et gérer des appareils iOS avec XenMobile, vous devez configurer et créer un certificat Apple Push Notification Service (APNS). Pour obtenir des instructions détaillées, consultez la section Faire une demande de certificat APNS.

Le tableau suivant illustre le format et le type du certificat pour chaque composant de XenMobile :

Composant XenMobileFormat du certificatType de certificat requis
NetScaler GatewayPEM (BASE64)

PFX (PKCS#12)

SSL, racine

NetScaler Gateway convertit automatiquement un fichier PFX vers PEM.

Serveur XenMobilePEM ou

PFX (PKCS#12)

SSL, SAML, APNS

XenMobile génère également une PKI complète durant le processus d'installation.

Le serveur XenMobile ne prend pas en charge les certificats avec une extension .pem. Utilisez la commande openssl pour générer un fichier PFX à partir d'un fichier PEM :

openssl pkcs12 -export -out certificate.pfx  -in certificate.pem

StoreFrontPFX (PKCS#12)SSL, racine


XenMobile prend en charge les certificats d'écoute SSL et les certificats clients de 4096, 2048 et 1024 bits. Veuillez noter que les certificats 1024 bits peuvent être facilement compromis.

Pour NetScaler Gateway et le serveur XenMobile, Citrix recommande d'obtenir les certificats de serveur à partir d'une autorité de certification publique, comme Verisign, Thawte ou DigiCert. Vous pouvez créer une demande de signature de certificat (CSR) à partir de NetScaler Gateway ou de l'utilitaire de configuration XenMobile. Lorsque vous créez la CSR, envoyez-la à l'autorité de certification pour signature. Lorsque l'autorité de certification renvoie le certificat signé, vous pouvez l'installer sur NetScaler Gateway ou XenMobile.

Configuration des certificats clients pour l'authentification

NetScaler Gateway prend en charge l'utilisation de certificats clients pour l'authentification. Les utilisateurs qui ouvrent une session sur NetScaler Gateway peuvent également être authentifiés en fonction des attributs du certificat client qui est présenté au serveur virtuel. L'authentification du certificat client peut également être utilisée avec un autre type d'authentification, tel que LDAP ou RADIUS pour fournir une authentification à deux facteurs.

Pour authentifier les utilisateurs en fonction des attributs du certificat du côté client, l'authentification du client doit être activée sur le serveur virtuel et le certificat client doit être demandé. Vous devez lier un certificat racine au serveur virtuel sur NetScaler Gateway.

L’authentification des appareils avec NetScaler Gateway n'est pas prise en charge pour les certificats obtenus via une autorité de certification discrétionnaire.

Lorsque les utilisateurs ouvrent une session sur NetScaler Gateway, après l'authentification, les informations relatives au nom d’utilisateur sont extraites à partir du champ spécifié du certificat. Ce champ est généralement Subject:CN. Si le nom d'utilisateur est extrait avec succès, l'utilisateur est authentifié. S'il ne fournit pas de certificat valide durant la négociation SSL ou si l'extraction du nom d'utilisateur échoue, l'authentification échoue.

Vous pouvez authentifier les utilisateurs en fonction du certificat client en définissant le type d'authentification par défaut de manière à utiliser le certificat client. Vous pouvez également créer une action de certificat dont la tâche est de définir les opérations à réaliser durant l'authentification basée sur un certificat client SSL.

PKI XenMobile

La fonctionnalité d'intégration de l'infrastructure de clé publique (PKI) XenMobile vous permet de gérer la distribution et le cycle de vie des certificats de sécurité utilisés sur vos appareils.

XenMobile crée une PKI interne pour l'authentification de l'appareil lors du processus d'installation.

Les PKI externes peuvent également être utilisées pour émettre des certificats sur les appareils que vous pouvez utiliser dans les stratégies de configuration ou pour l'authentification des clients à NetScaler Gateway.

La fonction principale du système PKI est l'entité PKI. Une entité PKI présente un composant backend pour les opérations PKI. Ce composant fait partie de votre infrastructure d'entreprise, telle que Microsoft, RSA, Entrust Symantex ou OpenTrust PKI. L’entité PKI gère l’émission et la révocation de certificats backend. Elle représente la source de référence pour le statut du certificat. La configuration XenMobile doit normalement contenir une entité PKI par composant PKI backend.

La fonction secondaire du système PKI est le fournisseur d'identités. Un fournisseur d'identités est une configuration particulière d'émission et de cycle de vie de certificat. Il contrôle des éléments comme le format du certificat (sujet, clé, algorithmes) et les conditions de sa révocation ou de son renouvellement, le cas échéant. Les fournisseurs d'identités délèguent des opérations aux entités PKI. En d'autres termes, bien que les fournisseurs d'identités contrôlent le moment où les opérations PKI sont exécutées et la nature des données avec lesquelles elles sont effectuées, les entités PKI contrôlent la manière dont ces opérations sont réalisées. La configuration XenMobile contient normalement plusieurs fournisseurs d'identités par entité PKI.

Administration des certificats XenMobile

Nous vous recommandons d’effectuer un suivi des certificats que vous utilisez dans votre déploiement XenMobile, et plus particulièrement leurs dates d’expiration et mots de passe associés. Cette section vise à faciliter l'administration des certificats dans XenMobile.

Votre environnement peut inclure une partie ou l’ensemble des certificats suivants :

Serveur XenMobile
Certificat SSL pour le nom de domaine complet MDM
Certificat SAML (pour ShareFile)
Certificats d’autorité de certification racine et intermédiaire pour les certificats ci-dessus et toute autre ressource interne (StoreFront / Proxy etc)
Certificat APNS pour la gestion des appareils iOS
Certificat APNS interne pour les notifications XMS WorxHome
Certificat utilisateur PKI pour la connectivité aux infrastructures de clé publique (PKI)

MDX Toolkit
Certificat Apple Developer
Profil de provisioning Apple (par application)
Certificat APNS Apple (à utiliser avec WorxMail)
Fichier keyStore Android
Windows Phone – Certificat Symantec

NetScaler
Certificat SSL pour le nom de domaine complet MDM
Certificat SSL pour le nom de domaine complet de la passerelle
Certificat SSL pour le nom de domaine complet des StorageZone Controller (SZC) ShareFile
Certificat SSL pour l’équilibrage de charge Exchange (configuration de déchargement)
Certificat SSL pour l’équilibrage de charge StoreFront
Certificats d’autorité de certification racine et intermédiaire pour les certificats ci-dessus

Stratégie d’expiration des certificats XenMobile

Si vous laissez un certificat expirer, ce certificat n’est plus valide. Par conséquent vous ne pouvez plus effectuer de transactions sécurisées sur votre environnement ni accéder aux ressources XenMobile.

Remarque

L’autorité de certification (CA) vous invitera à renouveler votre certificat SSL avant la date d'expiration.

Certificats APNS pour WorxMail

Étant donné que les certificats du service de notification push d'Apple (APNS) expirent tous les ans, n’oubliez pas de créer de nouveaux certificats SSL pour le service de notification push d'Apple et de les mettre à niveau sur le portail Citrix avant que les certificats n’expirent. Si le certificat expire, les utilisateurs rencontreront des incohérences dans les notifications push de WorxMail. En outre, vous ne pourrez plus envoyer de notifications push pour vos applications.

Certificats APNS pour la gestion des appareils iOS

 

Pour inscrire et gérer des appareils iOS avec XenMobile, vous devez configurer et créer un certificat APNS d’Apple. Si le certificat expire, les utilisateurs ne peuvent pas s’inscrire auprès de XenMobile et vous ne pouvez pas gérer leurs appareils iOS. Pour de plus amples informations, consultez la section Faire une demande de certificat APNS.

Vous pouvez afficher l’état et la date d'expiration du certificat APNS en vous connectant au portail Apple Push Certificates Portal. Vous devez vous connecter à l’aide du même utilisateur que celui qui a créé le certificat.

Apple vous enverra également une notification par e-mail 30 et 10 jours avant la date d'expiration avec les informations suivantes :

« The following Apple Push Notification Service certificate, created for AppleID CustomersID will expire on Date. Revoking or allowing this certificate to expire will require existing devices to be re-enrolled with a new push certificate.

Please contact your vendor to generate a new request (a signed CSR), then visit https://identity.apple.com/pushcert to renew your Apple Push Notification Service certificate.

Thank You,

Apple Push Notification Service »

MDX Toolkit (certificat de distribution iOS)

Toute application exécutée sur un appareil iOS physique (autres que des applications dans l'App Store d'Apple) doit être signée avec un profil de provisioning et un certificat correspondant.

Veuillez noter qu'un certificat et un profil de provisioning iOS Developer for Enterprise existants peuvent ne pas être compatibles avec iOS 9. Pour de plus amples informations, consultez la section Wrapping d'applications Worx pour iOS 9.

Pour vérifier que vous disposez d'un certificat de distribution iOS valide, procédez comme suit :

1. À partir du portail Apple Enterprise Developer, créez un ID d'application explicite pour chaque application que vous voulez wrapper avec le MDX Toolkit. Un exemple d'ID d'application acceptable est : com.NomSociété.NomProduit.
À partir du portail Apple Enterprise Developer, accédez à Provisioning Profiles > Distribution et créez un profil de provisioning interne. Répétez cette étape pour chaque ID d'application créé à l'étape précédente.
3. Téléchargez tous les profils de provisioning. Pour de plus amples informations, consultez la section Wrapping des applications mobiles iOS.

Pour confirmer que tous les certificats du serveur XenMobile sont valides, procédez comme suit :

  1.  Dans la console XenMobile, cliquez sur Paramètres et sur Certificats
  2. Assurez-vous que tous les certificats y compris les certificats APNS, d’écoute SSL, racine et intermédiaire sont valides.

Keystore Android

Le keystore est un fichier qui contient les certificats utilisés pour signer votre application Android. Lorsque la période de validité de votre clé expire, les utilisateurs ne peuvent plus mettre à niveau vers les nouvelles versions de votre application.

Certificats d’entreprise Symantec pour Windows Phone

Symantec est le fournisseur exclusif des certificats de signature de code du service Microsoft App Hub. Les développeurs et les éditeurs de logiciels rejoignent le App Hub pour distribuer des applications Windows Phone et Xbox 360 en vue de leur téléchargement via le Windows Marketplace. Pour de plus amples informations, consultez Symantec Code Signing Certificates for Windows Phone dans la documentation de Symantec.
 
Si le certificat expire, les utilisateurs Windows Phone ne peuvent pas s’inscrire, installer une application publiée et signée par l’entreprise, ou démarrer une application d’entreprise qui a été installée sur le téléphone.

NetScaler

Pour de plus amples informations sur la façon de gérer l’expiration des certificats pour NetScaler, consultez l’article How to handle certificate expiry on NetScaler dans le centre de connaissances Citrix.

Un certificat NetScaler ayant expiré empêche les utilisateurs de s’inscrire, d’accéder au Worx Store, de se connecter au Exchange Server lors de l’utilisation de WorxMail, et d’énumérer et d’ouvrir des applications HDX (en fonction du certificat qui a expiré). 

Le Expiry Monitor et le Command Center peuvent vous aider à suivre vos certificats NetScaler et vous informerons lorsque le certificat expire. Ces deux outils permettent d’assurer le suivi des certificats Netscaler suivants :

Certificat SSL pour le nom de domaine complet MDM
Certificat SSL pour le nom de domaine complet de la passerelle
Certificat SSL pour le nom de domaine complet des StorageZone Controller (SZC) ShareFile
Certificat SSL pour l’équilibrage de charge Exchange (configuration de déchargement)
Certificat SSL pour l’équilibrage de charge StoreFront
Certificats d’autorité de certification racine et intermédiaire pour les certificats précédents