Acerca de los certificados de Azure Key Vault

La compatibilidad con certificados de Azure Key Vault proporciona la administración de sus certificados X.509 y los comportamientos siguientes:

  • Permite que el propietario de un certificado cree un certificado a través de un proceso de creación de almacén de claves o a través de la importación de un certificado existente. Los certificados importados incluyen los certificados autofirmados y los certificados generados desde una entidad de certificación (CA).

  • Permite que el propietario de un certificado de Key Vault implemente un almacenamiento seguro y la administración de certificados X.509 sin interactuar con material de clave privada.

  • Permite que el propietario de un certificado cree una directiva que indique a Key Vault cómo administrar el ciclo de vida de un certificado.

  • Permite al propietario del certificado proporcionar información de contacto para las notificaciones sobre los eventos de ciclo de vida de expiración y renovación.

  • Admite la renovación automática con emisores seleccionados: proveedores de certificados X.509 y CA asociados con Key Vault.

    Nota:

    También se permiten proveedores y autoridades no asociados, pero no admiten la renovación automática.

Para más información sobre la creación de certificados, consulte Métodos de creación de certificados.

Composición de un certificado

Cuando se crea un certificado de Key Vault, se crean también una clave direccionable y un secreto con el mismo nombre. La clave de Key Vault permite operaciones de clave y el secreto de Key Vault permite recuperar el valor del certificado como secreto. Un certificado de Key Vault también contiene metadatos del certificado X.509 público.

El identificador y la versión de los certificados son similares a los de las claves y los secretos. Una versión específica de una clave direccionable y el secreto creados con la versión del certificado de Key Vault está disponible en la respuesta del certificado de Key Vault.

Diagrama en el que se muestra el rol de los certificados en un almacén de claves.

Clave exportable o no exportable

Cuando se crea un certificado de Key Vault, este se puede recuperar desde el secreto direccionable con la clave privada en formato PFX o PEM. La directiva que se utiliza para crear el certificado debe indicar que la clave es exportable. Si la directiva indica que la clave no es exportable, la clave privada no forma parte del valor cuando se recupera como un secreto.

La clave direccionable se vuelve más pertinente con los certificados de Key Vault no exportables. Las operaciones de la clave de Key Vault direccionable se asignan desde el campo keyusage de la directiva del certificado de Key Vault que se usa para crear el certificado de Key Vault.

En la tabla siguiente se enumeran los tipos de clave admitidos.

Tipo de clave Acerca de Seguridad
RSA Clave RSA protegida por software FIPS 140-2 nivel 1
RSA-HSM Clave RSA protegida con HSM (solo SKU Premium) HSM validados con FIPS 140-2 nivel 2
EC Clave de curva elíptica protegida con software FIPS 140-2 nivel 1
EC-HSM Clave de curva elíptica protegida con HSM (solo SKU Premium) HSM validados con FIPS 140-2 nivel 2
oct Clave de octeto protegida con software FIPS 140-2 nivel 1

Las claves exportables solo se permiten con RSA y EC. Las claves HSM no son exportables. Para obtener más información sobre los tipos de clave, consulte Creación de certificados.

Etiquetas y atributos de certificado

Además de los metadatos del certificado, una clave direccionable y un secreto direccionable, un certificado de Key Vault contiene atributos y etiquetas.

Atributos

Los atributos del certificado se reflejan en los atributos de la clave y el secreto direccionables que se crean cuando se crea el certificado de Key Vault.

Un certificado de Key Vault tiene el siguiente atributo:

  • enabled: este atributo booleano es opcional. El valor predeterminado es true. Se puede especificar para indicar si se pueden recuperar los datos del certificado como un secreto o es operativo como una clave.

    Este atributo también se utiliza con nbf y exp cuando se produce una operación entre nbf y exp, pero solo si enabled está establecido en true. Las operaciones fuera de la franja entre nbf y exp se deniegan automáticamente.

Una respuesta incluye estos atributos de solo lectura adicionales:

  • created: IntDate indica cuándo se creó esta versión del certificado.
  • updated: IntDate indica cuándo se modificó esta versión del certificado.
  • exp: IntDate contiene el valor de la fecha de expiración del certificado X.509.
  • nbf: IntDate contiene el valor de la fecha "no antes de" del certificado X.509.

Nota:

Si un certificado de Key Vault expira, la clave y el secreto direccionables dejan de funcionar.

Etiquetas

Las etiquetas de los certificados son un diccionario especificado por el cliente de pares clave y valor, similar a las etiquetas de las claves y los secretos.

Nota:

Un autor de llamada puede leer las etiquetas si tiene el permiso list o get para ese tipo de objeto (claves, secretos o certificados).

Directiva de certificados

Una directiva de certificados contiene información sobre cómo crear y administrar el ciclo de vida de un certificado de Key Vault. Cuando se importa un certificado con clave privada en Key Vault, el servicio de Key Vault crea una directiva predeterminada mediante la lectura del certificado X.509.

Cuando se crea un certificado de Key Vault desde el principio, debe proporcionarse una directiva. La directiva especifica cómo crear esta versión de certificado de Key Vault o la próxima versión de certificado de Key Vault. Tras establecerse una directiva, no se requiere en sucesivas operaciones create para futuras versiones. Solo hay una instancia de una directiva para todas las versiones de un certificado de Key Vault.

