Planificación de la estructura de una jerarquía de CA

Como mejor práctica, planifique una jerarquía de autoridades de certificación que se corresponda con la estructura de su organización. Normalmente, puede implementar una de las siguientes estructuras de CA comunes.

Dos niveles: CA raíz y CA subordinada

Utilice esta opción si la carga de trabajo requiere la estructura de CA más sencilla. En este caso de ejemplo, cree una CA raíz de confianza única. A continuación, cree una CA subordinada, por ejemplo una CA intermedia, para emitir certificados de hoja para sus aplicaciones y servicios.

Tres niveles: CA raíz y dos autoridades de certificación subordinadas

Utilice esta opción si la carga de trabajo requiere otro nivel entre la CA raíz y las operaciones de CA de nivel inferior. En este escenario, la CA subordinada intermedia sólo se utiliza para firmar autoridades de certificación subordinadas que emiten certificados de hoja para sus aplicaciones.

Establecimiento del nivel de detalle de la jerarquía de CA

Cuando crea una entidad emisora de certificados en Secrets Manager, puede establecer el parámetro Longitud máxima de vía de acceso para determinar cuántos certificados de CA pueden existir en la cadena de su entidad. Este valor impone el número de certificados de CA que pueden existir en la vía de acceso de certificación de la CA.

Por lo general, puede configurar una CA raíz que no limite el número de autoridades de certificación subordinadas que puede crear en su ruta de certificación. Sin embargo, definir una longitud máxima de ruta en las entidades emisoras de certificados subordinadas es un paso de seguridad importante para evitar entidades emisoras de certificados mal configuradas. En función de la ubicación de una CA subordinada en la jerarquía, especifique una longitud máxima de vía de acceso para que el poder de la entidad emisora de certificados solo esté limitado al nivel de detalle deseado.

La longitud máxima de vía de acceso que defina no incluye los certificados de hoja. En el ejemplo anterior, la CA subordinada de nivel 4 puede emitir certificados de hoja pero no puede tener más certificados de CA en su ruta.

Elección de un periodo de validez para los certificados

El periodo de validez de un certificado X.509 es un campo obligatorio que determina cuánto tiempo se confía en el certificado y cuánto tiempo sigue siendo válido. Cuando planifique la jerarquía de CA, utilice una vida útil anterior a la preferida para los certificados de hoja que desea emitir para las aplicaciones. A continuación, determine el periodo de validez de los certificados de CA.

Un certificado debe tener un periodo de validez inferior o igual al periodo de validez de la CA que lo emitió. Por ejemplo, si crea una CA raíz con un tiempo de vida (TTL) de 10 años, todas las autoridades de certificación intermedias subordinadas deben tener un TTL igual o inferior a 10 años. Asimismo, si una CA intermedia tiene un TTL de 3 años, los certificados de hoja deben tener un TTL igual o inferior a 3 años.

1. Elija un periodo de validez para los certificados de hoja que sea apropiado para el caso de uso.

   Los certificados privados que puede crear con Secrets Manager se consideran certificados de hoja que se pueden emitir para una entidad final, como una aplicación de cliente o servidor. Con Secrets Manager, puede crear certificados con un periodo de validez máximo de tres años o 36 meses. Después de determinar un TTL o periodo de validez para los certificados hoja, establezca el valor utilizando una plantilla de certificado para que el TTL que prefiera se aplique cada vez que se genere un nuevo certificado hoja.

   Cuanto más corto sea el TTL de sus certificados de hoja, más protegido estará contra la exposición inadvertida o el compromiso de su certificado y su clave privada. Un periodo de validez más corto para los certificados significa que reduce la probabilidad de compromiso, pero también requiere rotar el certificado con más frecuencia para asegurarse de que siga siendo válido. Para evitar una interrupción involuntaria, puede planificar la rotación automática de los certificados privados.

2. Elija un periodo de validez para la CA subordinada.

   Como mejor práctica, establezca un periodo de validez para un certificado de CA subordinada que sea significativamente más largo que los periodos de validez de los certificados que emiten. Defina un periodo de validez de una CA padre que sea entre dos y cinco veces el periodo de cualquier certificado de CA hijo o certificado de hoja que emita. Por ejemplo, si tiene una jerarquía de CA de dos niveles y desea emitir certificados de hoja con un TTL de un año, configure la CA emisora subordinada con un TTL de tres años. Siempre puede actualizar certificados de CA subordinadas sin sustituir el certificado de CA raíz.

3. Elija un periodo de validez para la CA raíz.

   Al actualizar un certificado de CA raíz, el cambio afecta a toda la infraestructura de clave pública. Para minimizar el impacto, se recomienda establecer un periodo de validez largo para el certificado de CA raíz. En Secrets Manager, el TTL predeterminado para los certificados raíz es de 10 años.

Elegir un servicio de gestión de claves

