Cette page a été traduite par l'API Cloud Translation.

Créer des keystores et des Truststores pour le cloud privé 4.17.09 et les versions antérieures

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info

Ce document explique comment créer, modifier et supprimer des keystores et des truststores pour Edge pour Private Cloud version 4.17.09 et antérieure.

À propos des keystores et des truststores

Les keystores et les Truststores définissent des référentiels de certificats de sécurité utilisés pour TLS. le chiffrement. La principale différence entre les deux est l'endroit où elles sont utilisées dans le processus d'établissement de la liaison TLS :

Un keystore contient un certificat TLS et une clé privée permettant d'identifier lors du handshake TLS.

Dans le TLS à sens unique, lorsqu'un client se connecte au point de terminaison TLS sur le serveur, le keystore du serveur présente le certificat du serveur (certificat public) au client. Le client valide ensuite ce certificat auprès d'une autorité de certification (AC), telle que Symantec ou VeriSign.

Avec le protocole TLS bidirectionnel, le client et le serveur gèrent tous deux un keystore avec leur propre certificat et clé privée utilisée pour l'authentification mutuelle.
Un truststore contient des certificats utilisés pour vérifier les certificats reçus en tant que lors d'un handshake TLS.

Dans le TLS à sens unique, un truststore n'est pas nécessaire si le certificat est signé par une autorité de certification valide. Si le reçu par un client TLS est signé par une autorité de certification valide, puis le client fait une demande à l'autorité de certification pour authentifier le certificat. Un client TLS utilise généralement un truststore pour valider les certificats autosignés reçus du serveur TLS ou les certificats qui ne sont pas signés par une autorité de certification de confiance. Dans ce scénario, le client remplit son truststore avec les certificats qu'il approuve. Ensuite, lorsque le client reçoit un certificat de serveur, le certificat entrant est validés par rapport aux certificats de son Truststore.

Par exemple, un client TLS se connecte à un serveur TLS où le serveur utilise un certificat autosigné. Comme il s'agit d'un certificat autosigné, le client ne peut pas le valider auprès d'une autorité de certification. À la place, le client précharge le certificat autosigné du serveur dans son Truststore. Ensuite, lorsque le client tente de se connecter au serveur, il utilise son truststore pour valider le certificat reçu du serveur.

Pour le TLS bidirectionnel, le client TLS et le serveur TLS peuvent utiliser un truststore. Un truststore est requis lorsque vous effectuez un TLS bidirectionnel lorsque Edge agit en tant que serveur TLS.

Les certificats peuvent être émis par une autorité de certification (AC) ou être autosignés par la clé privée que vous générez. Si vous avez accès à une autorité de certification, suivez les instructions fournies par votre autorité de certification pour générer des clés et émettre des certificats. Si vous n'avez pas accès à une autorité de certification, vous pouvez générer un certificat autosigné à l'aide de l'un des nombreux outils gratuits disponibles publiquement, tels que openssl.

L'implémentation d'un keystore et truststore sur Edge

Dans Edge, un keystore contient un ou plusieurs fichiers JAR, dans lesquels le fichier JAR contient :

Certificat TLS sous forme de fichier PEM : certificat signé par une autorité de certification une chaîne de certificats dans laquelle le dernier certificat est signé par une autorité de certification, ou un certificat autosigné certificat.
Clé privée au format PEM Edge prend en charge des tailles de clé allant jusqu'à 2 048 bits. Une phrase secrète est (facultatif).

Un Truststore est semblable à un keystore, sauf qu'il ne contient que des certificats sous la forme d'un fichier PEM, mais pas clés privées.

Si le certificat fait partie d'une chaîne, le keystore/truststore doit contenir tous les certificats de la chaîne, soit sous forme de fichiers PEM individuels, soit sous forme de fichier unique. Si vous n'utilisez qu'un seul fichier, Les certificats doivent être dans l'ordre, le premier certificat du fichier étant celui utilisé pour TLS suivi par la chaîne de certificats, dans l’ordre, au certificat CA. Vous devez insérer une ligne vide entre chaque certificat du fichier.

Edge fournit une API que vous pouvez utiliser pour créer des keystores et des truststores. Les API réelles sont les mêmes. La différence est que lorsque vous créez un keystore, vous transmettez un fichier JAR contenant le certificat et la clé privée. Lorsque vous créez un Truststore, vous ne transmettez que le certificat sous la forme d'un fichier PEM.

À propos du format des fichiers de certificat et de clé

Les exemples de ce document présentent le certificat et la clé TLS définis comme des fichiers PEM, qui sont conformes au format X.509. Si votre certificat ou votre clé privée n'est pas défini par un fichier PEM, vous pouvez le convertir en fichier PEM à l'aide d'utilitaires tels que openssl.

