Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Crea almacenes de claves y almacenes de confianza para la versión 4.17.09 y versiones anteriores de la nube privada

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

En este documento, se describe cómo crear, modificar y borrar almacenes de claves y almacenes de confianza para Edge para la versión 4.17.09 y versiones anteriores de la Nube privada.

Acerca de los almacenes de claves y los almacenes de confianza

Los almacenes de claves y los almacenes de confianza definen repositorios de certificados de seguridad que se usan para la encriptación TLS. La principal diferencia entre ambos es dónde se usan en el proceso de protocolo de enlace TLS:

Un almacén de claves contiene un certificado TLS y una clave privada que se usan para identificar la entidad durante el protocolo de enlace TLS.

En la TLS unidireccional, cuando un cliente se conecta al extremo TLS en el servidor, el almacén de claves del servidor presenta el certificado del servidor (certificado público) al cliente. Luego, el cliente valida ese certificado con una autoridad certificadora (CA), como Symantec o VeriSign.

En la TLS bidireccional, tanto el cliente como el servidor mantienen un almacén de claves con su propio certificado y clave privada que se usan para la autenticación mutua.
Un truststore contiene certificados que se usan para verificar los certificados recibidos como parte del protocolo de enlace TLS.

En la TLS unidireccional, no se requiere un almacén de confianza si el certificado está firmado por una CA válida. Si el certificado que recibe un cliente TLS está firmado por una CA válida, el cliente realiza una solicitud a la CA para autenticar el certificado. Por lo general, un cliente TLS usa un almacén de certificados de confianza para validar los certificados autofirmados que recibe del servidor TLS o los certificados que no están firmados por una CA de confianza. En este caso, el cliente completa su almacén de certificados de confianza con los certificados en los que confía. Luego, cuando el cliente recibe un certificado de servidor, el certificado entrante se valida con los certificados de su almacén de certificados de confianza.

Por ejemplo, un cliente TLS se conecta a un servidor TLS en el que el servidor usa un certificado autofirmado. Debido a que es un certificado autofirmado, el cliente no puede validarlo con una CA. En cambio, el cliente precarga el certificado autofirmado del servidor en su almacén de confianza. Luego, cuando el cliente intenta conectarse al servidor, usa su almacén de certificados de confianza para validar el certificado que recibió del servidor.

Para la TLS bidireccional, tanto el cliente TLS como el servidor TLS pueden usar un almacén de confianza. Se requiere un almacén de certificados de confianza cuando se realiza una TLS bidireccional cuando Edge actúa como el servidor TLS.

Una autoridad certificadora (CA) puede emitir certificados, o bien puedes autofirmarlos con la clave privada que generes. Si tienes acceso a una CA, sigue las instrucciones que te proporciona tu para generar claves y emitir certificados. Si no tienes acceso a una CA, puedes generar un certificado autofirmado con una de las muchas herramientas gratuitas disponibles públicamente, como openssl.

Implementa un almacén de claves y un almacén de certificados de confianza en Edge

En Edge, un almacén de claves contiene uno o más archivos JAR, en los que el archivo JAR contiene lo siguiente:

Certificado TLS como archivo PEM: un certificado firmado por una autoridad certificadora (CA), una cadena de certificados en la que el último certificado está firmado por una CA o un certificado autofirmado cert.
Clave privada como archivo PEM. Edge admite tamaños de clave de hasta 2048 bits. Una frase de contraseña es opcional.

Un almacén de certificados de confianza es similar a un almacén de claves, excepto que solo contiene certificados como un archivo PEM, pero no claves privadas.

Si el certificado es parte de una cadena, el almacén de claves o el almacén de certificados de confianza debe contener todos los certificados de la cadena, ya sea como archivos PEM individuales o como un solo archivo. Si usas un solo archivo, los certificados deben estar en orden, en el que el primer certificado del archivo es el certificado que se usa para TLS, seguido de la cadena de certificados, en orden, al certificado de la AC. Debes insertar una línea vacía entre cada certificado del archivo.

