Sécurité et VPN : Service RADIUS (Remote Authentication Dial-In User Service)

Guide de certificat pour EAP version 1.01

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document clarifie une partie de la confusion qui accompagne les divers types, formats, et conditions requises de certificat associées avec les diverses formes du Protocole EAP (Extensible Authentication Protocol). Les cinq types de certificat ont associé à l'EAP que ce document discute sont serveur, racine CA, intermédiaire CA, client, et ordinateur. Ces Certificats sont trouvés dans divers formats et il peut y avoir des conditions requises différentes en ce qui concerne chacun d'eux basé sur l'implémentation d'EAP impliquée.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Certificats de serveur

Le certificat de serveur est installé sur le serveur de RAYON et son objectif principal dans l'EAP est de créer le tunnel chiffré de Transport Layer Security (TLS) qui protège les informations d'authentification. Quand vous utilisez EAP-MSCHAPv2, le certificat de serveur prend un rôle secondaire qui est d'identifier le serveur de RAYON comme entité de confiance pour l'authentification. Ce rôle secondaire fait par l'utilisation du champ amélioré de l'utilisation principale (EKU). Le champ EKU identifie le certificat comme certificat de serveur valide et le vérifie que la racine CA qui a délivré le certificat est une racine de confiance CA. Ceci exige la présence du certificat de CA de racine. Le Cisco Secure ACS exige que le certificat soit Base64-encoded ou format DER-encodé de la binaire X.509 v3.

Vous pouvez créer ce certificat avec l'un ou l'autre l'utilisation d'une demande de signature de certificat (CSR) dans ACS, qui est soumis à un CA. Ou, vous pouvez également couper le certificat avec l'utilisation d'une forme interne de création de certificat CA (comme des services de certificat de Microsoft). Il est important de noter que, alors que vous pouvez créer le certificat de serveur avec des tailles de clé plus grandes que 1024, aucun principal plus en grande partie que 1024 ne fonctionne avec le PEAP. Le client s'arrête même si l'authentification passe.

Si vous créez le certificat avec l'utilisation d'un CSR, il est créé avec .cer, un .pem, ou un format de .txt. En de rares occasions, il est créé sans l'extension. Assurez-vous que votre certificat est un fichier de texte brut avec une extension que vous pouvez changer en tant que nécessaire (l'appliance ACS utilise l'extension de .cer ou .pem). Supplémentaire, si vous utilisez un CSR, la clé privée du certificat est créée dans le chemin que vous spécifiez comme fichier séparé qui peut ou peut ne pas avoir une extension et qui a un mot de passe associé avec lui (le mot de passe est exigée pour l'installation sur ACS). Indépendamment de l'extension, assurez-vous que c'est un fichier de texte brut avec une extension que vous pouvez changer en tant que nécessaire (l'appliance ACS utilise l'extension .pvk ou .pem). Si aucun chemin n'est spécifié pour la clé privée, ACS enregistre la clé dans C:\Program Files \CiscoSecure ACS vx.x \ CSAdmin \ logs répertoire et aspects dans ce répertoire si aucun chemin n'est spécifié pour le fichier principal privé quand vous installez le certificat.

Si le certificat est créé avec l'utilisation de la forme de soumission de certificat de services de certificat de Microsoft, assurez-vous que vous marquez les clés comme exportable de sorte que vous puissiez installer le certificat dans ACS. La création d'un certificat simplifie de cette manière le processus d'installation de manière significative. Vous pouvez directement l'installer dans la mémoire appropriée de Windows de l'interface web de services de certificat et alors l'installer sur ACS de mémoire avec l'utilisation de la NC comme référence. Un certificat installé dans la boutique informatique d'ordinateur local peut également être exporté de la mémoire de Windows et être installé sur un autre ordinateur facilement. Quand ce type de certificat est exporté, les clés doivent être marquées en tant qu'exportable et être données un mot de passe. Le certificat apparaît alors dans le format .pfx qui inclut la clé privée et le certificat de serveur.

Une fois correctement installé dans la mémoire de certificat de Windows, le certificat de serveur doit apparaître dans les Certificats (ordinateur local) > personnel > répertoire de Certificats comme vu dans cette fenêtre d'exemple.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-1.gif

