Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Utiliser des certificats numériques

Suivez ces étapes pour générer et utiliser des certificats pour le serveur RADIUS intégré à Juniper Mist Access Assurance pour chaque organisation.

Lors de l’utilisation de l’authentification EAP, le client et le serveur doivent vérifier l’identité de l’autre. Le client doit faire confiance au serveur avec lequel il communique, et le serveur doit authentifier le client. Le certificat du serveur est la première étape de ce processus d’authentification mutuelle, et le client doit le valider ou lui faire confiance avant de poursuivre la communication.

Si nous examinons n’importe quelle transaction EAP (par exemple EAP-TLS ou EAP-TTLS), qu’il s’agisse d’une authentification sans fil ou filaire, la première étape consiste pour le serveur à s’identifier lui-même en envoyant un message « Server Hello » à l’appareil client.

Lorsqu’un appareil client reçoit un certificat de serveur, il examine la liste des autorités de certification (CA) de confiance dans le profil Wi-Fi ou LAN et vérifie si le certificat de serveur est signé par l’une des autorités de certification approuvées. Si elle est configurée, vérifie si le nom du serveur correspond à la liste des noms de serveurs approuvés dans la configuration du client.

Nous vous recommandons de ne pas ignorer l’étape de validation et le certificat du serveur de confiance. Il s’agit d’un risque élevé pour la sécurité et peut ouvrir des attaques MITM (Man in the middle).

Vous pouvez utiliser l’une des méthodes suivantes pour générer et utiliser des certificats pour le serveur RADIUS intégré à Juniper Mist Access Assurance pour chaque organisation.

  • Certificat d’AC : Juniper Mist nécessite des certificats d’AC spécifiques pour établir la confiance avec vos appareils clients. Ces certificats, émis par des autorités de certification (CA) de confiance, permettent à Juniper Mist Access Assurance d’accorder l’accès réseau aux appareils clients. La validation des appareils clients par Juniper Mist repose sur la présentation de certificats par les appareils, qui doivent être signés par le même AC.
  • Certificat Juniper Mist Access Assurance par défaut : l’organisation Mist conserve son autorité de certification (AC) Mist privée unique et responsable de l’émission du certificat du serveur Access Assurance. En l’absence de configurations spécifiques, les clients recevront un certificat par défaut authentifié par leur AC Mist Org respective. Ce certificat correspond au domaine « auth.mist.com ».
  • Certificat de serveur personnalisé : le certificat de serveur personnalisé est privilégié lorsque vous préférez ne pas modifier la configuration du client actuel et que vous souhaitez que les clients approuvent les certificats de serveur émis par la même autorité de certification (AC) qui a fourni les certificats client. Vous devez entrer la clé privée et le certificat signé que vous avez obtenus de votre serveur RADIUS.

Lisez les procédures suivantes pour comprendre comment utiliser les certificats ci-dessus.

Utiliser un certificat d’autorité de certification (AC)