Edge proporciona una API que usas para crear almacenes de claves y almacenes de confianza. Las APIs reales son las mismas. La diferencia es que, cuando creas un almacén de claves, pasas un archivo JAR que contiene el certificado y la clave privada. Cuando creas un almacén de confianza, solo pasas el certificado como un archivo PEM.

Acerca del formato de los archivos de certificado y clave

En los ejemplos de este documento, se muestran el certificado y la clave TLS definidos como archivos PEM, que cumplen con el formato X.509. Si tu certificado o clave privada no están definidos por un archivo PEM, puedes convertir los en un archivo PEM con utilidades como openssl.

Sin embargo, muchos archivos .crt y .key ya están en formato PEM. Si estos archivos son archivos de texto y están encerrados en lo siguiente:

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

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

Entonces, los archivos son compatibles con el formato PEM y puedes usarlos en un almacén de claves o de confianza sin convertirlos en un archivo PEM.

Si tienes una cadena de certificados y quieres usarla en un almacén de claves o almacén de certificados de confianza, entonces puedes combinar todos los certificados en un solo archivo PEM con una línea nueva entre cada certificado. Los certificados deben estar en orden, y el último debe ser un certificado raíz o un certificado intermedio firmado por un certificado raíz:

-----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-----

Obtén detalles sobre un almacén de claves existente

Verifica tu entorno para ver si hay almacenes de claves existentes con la API de lista de almacenes de claves y de confianza:

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

Para los clientes de la nube, se proporciona un almacén de claves predeterminado para las organizaciones de prueba gratuita en los entornos de prueba y producción. Deberías ver los siguientes resultados para esta llamada en ambos entornos:

[ "freetrial" ]

Puedes usar este almacén de claves predeterminado para probar tus APIs y enviarlas a producción, pero por lo general, creas tu propio almacén de claves, con tu propio certificado y clave, antes de implementar en producción.

Para los clientes de la Nube privada, el array que se muestra está vacío hasta que creas tu primer almacén de claves.

Verifica el contenido del almacén de claves con la API de obtención de un almacén de claves o de confianza. Para un cliente de la nube, deberías ver un solo certificado TLS del servidor , el certificado predeterminado que Apigee Edge proporciona para las cuentas de prueba gratuita.

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

La respuesta debería aparecer de la siguiente manera:

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

También puedes ver esta información en la IU de administración de Edge:

Accede a la IU de administración de Edge en https://enterprise.apigee.com (nube) o http://<ms-ip>:9000 (local), donde <ms-ip> es la dirección IP del nodo del servidor de administración.
En el menú de la IU de administración de Edge, selecciona Admin > TLS Certificates.

Obtén detalles del certificado TLS

Puedes usar la API de obtención de detalles de certificados de un almacén de claves o de confianza para ver detalles sobre los certificados TLS en el almacén de claves, como la fecha de vencimiento y el emisor. Primero, obtén el nombre del certificado en el que te interesa. En este ejemplo, se recupera información para el almacén de claves llamado "freetrial".

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

Respuesta de muestra:

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

Luego, usa el valor de la propiedad certs para obtener los detalles del certificado:

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

Respuesta de muestra:

{
 "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"
}

También puedes ver esta información en la IU de administración de Edge:

Accede a la IU de administración de Edge en https://enterprise.apigee.com (nube) o http://<ms-ip>:9000 (local), donde <ms-ip> es la dirección IP del nodo del servidor de administración.
En el menú de la IU de administración de Edge, selecciona Admin > TLS Certificates.

En la IU de Edge, puedes especificar con cuánta anticipación Edge indica que un certificado vencerá. De forma predeterminada, la IU destaca los certificados programados para vencer en los próximos 10 días.

Crea un almacén de claves

Un almacén de claves es específico de un entorno en tu organización, por ejemplo, el entorno de prueba o producción. Por lo tanto, si quieres probar el almacén de claves en un entorno de prueba antes de implementarlo en tu entorno de producción, debes crearlo en ambos entornos.