les Certificats Auto-signés sont vous délivrent un certificat créent sans racine ou implication intermédiaire du CA. Ils ont la même valeur dans les domaines de sujet et d'émetteur comme un certificat de CA de racine. La plupart de format auto-signé de l'utilisation X.509 v1 de Certificats. Par conséquent, ils ne fonctionnent pas avec ACS. Cependant, en date de la version 3.3, ACS a la capacité de créer ses propres Certificats auto-signés que vous pouvez utiliser pour l'EAP-TLS et le PEAP. N'utilisez pas une taille de clé plus grande que 1024 pour la compatibilité avec le PEAP et l'EAP-TLS. Si vous utilisez un certificat auto-signé, le certificat également agit en qualité du certificat de CA de racine et doit être installé dans les Certificats (ordinateur local) > répertoire d'Autorités de certification racine approuvée > de Certificats du client quand vous utilisez le suppliant d'EAP de Microsoft. Il installe automatiquement dans la mémoire de confiance de certificats racine sur le serveur. Cependant, il doit sont de confiance toujours dans la liste de confiance de certificat dans l'installation de certificat ACS. Voyez le pour en savoir plus de section de Certificats CA de racine.

Puisque des Certificats auto-signés sont utilisés comme certificat de CA de racine pour la validation de certificat de serveur quand vous utilisez le suppliant d'EAP de Microsoft, et parce que la période de validité ne peut pas être augmentée du par défaut d'un an, Cisco recommande que vous les utilisiez seulement pour l'EAP comme mesure provisoire jusqu'à ce que vous puissiez utiliser un CA traditionnel.

Champ Subject

Le champ Subject identifie le certificat. La valeur NC est utilisée pour déterminer émis pour mettre en place dans l'onglet Général du certificat et est remplie avec les informations que vous écrivez dans le domaine de certificat dialogue CSR dans ACS '' ou avec les informations de la zone d'identification dans des services de certificat de Microsoft. La valeur NC est utilisée pour indiquer à ACS quel certificat elle doit utiliser de la mémoire de certificat d'ordinateur local si l'option d'installer le certificat de la mémoire est utilisée.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-2.gif

Champ d'émetteur

Le champ d'émetteur identifie le CA qui coupe le certificat. Employez cette valeur afin de déterminer la valeur du émis par le champ dans l'onglet Général du certificat. Il est rempli avec le nom du CA.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-3.gif

Champ amélioré d'utilisation principale

Le champ amélioré d'utilisation principale identifie le but visé du certificat et doit être répertorié en tant que « authentification de serveur ». Ce champ est obligatoire quand vous utilisez le suppliant de Microsoft pour le PEAP et l'EAP-TLS. Quand vous utilisez des services de certificat de Microsoft, ceci est configuré dans le CA autonome avec la sélection du certificat d'authentification de serveur du déroulant de but visé et à l'entreprise CA avec la sélection du serveur Web du déroulant de modèle de certificat. Si vous demandez un certificat avec l'utilisation d'un CSR avec des services de certificat de Microsoft, vous n'avez pas l'option de spécifier le but visé avec le CA autonome. Par conséquent, le champ EKU est absent. Avec l'entreprise CA, vous avez le déroulant de but visé. Quelques CAs ne créent pas des Certificats avec un champ EKU ainsi ils sont inutiles quand vous utilisez le suppliant d'EAP de Microsoft.

eap-v101-cert-guide-4.gif

Certificats CA de racine