Pour que l’authentification basée sur les certificats EAP-TLS (Extensible Authentication Protocol–couche transport Sécurité fonctionne, vous devez ajouter le certificat AC approuvé sur le portail Mist Juniper.

Cette étape permet à l’authentification d’accès Juniper Mist d’approuver les certificats clients signés par vos autorités de certification ajoutées.

Vous pouvez obtenir le certificat à partir d’un AC externe. Il peut s AC’agir d’un AC public bien connu ou d’un AC d’entreprise.

Regardez la vidéo suivante pour savoir comment générer un certificat à des fins de test ou d’utilisation en laboratoire :

How to create certificates both CA certificates and client certificates that you could use for lab testing to repeat all the steps in our tutorials. So in order to do things easily and quickly, assuming there is no existing infrastructure, assuming there is nothing you can use that you're available on-hand, you could use some open source tools that are out there on the internet. I will use degree-based certificate authority and key management called XCA.

You can Google it. You can download it. It's available for everyone to use. So now, when we will use XCA tool, first thing we will need to do, we'll need to create a new database. You could think of this creating a specific BQ infrastructure right on your laptop. So we can just say missed access insurance tutorial. Database, save it in there, it will ask you to encrypt it, which is a good thing. Click OK. So now we have the database created.

So the first thing we will need to create our certificate infrastructure is the certificate authority. That's the thing that will sign all the certificates of all your client devices that you will be using for testing. And that's the ultimate source of trust in your BQ infrastructure. So I'm going to click on new certificate. I'm going to select that, this is going to be a self-signed certificate because technically, every certificate authority, the root certificate authority is a self-signed.

Has a self-signed certificate. We'll select the template called CA from this list, will then go to subject. We can give it some internal name but doesn't matter, we could just say lab mist CA. You can fill in some of the data in there. Again, it doesn't really matter what you will put in there. But for testing purposes, just use anything you really like, organization name. Common name is important. This is how you identify certificates in real life. So one of the important attributes is common name. And we will take a look at the other one later, which is called the subject alternative name.

So common name, let's just call it lab-mist-ca@justify.com. Maybe something like this. I'm going to click that. We'll need to create a private key. A private key is what will prove that the certificate-- oh, owned and certificate holder is actually that same device or it's same CA. So we'll generate a new key, we'll set it to be 4,000 bytes, create. It will automatically selected here. It's good. We'll go to extensions. The type will be certification authority. It will add a few attributes in the certificate saying this is a CA cert.

This is where we will add the subject to alternative name. So typically what you'll do is you click edit, you will say I want to copy common name and there. Click apply. That's it. This will typically go and take your common name and copy it into a assign attribute.

Nowadays, many clients are using SAN to validate-- certificate validity. And the key usage, what do we need there? We need certificate signs, CRL sign. That's pretty much it. So we'll click OK. This now created our certificate authority in here. So we have the certificate. This is a CA cert, it has a common name.

The expiry date is, well, next year, but typically CA cert would be valid for like 10 years or something like that. For our intents and purposes, this is just a lot testing one year is more than enough.

So what will then need to do is will create a client cert. So click select our CA, will click new certificate. Now see under signing section, we are going to use this CA cert for signing certificates. It's not going to be self-signed anymore. So now our certificate authority will sign a new certificate that will be issued by the client. This is how we will establish this chain of trust. So create, select the template-- TLS client. We'll go to subject. That just say this is going to be a test lab client. Doesn't matter.

So common name is important. So this is where I would recommend you to use something that is an actual username that you want to use later on with your testing, whether you have an identity provider with your test username or things like that. So in my case, I will use one username I have in my Okta IdP that I will use later on. So I'm going to just use my Juniper email address. I'm going to copy it. We'll need to generate a private key, again, 4,000 bits.

We'll go to extensions, we'll select end entity. We'll click on subject, alternative name. Again, we'll just say copy common name. We'll go to key usage, will now need to select that this is a client certificate not the service certificate. And we will need key encipherments, digital signature, it should be OK. Now we click OK. We now have a client certificate.

So now we see there is a little dropdown in there. So we have a CA but now sign the client certificate. So now we have a CA and now we have a client certificate. What we'll do will need to export the CA. I will click on export. The CA cert, we are only exporting the public certificate, we are not touching the private key. Private Key stays untouched. It it is never exported anywhere. This is the only thing that protects the ownership of that certificate.

So we are exporting the private key in our test folder-- .mistCRT that's all we need. Click OK. The next thing we'll need is we'll need to export the certificate and the private key that we will use for client testing. Again, normally in production environment, you're not going to export private keys, they will be automatically pushed and distributed through MDM securely so they're never exposed to the network or anybody. But in our case, since we're testing, that's OK to do for now. So we'll click export.

In this case, the export format is pfx. That's the format that will include the client certificate, the client private key, and the CA cert in one package. So you can later on imported to one of your testing clients. And generally, this format is well understood by different operating systems.

It will ask you to encrypt that package. So just do a very secure password of 1234. Now we have to search, export it. We have a CA cert and we have a client cert. For now, this is good enough for our testin

Pour ajouter un certificat d’AC :

  1. Dans le menu de gauche du portail Mist Juniper, sélectionnez Certificats > d’accès > d’organisation.
    La page Autorités de certification s’affiche et affiche une liste de certificats.
  2. Cliquez sur Ajouter une autorité de certification.
  3. Collez votre certificat d’AC dans le champ Certificat signé.
    Figure 1 : Ajouter une autorité Add Certificate Authority de certification

    Le texte doit inclure les —–BEGIN CERTIFICATE—– lignes et —–END CERTIFICATE—– .

    Le système analyse et décode le certificat d’AC importé et affiche les propriétés du certificat dans le volet Propriétés . Nous vous recommandons d’ajouter votre AC racine, ainsi que toutes vos autorités de certification intermédiaires ou émettrices de certificats.

Utiliser le certificat de serveur par défaut de Juniper Mist Access Assurance

Le cloud Juniper Mist agit comme une autorité de certification privée (AC) pour chaque organisation ajoutée au cloud Juniper Mist. Juniper Mist émet un certificat de serveur. Si aucun certificat n’est configuré, le portail Juniper Mist présente un certificat de serveur par défaut signé par l’AC Juniper Mist aux appareils clients.

Un certificat sera émis pour le nom auth.mist.com et affichera des informations similaires à celles que vous voyez à la figure 2.

Figure 2 : certificat de serveur émis par Mist Access Assurance Server Certificate Issued by Mist Access Assurance
Côté client, vous devez configurer les appareils clients pour qu’ils fassent confiance au certificat AC Mist et éventuellement valider le nom du certificat du serveur comme auth.mist.com.

Pour télécharger le certificat du serveur Juniper Mist :

  1. Dans le menu de gauche de Juniper portail Mist, sélectionnez Organisation > Accès > Certificats.
    La page Autorités de certification s’affiche et affiche une liste de certificats.
  2. Cliquez sur Afficher le certificat Mist.
    L’écran affiche les détails du certificat signé . Copiez le contenu du certificat à partir du champ Certificat signé .
    Figure 3 : Affichage et copie du certificat View and Copy Mist Certificate Mist
  3. Stockez le contenu du certificat sur votre ordinateur local et ajoutez l’extension .crt ou .cer dans le nom du fichier. Par exemple : mymistorgca.crt.
  4. Importez le fichier de certificat sur tous vos appareils clients en tant que certificat racine approuvé.

    Une fois que vous avez configuré un appareil client pour qu’il fasse confiance au Juniper Mist AC certificat, vous pouvez utiliser le certificat jusqu’à ce qu’il soit valide.

Utiliser des certificats de serveur personnalisés

Vous disposez peut-être déjà d’une PKI et souhaitez conserver la configuration existante intacte. Dans un tel scénario, vous devez charger le certificat public de votre AC racine et la paire de clés publique/privée du serveur RADIUS sur le portail Mist Juniper.

Assurez-vous que vos appareils clients utilisent également les mêmes certificats afin que le serveur RADIUS valide le certificat de chaque client (demandeur). Effectuez cette tâche si vous souhaitez conserver la configuration actuelle de vos clients inchangée et que vous souhaitez que les clients approuvent le certificat de serveur émis par le même AC qui a émis leurs certificats.

Pour télécharger votre certificat sur le portail Juniper Mist :

  1. Dans le menu de gauche de Juniper portail Mist, sélectionnez Organisation > Accès > Certificats.
    La page s’affiche et affiche une liste de certificats.
  2. Cliquez sur Importer un certificat Radius personnalisé pour ouvrir la page du certificat.
    Figure 4 : Importation d’un certificat Import Custom RADIUS Server Certificate de serveur RADIUS personnalisé
  3. Sur la page Importer un certificat RADIUS Server personnalisé, entrez les détails de votre certificat d’AC :
    Figure 5 : Entrer les détails Enter Custom Server Certificate Details du certificat de serveur personnalisé
    • Clé privée : copiez et collez les informations de clé privée. Le texte doit inclure les BEGIN RSA PRIVATE KEY lignes et END RSA PRIVATE KEY .
    • Mot de passe de la clé privée : entrez la phrase secrète de la clé privée (si disponible).
    • Certificat signé : copiez et collez le certificat sous forme de texte. Assurez-vous d’inclure toutes les autorités de certification intermédiaires et le certificat de l’AC racine. Le texte doit inclure les —–BEGIN CERTIFICATE—– lignes et —–END CERTIFICATE—– .
  4. Cliquez sur Enregistrer.
  5. Configurez vos appareils clients pour qu’ils fassent confiance à l’autorité de certification racine (AC) qui a signé votre certificat de serveur.
    Avec cette étape, vous vous assurez que lorsque vous mettez à jour ou modifiez votre certificat de serveur (ce qui est généralement fait tous les ans ou après quelques années), les appareils clients feront confiance au nouveau certificat de serveur parce qu’ils font confiance à l’AC parent qui l’a signé.

Guidelines for using custom server certificates:

  • Do not use a wildcard certificate, for example: *.abc.com for 802.1X authentication.
  • You can use a certificate that contains a common name (CN) or a subject alternative name (SAN) for 802.1X authentication..
  • We recommend the following x509 extension attributes. The majority of the client device operating systems support these extensions.
    • Use certificate version 3 or v3 (not legacy v1)
    • If the server name is being used as a validation criterion on the client side, then the certificate should include the SAN extension with the DNS name of the server.
    • Include Extended Key Usage as a TLS web server authentication criterion (required for most Android devices).

Vous pouvez maintenant poursuivre le processus d’authentification basée sur les certificats.

Exigences relatives aux certificats clients

Lors de la mise en œuvre de l’authentification basée sur les certificats avec Juniper Mist Access Assurance, les certificats client doivent répondre à des exigences spécifiques pour garantir le bon fonctionnement de fonctionnalités telles que les recherches IdP et l’intégration MDM.

Exigences de sécurité

Les certificats clients doivent répondre aux normes de sécurité minimales suivantes :

  • Type de certificat : certificat X.509 v3
  • Longueur de la clé : 2048 bits ou plus (4096 bits recommandés) ou ECDSA (P-256 ou plus)
  • Algorithme de signature : SHA-256 ou plus fort (SHA-384, SHA-512)
  • Extensions requises : Utilisation étendue des clés avec authentification du client (1.3.6.1.5.5.7.3.2)

Exigences relatives aux recherches de fournisseur d’identité

Pour une correspondance réussie de l’identité de l’utilisateur avec votre IdP, assurez-vous que vos certificats client incluent l’un des champs suivants. La recherche doit être effectuée à l’aide du nom de l’utilisateur principal dans le cloud IdP (format user@domain.xyz). Les champs suivants sont vérifiés dans l’ordre indiqué ci-dessous :

  • Sujet Nom usuel (CN)
  • Nom alternatif de l’objet - UPN (SAN :UPN)
  • Objet : Nom alternatif - E-mail (SAN :Email)
Remarque : L’ordre de préférence de recherche ci-dessus peut être ajusté à l’aide de l’API.

Comportement de recherche du fournisseur d’identité pour les certificats d’ordinateur

Pour une correspondance réussie de l’identité machine avec votre IdP (concerne principalement Entra ID, car les autres IdP cloud n’ont pas d’identité machine), assurez-vous que vos certificats client incluent l’un des champs suivants.

La recherche doit se faire à l’aide du nom de l’appareil (à l’exclusion du nom de domaine) dans votre EntraID. Les champs suivants sont vérifiés dans l’ordre indiqué ci-dessous :

  • Sujet Nom usuel (CN)
  • Nom alternatif du sujet - DNS (SAN :DNS)
Remarque : L’ordre de préférence de recherche ci-dessus peut être ajusté à l’aide de l’API.

Considérations relatives à l’intégration MDM

Lorsque vous utilisez des certificats avec des solutions MDM :

  • Incluez les identifiants d’appareil dans le certificat (tels que DeviceId ou UDID dans le champ SAN :DNS) pour les recherches basées sur l’appareil.
  • Consultez la documentation d’intégration pertinente pour chaque fournisseur de MDM sur le portail de documentation de Juniper : NAC Juniper Mist Access Assurance
Conseil :

Testez la configuration de votre certificat avec un petit ensemble d’appareils avant de le déployer à l’échelle de l’organisation pour vous assurer que toutes les fonctionnalités d’Access Assurance fonctionnent correctement.