La creación de un almacén de claves es un proceso de dos pasos:

Crea un archivo JAR que contenga tu certificado y clave privada.
Crea el almacén de claves y sube el archivo JAR.

Crea un archivo JAR que contenga tu certificado y clave privada

Crea un archivo JAR con tu clave privada, certificado y manifiesto. El archivo JAR debe contener los siguientes archivos y directorios:

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

En el directorio que contiene tu par de claves y certificado, crea un directorio llamado /META-INF. Luego, crea un archivo llamado descriptor.properties en /META-INF con el siguiente contenido:

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

Genera el archivo JAR que contiene tu par de claves y certificado:

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

Agrega descriptor.properties a tu archivo JAR:

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

Crea el almacén de claves y sube el archivo JAR

Para crear un almacén de claves en un entorno, solo debes especificar el nombre del almacén de claves en la API de creación de un almacén de claves o de confianza. El nombre solo puede contener caracteres alfanuméricos:

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

Respuesta de muestra:

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

Después de crear un almacén de claves con nombre en un entorno, puedes subir tus archivos JAR que contienen un certificado y una clave privada con la API de carga de un archivo JAR a un almacén de claves:

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

donde la opción -F especifica la ruta de acceso al archivo JAR.

En esta llamada, especificas dos parámetros de consulta:

alias - Identifica el certificado y la clave en el almacén de claves. Cuando creas un host virtual, haces referencia al certificado y la clave por su nombre de alias.
`password`: Es la contraseña de la clave privada. Omite este parámetro si la clave privada no tiene contraseña.

Verifica que tu almacén de claves se haya subido correctamente:

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

Respuesta de muestra:

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

Crea un almacén de certificados de confianza

Las APIs que usas para crear un almacén de certificados de confianza son las mismas que se usan para crear un almacén de claves. La única diferencia es que pasas el archivo de certificado como un archivo PEM en lugar de un archivo JAR.

Si el certificado es parte de una cadena, debes subir todos los certificados de la cadena por separado al almacén de certificados de confianza o crear un solo archivo que contenga todos los certificados. Incluye una línea nueva entre cada certificado del archivo. Por lo general, el certificado final está firmado por el emisor del certificado. Por ejemplo, en el almacén de certificados de confianza, subes un certificado de cliente, client_cert_1, y el certificado del emisor del certificado de cliente, ca_cert.

Durante la autenticación TLS bidireccional, la autenticación del cliente se realiza correctamente cuando el servidor envía client_cert_1 al cliente como parte del proceso de protocolo de enlace TLS.

Como alternativa, tienes un segundo certificado, client_cert_2, firmado por el mismo certificado, ca_cert. Sin embargo, no subes client_cert_2 al almacén de confianza. El almacén de confianza aún contiene client_cert_1 y ca_cert.

Cuando el servidor pasa client_cert_2 como parte del protocolo de enlace TLS, la solicitud se realiza correctamente. Esto se debe a que Edge permite que la verificación de TLS se realice correctamente cuando client_cert_2 no existe en el almacén de confianza, pero fue firmado por un certificado que existe en el almacén de confianza. Si quitas el certificado de la AC , ca_cert, del almacén de certificados de confianza, falla la verificación de TLS.

Crea un almacén de certificados de confianza vacío en el entorno con la API de creación de un almacén de claves o de certificados de confianza, la misma API que usas para crear un almacén de claves:

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

Sube el certificado como un archivo PEM al almacén de certificados de confianza con la API de carga de un certificado a un almacén de certificados de confianza:

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

donde la -F opción especifica la ruta de acceso al archivo PEM.

Borra un almacén de claves o de confianza

Puedes borrar un almacén de claves o un almacén de certificados de confianza con la API de borrado de un almacén de claves o de confianza:

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

Respuesta de muestra:

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

Si borras un almacén de claves o un almacén de certificados de confianza que usa un host virtual o un extremo de destino/destino/servidor, fallarán todas las llamadas a la API a través del host virtual o del extremo de destino/destino/servidor.