L'un but du certificat de CA de racine est d'identifier le certificat de serveur (et le certificat de CA intermédiaire si c'est approprié) comme certificat de confiance à ACS et au suppliant de Windows EAP-MSCHAPv2. Il doit se trouvent dans la mémoire d'Autorités de certification racine approuvée dans Windows sur le serveur ACS et, dans le cas d'EAP-MSCHAPv2, sur l'ordinateur client. La plupart des Certificats CA de racine de tiers sont installés avec Windows et il y a peu d'effort impliqué de ceci. Si des services de certificat de Microsoft sont utilisés et le serveur de certificat est sur le même ordinateur qu'ACS, alors le certificat de CA de racine est installé automatiquement. Si le certificat de CA de racine n'est pas trouvé dans la mémoire d'Autorités de certification racine approuvée dans Windows, alors il doit être saisi de votre CA et être installé. Une fois correctement installé dans la mémoire de certificat de Windows, le certificat de CA de racine doit apparaître dans les Certificats (ordinateur local) > répertoire d'Autorités de certification racine approuvée > de Certificats comme vu dans cette fenêtre d'exemple.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-5.gif

Champs de sujet et d'émetteur

Les champs de sujet et d'émetteur identifient le CA et doivent être exactement identiques. Employez ces champs pour remplir fourni à et émis par des champs dans l'onglet Général du certificat. Ils sont remplis avec le nom de la racine CA.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-6.gif

Certificats CA intermédiaires

Les Certificats CA intermédiaires sont des Certificats que vous utilisez pour identifier un CA qui est subalterne à une racine CA. Quelques Certificats de serveur (les Certificats Sans fil de Verisign) sont créés avec l'utilisation d'une intermédiaire CA. Si un certificat de serveur qui est coupé par un intermédiaire CA est utilisé, le certificat de CA intermédiaire doit être installé dans la région intermédiaire d'autorités de certification de la mémoire d'ordinateur local sur le serveur ACS. En outre, si le suppliant d'EAP de Microsoft est utilisé sur le client, le certificat de CA de racine de la racine CA qui a créé le certificat de CA intermédiaire doit également être dans la mémoire appropriée sur le serveur ACS et le client de sorte que la chaîne de la confiance puisse être établie. Le certificat de CA de racine et le certificat de CA intermédiaire doivent être marqués en tant que fait confiance dans ACS et sur le client. La plupart des Certificats CA d'intermédiaire ne sont pas installés avec Windows ainsi vous le besoin le plus susceptible de les saisir du constructeur. Une fois correctement installé dans la mémoire de certificat de Windows, le certificat de CA intermédiaire apparaît dans les Certificats (ordinateur local) > répertoire intermédiaire d'autorités > de Certificats de certification comme vu dans cette fenêtre d'exemple.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-7.gif

Champ Subject

Le champ Subject identifie l'intermédiaire CA. Cette valeur est utilisée pour déterminer émis pour mettre en place dans l'onglet Général du certificat.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-8.gif

Champ d'émetteur

Le champ d'émetteur identifie le CA qui coupe le certificat. Employez cette valeur afin de déterminer la valeur du émis par le champ dans l'onglet Général du certificat. Il est rempli avec le nom du CA.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-9.gif

Certificats client

Des certificats client sont utilisés pour identifier franchement l'utilisateur dans l'EAP-TLS. Ils n'ont aucun rôle en construisant le TLS tunnel et ne sont pas utilisés pour le cryptage. L'identification sans équivoque est accomplie par l'un de trois signifie :

  • Comparaison NC (ou nom) — Compare la NC dans le certificat au nom d'utilisateur dans la base de données. Plus d'informations sur ce type de comparaison sont incluses dans la description du champ Subject du certificat.

  • Comparaison SAN — Compare le SAN dans le certificat au nom d'utilisateur dans la base de données. Ceci est seulement pris en charge en date d'ACS 3.2. Plus d'informations sur ce type de comparaison sont incluses dans la description de la zone d'identification alternative soumise du certificat.

  • Comparaison binaire — Compare le certificat à une copie binaire du certificat enregistré dans la base de données (seulement l'AD et le LDAP peuvent faire ceci). Si vous utilisez la comparaison binaire de certificat, vous devez enregistrer le certificat utilisateur dans un format binaire. En outre, pour le LDAP et le Répertoire actif génériques, l'attribut qui enregistre le certificat doit être l'attribut standard de LDAP nommé « usercertificate ».

Qu'est ce que méthode de comparaison est utilisée, les informations dans le champ approprié (NC ou SAN) doivent apparier le nom que votre base de données utilise pour l'authentification. L'AD utilise le nom de Netbios pour l'authentification dans le mode mixte et l'UPN dans le mode natif.

Cette section discute la génération de certificat client avec l'utilisation des services de certificat de Microsoft. L'EAP-TLS exige d'un seul certificat client pour que chaque utilisateur soit authentifié. Le certificat doit être installé sur chaque ordinateur pour chaque utilisateur. Une fois correctement installé, le certificat se trouve dans les Certificats - utilisateur courant > personnel > répertoire de Certificats comme vu dans cette fenêtre d'exemple.

eap-v101-cert-guide-10.gif

Champ d'émetteur

Le champ d'émetteur identifie le CA qui coupe le certificat. Employez cette valeur afin de déterminer la valeur du émis par le champ dans l'onglet Général du certificat. Ceci est rempli avec le nom du CA.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-11.gif

Champ amélioré d'utilisation principale

Le champ amélioré d'utilisation principale identifie le but visé du certificat et doit contenir l'authentification client. Ce champ est obligatoire quand vous utilisez le suppliant de Microsoft pour le PEAP et l'EAP-TLS. Quand vous utilisez des services de certificat de Microsoft, ceci est configuré dans le CA autonome quand vous sélectionnez le certificat d'authentification client du déroulant de but visé et à l'entreprise CA quand vous sélectionnez l'utilisateur du déroulant de modèle de certificat. Si vous demandez un certificat avec l'utilisation d'un CSR avec des services de certificat de Microsoft, vous n'avez pas l'option de spécifier le but visé avec le CA autonome. Par conséquent, le champ EKU est absent. Avec l'entreprise CA, vous avez le déroulant de but visé. Quelques CAs ne créent pas des Certificats avec un champ EKU. Ils sont inutiles quand vous utilisez le suppliant d'EAP de Microsoft.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-12.gif

Champ Subject

Ce champ est utilisé dans la comparaison NC. La première NC répertoriée est comparée contre la base de données pour trouver une correspondance. Si une correspondance est trouvée, l'authentification réussit. Si vous utilisez un CA autonome, la NC est remplie avec celui que vous mettiez dans la zone d'identification sous la forme de soumission de certificat. Si vous utilisez l'entreprise CA, la NC est automatiquement remplie avec le nom du compte comme répertorié dans le pupitre de commandes d'utilisateurs et de Répertoire actif (ceci n'apparie pas nécessairement l'UPN ou le nom de Netbios).

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-13.gif

Zone d'identification alternative soumise

La zone d'identification alternative soumise est utilisée dans la comparaison SAN. Le SAN répertorié est comparé contre la base de données pour trouver une correspondance. Si une correspondance est trouvée, l'authentification réussit. Si vous utilisez l'entreprise CA, le SAN est automatiquement rempli avec le @domain de nom de connexion de Répertoire actif (UPN). Le CA autonome n'inclut pas un champ SAN ainsi vous ne pouvez pas utiliser la comparaison SAN.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-14.gif

Certificats d'ordinateur

Des Certificats d'ordinateur sont utilisés dans l'EAP-TLS pour identifier franchement l'ordinateur quand vous utilisez l'authentification de machine. Vous pouvez seulement accéder à ces Certificats quand vous configurez votre entreprise CA de Microsoft pour l'Auto-inscription de certificat et joignez l'ordinateur au domaine. Le certificat est automatiquement créé quand vous utilisez les qualifications de Répertoire actif de l'ordinateur et les installez dans la boutique informatique d'ordinateur local. Les ordinateurs qui sont déjà des membres du domaine avant que vous configuriez l'Auto-inscription reçoivent un certificat la prochaine fois que Windows redémarre. Le certificat d'ordinateur est installé dans les Certificats (ordinateur local) > personnel > répertoire de Certificats des Certificats (ordinateur local) MMC SNAP-dans juste les Certificats de serveur similaires. Vous ne pouvez pas installer ces Certificats sur aucun autre ordinateur puisque vous ne pouvez pas exporter la clé privée.

Sujet et champs SAN

Le sujet et les champs SAN identifient l'ordinateur. La valeur est remplie par entièrement - le nom qualifié de l'ordinateur et est utilisée afin de déterminer émis pour mettre en place dans l'onglet Général du certificat et est identique pour le sujet et les champs SAN.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-15.gif

Champ d'émetteur

Le champ d'émetteur identifie le CA qui coupe le certificat. Employez cette valeur afin de déterminer la valeur du émis par le champ dans l'onglet Général du certificat. Il est rempli avec le nom du CA.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-16.gif

Annexe A - Extensions communes de certificat

.csr — Ce n'est pas réellement un certificat mais plutôt une demande de signature de certificat. C'est un fichier de texte brut avec ce format :

eap-v101-cert-guide-17.gif

.pvk — Cette extension dénote une clé privée bien que l'extension ne garantisse pas que le contenu est réellement une clé privée. La nécessité satisfaite d'être texte brut avec ce format :

eap-v101-cert-guide-18.gif

.cer — C'est une extension générique qui dénote un certificat. Le serveur, la racine CA, et les Certificats CA intermédiaires peuvent être dans ce format. C'est généralement un fichier de texte brut avec une extension que vous pouvez changer pendant que vous avez besoin et pouvez être DER ou baser de format 64. Vous pouvez importer ce format dans la mémoire de certificat de Windows.

.pem — Cette extension signifie le Privacy Enhanced Mail. Cette extension est utilisée généralement avec l'UNIX, Linux, BSD, et ainsi de suite. Il est généralement utilisé pour des Certificats de serveur et des clés privées, et est généralement un fichier de texte brut avec une extension que vous pouvez changer pendant que vous avez besoin de .pem à .cer de sorte que vous puissiez l'importer à la mémoire de certificat de Windows.

Le contenu interne de .cer et des fichiers .pem ressemble à généralement cette sortie :

eap-v101-cert-guide-19.gif

.pfx — Cette extension signifie l'échange de données personnelles. Ce format est une méthode que vous pouvez employer pour empaqueter des Certificats dans un fichier unique. Par exemple, vous pouvez empaqueter un certificat de serveur et son certificat de CA associé de clé privée et de racine dans un fichier et facilement importer le fichier dans la mémoire appropriée de certificat de Windows. Il est le plus utilisé généralement pour le serveur et les certificats client. Malheureusement, si un certificat de CA de racine est inclus, le certificat de CA de racine est toujours installé dans la mémoire d'utilisateur courant au lieu de la boutique informatique d'ordinateur local même si la boutique informatique d'ordinateur local est spécifiée pour l'installation.

.p12 — Ce format généralement est seulement vu avec un certificat client. Vous pouvez importer ce format dans la mémoire de certificat de Windows.

.p7b — C'est un autre format qui de plusieurs Certificats de mémoires dans un fichier. Vous pouvez importer ce format dans la mémoire de certificat de Windows.

Annexe B - Conversion de format de certificat

Dans la plupart des cas, la conversion de certificat se produit quand vous changez l'extension (par exemple, de .pem à .cer) puisque les Certificats sont généralement dans le format de texte brut. Parfois, un certificat n'est pas dans le format de plaintext et vous devez le convertir avec l'utilisation d'un outil tel qu'OpenSSLleavingcisco.com . Par exemple, les ACS Solution Engine ne peuvent pas installer des Certificats dans le format .pfx. Par conséquent, vous devez convertir le certificat et la clé privée en format utilisable. C'est la syntaxe de commande de base pour OpenSSL :

openssl pkcs12 -in c:\certs \test.pfx -out c:\certs \test.pem

Vous êtes incité pour le mot de passe d'importation et le mot de passe PEM. Ces mots de passe doivent être identiques et sont le mot de passe de clé privée qui est spécifié quand le .pfx est exporté. La sortie est un fichier simple .pem qui inclut tous les Certificats et clés privées dans le .pfx. Ce fichier peut être mentionné dans ACS pendant que le certificat et le fichier principal privé et lui installe sans des problèmes.

Annexe C - Période de validité de certificat

Un certificat est seulement utilisable au cours de sa période de validité. La période de validité pour un certificat de CA de racine est déterminée quand la racine CA est établie et peut varier. La période de validité pour un certificat de CA intermédiaire est déterminée quand le CA est établi et ne peut pas dépasser la période de validité de la racine CA à laquelle c'est subalterne. La période de validité pour le serveur, le client, et les Certificats d'ordinateur est automatiquement placé à un an avec des services de certificat de Microsoft. Ceci peut seulement être changé quand vous entaillez le registre de Windows selon l'article 254632 de base de connaissances de Microsoftleavingcisco.com et ne peut pas dépasser la période de validité de la racine CA. La période de validité des Certificats auto-signés qu'ACS génère est toujours d'un an et ne peut pas être changée dans des versions en cours.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 64062