Toutefois, de nombreux fichiers .crt et .key sont déjà au format PEM. Si ces fichiers sont du texte fichiers et sont inclus dans:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

ou :

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

Les fichiers sont alors compatibles avec le format PEM et vous pouvez les utiliser dans un keystore ou un truststore sans les convertir en fichier PEM.

Si vous disposez d'une chaîne de certificats et que vous souhaitez l'utiliser dans un keystore ou un truststore, vous pouvez combiner tous les certificats dans un seul fichier PEM avec une nouvelle ligne entre chaque certificat. Les certificats doivent être dans l'ordre et le dernier certificat doit être un certificat racine ou un certificat intermédiaire signé par un certificat racine :

-----BEGIN CERTIFICATE-----
(Your Primary TLS certificate)
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
(Intermediate certificate)
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
(Root certificate or intermediate certificate signed by a root certificate)
-----END CERTIFICATE-----

Obtenir des informations sur un keystore existant

Recherchez les keystores existants dans votre environnement à l'aide de la fonction List Keystores and Truststores:

curl -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

Pour les clients cloud, un keystore par défaut est fourni pour les organisations bénéficiant d'un essai sans frais dans les dans les environnements de test et de production. Vous devriez obtenir les résultats suivants pour cet appel pour les deux environnements :

[ "freetrial" ]

Vous pouvez utiliser ce keystore par défaut pour tester vos API et les déployer en production, créent généralement votre propre keystore, avec vos propres certificat et clé, avant de procéder au déploiement en production.

Pour les clients Private Cloud, le tableau renvoyé est vide jusqu'à ce que vous créiez votre premier keystore.

Vérifiez le contenu du keystore à l'aide de l'API Obtenir un keystore ou un truststore. Pour un client cloud, vous devriez voir un seul serveur TLS certificate - le certificat par défaut fourni par Apigee Edge pour les comptes d'essai sans frais.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

La réponse doit apparaître comme suit:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

Vous pouvez également afficher ces informations dans l'interface utilisateur de gestion Edge:

Connectez-vous à l'interface utilisateur de gestion Edge à l'adresse https://enterprise.apigee.com (cloud) ou http://<ms-ip>:9000 (sur site), où <ms-ip> est l'adresse IP du nœud du serveur de gestion.
Dans le menu de l'interface utilisateur de gestion d'Edge, sélectionnez Admin > Certificats TLS.

Obtenir les détails d'un certificat TLS

Vous pouvez utiliser l'API Obtenir les détails du certificat à partir d'un keystore ou d'un truststore pour afficher des informations sur les certificats TLS dans le keystore, telles que la date d'expiration et l'émetteur. Commencez par obtenir le nom du certificat qui vous intéresse. Cet exemple extrait des informations pour le keystore appelé "essai sans frais".

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

Exemple de réponse :

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

Utilisez ensuite la valeur de la propriété "certs" pour obtenir les détails du certificat :

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial/certs/wildcard.apigee.net.crt \
-u email:password

Exemple de réponse :

{
 "certInfo" : [ {
   "expiryDate" : "Wed, 23 Apr 2014 20:50:02 UTC",
   "isValid" : "Yes",
   "issuer" : "CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O=&quot;GoDaddy.com, Inc.&quot;, L=Scottsdale, ST=Arizona, C=US",
   "subject" : CN=*.example.apigee.net, OU=Domain Control Validated",
   "subjectAlternativeNames" : ["*.example.apigee.net","*.example.apigee.net" ],
   "validFrom" : "Tue, 15 Apr 2014 09:17:03 UTC",
   "version" : 3
 } ],
 "name" : "example.apigee.net.crt"
}

Vous pouvez également consulter ces informations dans l'interface utilisateur de gestion Edge :

Connectez-vous à l'interface utilisateur de gestion Edge à l'adresse https://enterprise.apigee.com (cloud) ou http://<ms-ip>:9000 (sur site), où <ms-ip> est l'adresse IP du nœud du serveur de gestion.
Dans le menu de l'interface utilisateur de gestion d'Edge, sélectionnez Admin > Certificats TLS.

Dans l'interface utilisateur d'Edge, vous pouvez spécifier à quel moment Edge indique qu'un certificat va expirer. Par défaut, l'UI met en surbrillance les certificats dont l'expiration est prévue dans les 10 prochains jours.

Créer un keystore

Un keystore est spécifique à un environnement de votre organisation, par exemple l'environnement de test ou de production. Par conséquent, si vous souhaitez tester le keystore dans un environnement de test avant de le déployer dans votre environnement de production, vous devez le créer dans les deux environnements.

La création d'un keystore se fait en deux étapes :

Créez un fichier JAR contenant votre certificat et votre clé privée.
Créez le keystore et importez le fichier JAR.