En un nivel general, una directiva de certificado contiene la siguiente información:

  • Propiedades del certificado X.509, entre las que se incluyen el nombre del firmante, los nombres alternativos del firmante y otras propiedades que se usan para crear una solicitud de certificado X.509.

  • Propiedades de la clave, entre las que se incluyen el tipo de clave, la longitud y los campos de exportable y ReuseKeyOnRenewal. Estos campos indican a Key Vault cómo generar una clave.

    Estos son los tipos de clave admitidos: RSA, RSA-HSM, EC, EC-HSM y oct.

  • Propiedades del secreto, como el tipo de contenido de un secreto direccionable para generar el valor secreto, para recuperar un certificado como un secreto.

  • Acciones de vigencia para el certificado de Key Vault. Cada acción de vigencia contiene:

    • Desencadenador: se especifica como días antes de la expiración o como un porcentaje del intervalo de vigencia.
    • Acción: emailContacts o autoRenew.
  • Parámetros sobre el emisor de certificado que se utiliza para emitir certificados X.509.

  • Atributos asociados a la directiva.

Para obtener más información, consulta Set-AzKeyVaultCertificatePolicy.

Correspondencia entre el uso de X.509 y las operaciones clave

La tabla siguiente representa la correspondencia entre las directivas de uso de claves X.509 y las operaciones de clave efectivas de una clave creada como parte de la creación de certificados de Key Vault.

Marcas de uso de claves X.509 Operaciones con claves de Key Vault Comportamiento predeterminado
DataEncipherment encrypt, decrypt No aplicable
DecipherOnly decrypt No aplicable
DigitalSignature sign, verify Valor predeterminado de Key Vault sin una especificación de uso en el momento de creación del certificado
EncipherOnly encrypt No aplicable
KeyCertSign sign, verify No aplicable
KeyEncipherment wrapKey, unwrapKey Valor predeterminado de Key Vault sin una especificación de uso en el momento de creación del certificado
NonRepudiation sign, verify No aplicable
crlsign sign, verify No aplicable

Emisor de certificado

Un objeto de certificado de Key Vault contiene una configuración que se usa para comunicarse con un proveedor de emisor de certificado seleccionado para solicitar certificados X.509.

Key Vault está asociado con los proveedores de emisión de certificado siguientes para certificados TLS/SSL.

Nombre del proveedor Ubicaciones
DigiCert Compatible con todas las ubicaciones del servicio de Key Vault en la nube pública y Azure Government
GlobalSign Compatible con todas las ubicaciones del servicio de Key Vault en la nube pública y Azure Government

Para poder crear un emisor de certificado en un almacén de claves, un administrador debe seguir estos pasos de requisitos previos:

  1. Incorporar la organización con al menos un proveedor de entidad de certificación.

  2. Crear las credenciales del solicitante para que Key Vault inscriba (y renueve) certificados TLS/SSL. Este paso proporciona la configuración para crear un objeto de emisor del proveedor en el almacén de claves.

Para obtener más información acerca de cómo crear objetos de emisor desde el portal de certificados, consulte el blog del equipo de Key Vault.

Key Vault permite la creación de varios objetos de emisor con diferentes configuraciones del proveedor de emisor. Tras crear un objeto de emisor, se puede hacer referencia a su nombre en una o varias directivas de certificado. Al hacer referencia al objeto de emisor se indica a Key Vault que utilice la configuración de acuerdo con lo especificado en el objeto de emisor al solicitar el certificado X.509 al proveedor de la entidad de certificación durante la creación y la renovación de certificados.

Los objetos de emisor se crean en el almacén. Solo se pueden usar con certificados de Key Vault en el mismo almacén.

Nota

Los certificados de confianza pública se envían a los registros de entidades de certificación (CA) y de transparencia de certificados (CT) fuera de los límites de Azure durante la inscripción. Las directivas de RGPD de esas entidades los cubren.

Contactos de certificados

Los contactos de certificados contienen información de contacto para enviar notificaciones desencadenadas por los eventos de vigencia del certificado. Todos los certificados del almacén de claves comparten la información de contacto.

Se envía una notificación a todos los contactos especificados para un evento de cualquier certificado del almacén de claves. Para obtener más información sobre cómo establecer un contacto de certificado, consulte Renovación de los certificados de Azure Key Vault.

Control de acceso a certificados

Key Vault administra el control de acceso para los certificados. El almacén de claves que contiene esos certificados proporciona el control de acceso. La directiva de control de acceso para los certificados es distinta de las directivas de control de acceso para las claves y los secretos en el mismo almacén de claves.

Los usuarios pueden crear uno o varios almacenes para almacenar los certificados, para mantener la segmentación adecuada del escenario y la administración de los certificados. Para obtener más información, consulte Control de acceso a los certificados.

Casos de uso de certificados

Comunicación y autenticación seguras

Los certificados TLS pueden ayudar a cifrar las comunicaciones a través de Internet y a establecer la identidad de los sitios web. Este cifrado hace que el punto de entrada y el modo de comunicación sean más seguros. Además, un certificado encadenado firmado por una entidad de certificación pública puede ayudar a comprobar que las entidades que tienen los certificados son legítimas.

Por ejemplo, estos son algunos casos de uso del uso de certificados para proteger la comunicación y habilitar la autenticación:

  • Sitios web de intranet/Internet: proteja el acceso al sitio de su intranet y asegure la transferencia de datos cifrados a través de Internet mediante certificados TLS.
  • Dispositivos IoT y de red: proteja los dispositivos mediante certificados para la autenticación y la comunicación.
  • Nube o multinube: proteja las aplicaciones basadas en la nube localmente, entre nubes o en el inquilino del proveedor de nube.

Firma de código

Un certificado puede ayudar a proteger el código o script de software para garantizar que el autor pueda compartir el software a través de Internet sin interferencias por parte de entidades malintencionadas. Una vez que el autor firma el código mediante un certificado y aprovechando la tecnología de firma de código, el software se marca con un sello de autenticación que muestra el autor y su sitio web. El certificado usado en la firma de código ayuda a validar la autenticidad del software, lo que refuerza la seguridad de un extremo a otro.

Pasos siguientes