Antes de crear una autoridad de certificación en Secrets Manager, debe elegir un servicio de gestión de claves (KMS) para generar las claves públicas y privadas de su CA. Puede elegir el motor de Certificados Privados KMS interno, en este caso las claves públicas y privadas de la CA son creadas en software y gestionadas internamente por el servicio. También puede optar por gestionar sus claves en un módulo de seguridad de hardware (HSM) externo. Secrets Manager admite IBM Cloud Hyper Protect Crypto Services (HPCS) para gestionar las claves de CA. Puede configurar una CA para que utilice claves existentes en un almacén de claves privadas HPCS, o permitir que Secrets Manager cree nuevas claves para la CA.

El motor de certificados privados Secrets Manager utiliza la API PKCS#11 para comunicarse con HPCS. La autenticación y autorización se realiza mediante una clave API IAM que se gestiona mediante un Secrets Manager secreto de credenciales IAM. Las operaciones de firma criptográfica se realizan en HPCS sin que el material de la clave privada de la CA salga nunca del criptodispositivo.

Nota: Secrets Manager no controla los costes ni los límites de tarifa asociados a la creación de certificados CA con claves en HPCS.

Elección de un algoritmo para generar claves

Antes de crear una entidad emisora de certificados en Secrets Manager, debe elegir un algoritmo de claves para generar las claves públicas y privadas de la CA. El par de claves públicas y privadas se utiliza para autenticar una conexión SSL/TLS. Si no tiene claro por dónde empezar, utilice la siguiente sugerencia orientativa para seleccionar un algoritmo de claves.

1. Elija una familia de algoritmos.

   El algoritmo de claves que seleccione determinará el algoritmo de cifrado y el tamaño de clave que se deben utilizar para generar claves y firmar certificados. Como práctica recomendada, utilice la misma familia de algoritmos para todos los certificados que pertenecen a una cadena de certificados. Secrets Manager da soporte a las siguientes familias de algoritmos.

   Familias de algoritmos y tamaños de clave admitidos

   Familia de algoritmos	Descripción	Tamaños de claves soportados
   RSA	RSA se utiliza mucho y es compatible con la mayoría de los navegadores y servidores; es el estándar del sector para la criptografía de claves públicas.	2048 bits 4096 bits
   Curva elíptica (EC)	Genera claves más fuertes y certificados más pequeños. Por ejemplo, una clave EC de 256 bits equivale en fuerza de cifrado a una clave RSA de 3072 bits.	224 bits 256 bits 384 bits 521 bits

2. Elija un tamaño de clave.

   El tamaño o la longitud de la clave que seleccione determinará la fuerza de cifrado. Cuanto mayor sea el tamaño de la clave para una familia de algoritmos, más difícil será provocar una brecha. Tenga en cuenta que las longitudes de clave más largas dan como resultado más datos para almacenar y transmitir, lo que puede afectar al rendimiento de su certificado. Como práctica recomendada, elija un tamaño de clave que sea adecuado para el periodo de validez o TTL del certificado.

   Para los certificados de vida más larga, se recomienda utilizar longitudes de clave más largas para proporcionar una mayor protección de cifrado.

Leer lista de revocación de certificados

Con este punto final, puede recuperar la CRL actual en formato sin procesar DER-encoded. Si se añade /pem al endpoint, la CRL se devuelve en formato PEM.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/crl(/pem)

Response 200 OK
<binary DER-encoded CRL>

Para validar que los certificados de CA de hoja o intermedios no se revocan del contexto de un certificado de hoja, puede configurar la CA con la propiedad "crl_distribution_points_encoded": true. Esta configuración codifica el URL que se utiliza para descargar la CRL de la CA emisora en la propiedad como X509v3 CRL Distribution Points en cada certificado de CA hoja o intermedia. A continuación, el validador de CA puede comprobar si se han revocado los certificados de CA de hoja o intermedios.

Leer certificado de CA

Con este punto final, puede recuperar el certificado de CA en bruto DER-encoded form. Si se añade /pem al endpoint, el certificado CA se devuelve en formato PEM.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca(/pem)

Response 200 OK
<binary DER-encoded certificate >

Leer cadena de certificados de CA

Con este endpoint puede recuperar la cadena de certificados de la CA, que incluye la CA en formato PEM. Este punto final está desnudo. No devuelve una estructura de datos de Vault estándar y la CLI de Vault no puede leerla.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca_chain

Response 200 OK
<PEM-encoded certificate chain>

Para verificar que la cadena CA es del contexto de un certificado hoja, puede configurar sus Autoridades de Certificación en Secrets Manager con la propiedad "issuing_certificates_urls_encoded": true. En cada certificado de CA de hoja o intermedio, esta configuración codifica el URL que se utiliza para descargar el certificado de CA emisora en la propiedad Authority Information Access/CA Issuers. A continuación, el validador de CA puede validar cada certificado de CA.