Créer un fichier JAR contenant votre certificat et votre clé privée

Créez un fichier JAR avec votre clé privée, votre certificat et un fichier manifeste. Le fichier JAR doit contenant les fichiers et répertoires suivants:

/META-INF/descriptor.properties
myCert.pem
myKey.pem

Dans le répertoire contenant votre paire de clés et votre certificat, créez un répertoire appelé /META-INF Ensuite, créez un fichier intitulé descriptor.properties dans /META-INF par les éléments suivants contenus:

certFile={myCertificate}.pem
keyFile={myKey}.pem

Générez le fichier JAR contenant la paire de clés et le certificat:

jar -cf myKeystore.jar myCert.pem myKey.pem

Ajoutez descriptor.properties à votre fichier JAR :

jar -uf myKeystore.jar META-INF/descriptor.properties

Créez le keystore et importez le Fichier JAR

Pour créer un keystore dans un environnement, il vous suffit de spécifier son nom Créer une API Keystore ou Truststore. Le nom ne peut contenir que des caractères alphanumériques:

curl -X POST -H "Content-Type: text/xml" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-d '<KeyStore name="myKeystore"/>' -u email:password

Exemple de réponse :

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystore"
}

Après avoir créé un keystore nommé dans un environnement, vous pouvez importer les fichiers JAR qui contient un certificat et une clé privée à l'aide du service Importez un fichier JAR dans une API Keystore:

curl -X POST -H "Content-Type: multipart/form-data" \
-F file="@myKeystore.jar" -F password={key_pass} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/{myKeystore}/keys?alias={key_alias}" \
-u email:password

où l'option -F spécifie le chemin d'accès au fichier JAR.

Dans cet appel, vous spécifiez deux paramètres de requête :

alias : identifie le le certificat et la clé dans le magasin de clés. Lorsque vous créez un hôte virtuel, vous référencez le certificat et la clé par leur nom d'alias.
password : mot de passe de la clé privée. Omettre ce paramètre si la clé privée n'est associée à aucun mot de passe.

Vérifiez que votre keystore a été importé correctement:

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystore \
-u email:password

Exemple de réponse :

{  
 "certs" : [ "myCertificate" ],
 "keys" : [ "myKey" ],
 "name" : "myKeystore"
}

Créer un Truststore

Les API que vous utilisez pour créer un truststore sont les mêmes que celles utilisées pour créer un keystore. La La seule différence est que vous transmettez le fichier de certificat en tant que fichier PEM au lieu d'un fichier JAR.

Si le certificat fait partie d'une chaîne, vous devez soit importer séparément tous les certificats de la chaîne dans le truststore, soit créer un fichier unique contenant tous les certificats. Incluez une nouvelle ligne entre chaque certificat dans le fichier. Le certificat final est généralement signé par l'émetteur du certificat. Par exemple, dans le truststore, vous importez un certificat client, client_cert_1, et le certificat de l'émetteur du certificat client, ca_cert.

Lors de l'authentification TLS à deux voies, l'authentification du client aboutit lorsque le serveur envoie client_cert_1 au client dans le cadre du processus de handshake TLS.

Vous disposez également d'un deuxième certificat, client_cert_2, signé par le même certificat, ca_cert. Cependant, vous ne devez pas importez client_cert_2 dans Truststore. Le truststore contient toujours client_cert_1 et ca_cert.

Lorsque le serveur transmet client_cert_2 lors du handshake TLS, la requête aboutit. En effet, Edge permet à la validation TLS de réussir lorsque client_cert_2 n'existe pas dans le « Truststore », mais a été signé par le certificat qui existe dans le truststore. Si vous supprimez le certificat de l'autorité de certification, ca_cert, du truststore, la validation TLS échoue.

Créez un truststore vide dans l'environnement à l'aide de Créer un keystore ou un truststore, la même API que celle que vous utilisez pour créer un keystore :

curl -X POST -H "Content-Type: text/xml" -d \
'<KeyStore name="myTruststore"/>' \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

Importez le certificat sous forme de fichier PEM dans le truststore à l'aide du Importez un certificat dans une API Truststore :

curl -X POST -H "Content-Type: multipart/form-data" -F file="@trust.pem" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myTruststore/certs?alias=myTruststore \
-u email:password

où l'option -F spécifie le chemin d'accès au fichier PEM.

Supprimer un keystore ou un truststore

Vous pouvez supprimer un keystore ou un truststore à l'aide de la commande Supprimez une API Keystore ou Truststore:

curl -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystoreName \
-u email:password

Exemple de réponse :

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystoreName"
}

Si vous supprimez un keystore ou un truststore utilisé par un hôte virtuel ou une cible point de terminaison/cible/serveur, tous les appels d'API via l'hôte virtuel ou le point de terminaison/le serveur cible échouera...