Créer des certificats

Créez des certificats dans le cadre de l'installation de PEG.

Prérequis

Vous pouvez créer des certificats en utilisant l'une des deux options suivantes.
Dans les deux cas, vous aurez besoin des éléments suivants :
  • Identifiant unique (UID) : chaque machine virtuelle PEG que vous exécutez doit avoir un identifiant unique. Vous pouvez définir l'UID comme vous le souhaitez, à condition qu'il réponde aux critères suivants :
    • Longueur inférieure ou égale à 18 caractères
    • Contient uniquement des lettres de a à z, des chiffres de 0 à 9 ou des tirets
    • Ne doit pas commencer ou se terminer par un tiret
    • Ne doit pas contenir de traits d'union consécutifs
    • Conseil : Pour créer facilement un UID, prenez les 18 derniers caractères d'un GUID généré par un générateur de GUID en ligne.
  • Le domaine Apex que vous voulez utiliser pour les noms du DNS de PEG (par exemple, example.com)

Option 2 - Créez vos propres clés et certificats

Apprenez à créer des clés et des certificats avant de déployer PEG.

Les clés et les certificats doivent être au format Base64 PEM (appelé format openssl ou PKCS #8 pour les clés dans certains systèmes). Créez des certificats conformément à Tâches courantes - Création des certificats. Les clés ne doivent pas être protégées par un mot de passe. Veillez également à ce que vos clés correspondent aux noms de fichiers figurant dans la colonne Nom du fichier de clés de Tâches courantes - Création des certificats.

Il est important de vérifier que le certificat collé dans le terminal correspond exactement au certificat source. Certaines applications peuvent ajouter un caractère masqué au fichier lors de la copie et du collage. Pour éviter tout problème, suivez les étapes ci-dessous.

  • Vérifier le contenu du fichier : après avoir collé le contenu dans le fichier, utilisez un éditeur de texte (comme nano, vim ou gedit) pour vérifier que le fichier ne contient pas de caractères indésirables à la fin.
  • Utilisez l'écho avec redirection : au lieu de coller directement le contenu, utilisez l'écho avec redirection pour créer le fichier. Cela réduit le risque de caractères cachés.
  • Utilisez scp pour copier les fichiers de votre système local vers une instance distante au lieu de les copier.

Tâches courantes - Création des certificats

Apprenez à créer des certificats Base64 PEM.

Lorsque vous créez les certificats, créez six certificats serveur Base64 PEM (appelés format openssl dans certains systèmes), avec des noms de domaine et des noms de fichier mappés comme suit, où l'UID vous est fourni par Découverte du processus et le domaine Apex est le domaine Apex que vous utiliserez pour PEG. Chaque certificat créé ne doit contenir que le certificat feuille et non la chaîne complète.

Tableau 1. Mappage des noms de domaines aux noms de fichiers de certificats
Domaine Nom du fichier de certificat Nom du fichier de clés (requis uniquement si vous avez créé vos propres clés)
analytics-fiq-<UID>.<apex domain> analytics-cert.pem analytics-key.pem
proxy-fiq-<UID>.<apex domain> proxy-cert.pem proxy-key.pem
storage-fiq-<UID>.<apex domain> storage-cert.pem storage-key.pem
st-fiq-<UID>.<apex domain> st-cert.pem st-key.pem
dlp-fiq-<UID>.<apex domain> dlp-cert.pem dlp-key.pem
es-fiq-<UID>.<apex domain> es-cert.pem es-key.pem
klite-fiq-<UID>.<apex domain> klite-cert.pem klite-key.pem
Remarque : Vous pouvez créer un certificat avec tous les SAN. Si vous créez des clés, vous avez également la possibilité de n'en créer qu'une seule si vous le souhaitez. Cependant, vous devrez toujours vous assurer qu'il existe sept copies de ce certificat et sept copies de cette clé (si vous avez créé des clés) nommées comme indiqué précédemment. Ne créez pas de certificat générique.

Considérations

Passez en revue les points suivants sur la création de certificats pour l'installation de PEG :
  • Les certificats génériques ne sont pas autorisés : vous ne pouvez pas utiliser de certificats génériques pour les déploiements PEG. Chaque certificat doit être créé individuellement pour chaque service avec un nom de domaine spécifique.
  • Les certificats ne sont pas valables à l'échelle globale : les certificats générés par une autorité de certification interne ne sont pas reconnus comme étant globalement fiables par les systèmes externes ; ils doivent donc être approuvés manuellement sur tous les périphériques ou services client.
  • Validation manuelle des certificats : les certificats doivent être validés manuellement à chaque étape de déploiement pour garantir qu'ils sont corrects et qu'ils n'ont pas été corrompus ou falsifiés pendant le transfert.
  • Transfert manuel des certificats : les certificats doivent être copiés manuellement sur les machines virtuelles (VM). Si la copie n'est pas faite correctement ou si les fichiers sont modifiés pendant le processus de copie, des erreurs peuvent survenir.
  • Vérification de la validité des certificats sur toutes les machines : il est essentiel de confirmer que tous les certificats sont valides et correctement installés sur toute machine qui doit accéder aux services sécurisés par ces certificats.
  • Pas de renouvellement automatique des certificats : étant donné que les certificats internes ne sont pas intégrés aux systèmes des autorités de certification globaux, il n'existe pas de processus de renouvellement automatisé. Les administrateurs doivent suivre et renouveler manuellement les certificats avant leur expiration pour éviter les interruptions de service.
  • Configuration supplémentaire pour l'approbation : chaque client ou système accédant aux services PEG doit être configuré manuellement pour approuver les certificats d'autorité de certification internes. Cela peut impliquer l'installation de certificats racine ou l'ajustement des paramètres de sécurité.
  • Risque d'erreur humaine : la nature manuelle de la création, de la validation et de la distribution des certificats augmente la probabilité d'erreurs humaines, telles que des noms de fichiers incorrects, des configurations non valides ou des certificats manquants.
  • Révocation et audits limités : les configurations d'autorités de certification internes peuvent manquer de mécanismes de révocation sophistiqués (listes de révocation de certificats, OCSP, etc.), ce qui complique la révocation des certificats compromis ou expirés et l'audit efficace de leur utilisation.
  • Difficulté de mise à l'échelle : la gestion manuelle d'un grand nombre de certificats sur plusieurs machines virtuelles et environnements peut devenir difficile à mesure que le système évolue, et nécessiter des processus dédiés pour garantir la cohérence.