<ph type="x-smartling-placeholder"></ph>
Vous consultez la documentation Apigee Edge.
Accédez à la page
Documentation sur Apigee X. En savoir plus
Ce document explique comment créer, modifier et supprimer des keystores et des truststores pour Edge pour le Private Cloud version 4.17.09 et antérieures.
À 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 leur utilisation dans le handshake TLS processus:
- Un keystore contient un certificat TLS et une clé privée permettant d'identifier
lors du handshake TLS.
Avec le protocole 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 vérifie ensuite que certificat délivré par une autorité de certification (CA), 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 protocole TLS à sens unique, un Truststore n'est pas requis 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 de confiance. 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 sur lequel le serveur utilise un certificat certificat. 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 protocole TLS bidirectionnel, le client TLS et le serveur TLS peuvent tous deux utiliser un Truststore. Un magasin de confiance est requis lors de l'exécution d'un protocole TLS bidirectionnel lorsque Edge agit en tant que serveur TLS.
Les certificats peuvent être délivrés par une autorité de certification ou autosignés par clé privée que vous générez. Si vous avez accès à une autorité de certification, suivez les instructions fournies par votre CA permettant de générer des clés et d'émettre des certificats. Si vous n'avez pas accès à une autorité de certification, vous pouvez générer un certificat autosigné en utilisant l'un des nombreux outils sans frais accessibles au public, tels que openssl.
L'implémentation d'un keystore et truststore sur Edge
Sur Edge, un keystore contient un ou plusieurs fichiers JAR, où 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 sous forme de fichier PEM. Edge prend en charge des tailles de clé 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, alors le keystore/Truststore doit contenir tous les certificats dans le 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 utilisez pour créer des keystores et des truststores. Les API proprement dites sont même chose. La différence est que lorsque vous créez un keystore, vous transmettez un fichier JAR contenant un certificat et une 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 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 ne sont pas définis par un fichier PEM, vous pouvez convertir en un fichier PEM à l'aide d'utilitaires tels qu’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 ensuite compatibles avec le format PEM et vous pouvez les utiliser dans un keystore ou 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. La Les certificats doivent être dans l'ordre et le dernier certificat doit être un certificat racine ou 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. Les résultats suivants doivent s'afficher pour cet appel à la fois 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 la commande Obtenez une API Keystore ou 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 adresse IP du nœud du serveur de gestion. - Dans le menu de l'interface utilisateur de gestion Edge, sélectionnez Admin > Certificats TLS.
Obtenir les détails du certificat TLS
Vous pouvez utiliser le Obtenir les détails du certificat à partir d'un keystore ou d'une API Truststore pour afficher les détails des certificats TLS dans le keystore, comme la date d'expiration et l'émetteur. Tout d'abord, obtenez le nom du certificat dans 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"
}
Ensuite, utilisez 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="GoDaddy.com, Inc.", 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 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 adresse IP du nœud du serveur de gestion. - Dans le menu de l'interface utilisateur de gestion Edge, sélectionnez Admin > TLS Certificats
Dans l'interface utilisateur Edge, vous pouvez spécifier combien de temps à l'avance Edge indique qu'un certificat va peut expirer. Par défaut, l'interface utilisateur met en évidence les certificats dont l'expiration est prévue dans les 10 prochaines jours.
Créer un keystore
Un keystore est spécifique à un environnement de votre organisation, par exemple l'environnement de test ou de production environnement. Par conséquent, si vous souhaitez tester le keystore dans un environnement de test avant de déployer dans votre environnement de production, vous devez le créer dans les deux environnements.
La création d'un keystore s'effectue 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<ph type="x-smartling-placeholder">
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 le certificat et la clé par son alias.password: mot de passe de la clé privée. Omettez ce paramètre si la clé privée n'a pas de 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 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 importer tous les certificats de la chaîne séparément
au magasin de confiance, ou créez un fichier unique contenant tous les certificats, insérez une ligne entre
chaque certificat du fichier. Le certificat final est généralement signé par l'émetteur du certificat. Pour
exemple, dans le truststore, vous importez un certificat client client_cert_1, ainsi que le certificat client
certificat de l'émetteur, ca_cert.
Lors de l’authentification TLS bidirectionnelle, l’authentification du client réussit lorsque le serveur envoie
client_cert_1 au client en tant que
du processus de handshake TLS.
Vous pouvez également disposer 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 dans le cadre du handshake TLS, le
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 l'autorité de certification
certificat, ca_cert, de
« Truststore », puis la validation TLS
échoue.
Créez un Truststore vide dans l'environnement en utilisant Créer un Keystore ou 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 de la méthode 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...