Añadir políticas de emisión de certificados

Para añadir políticas de emisión de certificados en el servicio de AC, debes definir reglas y restricciones que rijan los tipos de certificados emitidos por una autoridad de certificación (AC). Para obtener más información sobre las políticas de emisión de certificados, consulte el artículo Acerca de las políticas de emisión de certificados.

Una política de emisión de certificados le permite especificar el sujeto y los nombres alternativos del sujeto (SANs) que se pueden incluir en los certificados emitidos. Puedes especificar la política de emisión de certificados al crear un grupo de AC o actualizar un grupo de AC para añadir una política de emisión.

Para obtener más información, consulta el artículo Descripción general de las plantillas y las políticas de emisión.

Antes de empezar

• Asegúrate de tener el rol de gestión operativa del servicio de AC (roles/privateca.caManager) o el rol de administrador del servicio de AC (roles/privateca.admin) de IAM. Para obtener información sobre cómo conceder un rol de gestión de identidades y accesos a una entidad, consulta el artículo Conceder un solo rol.

• Crea un grupo de autoridades de certificación.

Puedes añadir una política de emisión de certificados a un grupo de AC al crear un grupo de AC o al actualizar uno que ya tengas.

Puedes usar uno de los siguientes métodos:

Restricciones admitidas

El Servicio de Autoridades de Certificación admite las siguientes restricciones de la política de emisión. Puedes combinar las siguientes restricciones según sea necesario para crear una política de emisión de certificados personalizada.

Restringir o forzar los valores X.509 permitidos

Un grupo de CAs puede restringir los valores X.509 permitidos en las solicitudes de certificados configurando el campo passthrough_extensions.

Un grupo de CAs también puede especificar explícitamente los valores X.509 que se van a añadir a todos los certificados emitidos, sobrescribiendo los valores solicitados, mediante el campo baseline_values.

Los valores de baseline_values de un grupo de CAs permiten especificar las siguientes propiedades:

• Uso de claves
• Opciones de CA
• Servidores OCSP de AIA
• Extensiones X.509 adicionales

También puedes usar estas opciones juntas.

Si actualiza alguna parte del campo baseline_values, la actualización sustituirá a todo el conjunto de valores del campo baseline_values.

• Ejemplo: Restringe una CA para que solo emita certificados de entidad final con valores X.509 para TLS mutuo (mTLS).

  policy.yaml

  baselineValues:
    caOptions:
      isCa: false
    keyUsage:
      baseKeyUsage:
        digitalSignature: true
        keyEncipherment: true
      extendedKeyUsage:
         clientAuth: true
         serverAuth: true
  

• Ejemplo: Restringe una AC para que solo emita certificados de firma de código de entidad final con una URL OCSP de AIA de referencia.

  policy.yaml

  baselineValues:
    caOptions:
      isCa: false
    keyUsage:
      baseKeyUsage:
        digitalSignature: true
      extendedKeyUsage:
        codeSigning: true
    aiaOcspServers:
      -   "http://foo.bar/revocation"
    additionalExtensions:
    -   objectId:
          objectIdPath:
            -   1
            -   2
            -   3
        critical: false
        value: "base64 encoded extension value"
  

Para obtener más información sobre el perfil de certificado de mTLS de entidad final, consulta mTLS de entidad final.

Restringir los campos de identidad permitidos

Para restringir la identidad de los certificados emitidos a través de un pool de CAs, puedes añadir una expresión de [Common Expression Language (CEL)][4]{: .external} al campo identity_constraints de la política de emisión. Las expresiones CEL permiten restricciones arbitrarias sobre el nombre de dominio del asunto (incluido el nombre común) y los SANs de un certificado.

Para obtener más información sobre cómo usar una expresión CEL para restringir el asunto y los SANs, consulta Usar CEL.

• Ejemplo: permite que la AC emita solo certificados que coincidan con un asunto especificado.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: true
    allowSubjectAltNamesPassthrough: false
    celExpression:
      expression: 'subject.organization == "Example LLC" && subject.country_code in ["US", "UK"]'
  

  El campo celExpression es opcional. Usa una expresión de lenguaje de expresión común (CEL) para validar el asunto y el SAN de X.509 resueltos antes de que se firme un certificado. Para obtener más información sobre cómo usar expresiones CEL, consulta Usar CEL.

• Ejemplo: Permite solo los SANs que tengan nombres DNS como us.google.org o que terminen en .google.com.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == DNS && (san.value == "us.google.org" || san.value.endsWith(".google.com")) )'
  

• Ejemplo: Permite solo los SANs que tengan URIs https://google.com/webhp o que empiecen por spiffe://example-trust-domain-1/ns/namespace1/sa/.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == URI && (san.value == "https://google.com/webhp" || san.value.startsWith("spiffe://example-trust-domain-1/ns/namespace1/sa/")) )'
  

• Ejemplo: Permite solo los SANs que tengan direcciones de correo example@google.com o que terminen en @google.org.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == EMAIL && (san.value == "example@google.com" || san.value.endsWith("@google.org")) )'
  

• Ejemplo: Permite solo SANs personalizados que tengan un OID específico y un valor personalizado.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == CUSTOM && san.oid == [1, 2, 3, 4] && san.value == "custom-data" )'
  

Restringir la duración de la fecha anterior de los certificados emitidos

Para definir un valor de not_before_time anterior a la fecha actual en los certificados emitidos, usa el campo backdate_duration. Cuando se configura, los certificados de este grupo de AC tienen un valor not_before_time igual a la hora de emisión menos la duración especificada. El valor de not_after_time se ajusta para mantener el tiempo de validez del certificado solicitado. El valor de backdate_duration debe ser inferior o igual a 48 horas.

Ejemplo

Para retrasar los certificados una hora, usa el siguiente archivo policy.yaml:

backdateDuration: 3600s

Restringir la duración máxima de los certificados emitidos

Para restringir la validez de los certificados emitidos, usa el campo maximum_lifetime. Si la duración solicitada de un certificado es superior a la duración máxima, se trunca explícitamente.

Ejemplo

Para permitir una duración máxima de 30 días, usa el siguiente archivo policy.yaml:

maximumLifetime: 2592000s

Restringir los modos de emisión de certificados permitidos

Puedes solicitar un certificado mediante una solicitud de firma de certificado (CSR) o una descripción insertada de los valores solicitados. Algunas organizaciones prefieren añadir limitaciones a la opción que se puede usar, ya que este último método no requiere una prueba de posesión de la clave privada asociada. Puedes definir estas limitaciones mediante el campo allowedIssuanceModes.

Para obtener más información sobre cómo especificar las formas en las que se pueden solicitar certificados de un grupo de CAs, consulta IssuanceModes.

Para obtener más información sobre cómo solicitar certificados, consulta el artículo Crear una solicitud de certificado.

• Ejemplo: permitir solo la emisión de CSR.

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

Restringir los algoritmos de clave pública de la solicitud de certificado

Para restringir la longitud mínima de la clave y los algoritmos de clave pública que pueden usar los certificados, puede usar el campo allowedKeyTypes del archivo YAML de la política de emisión de certificados. Si se especifica este campo, la clave pública de la solicitud de certificado debe coincidir con uno de los tipos de clave que se indican en el archivo YAML. Si no se especifica este campo, puedes usar cualquier clave, excepto las claves RSA cuyo tamaño del módulo sea inferior a 2048 bits. Si quieres usar una clave RSA con un tamaño de módulo inferior a 2048 bits, debes permitirlo explícitamente mediante la política de emisión de certificados.

Ejemplo: Permite claves RSA con un tamaño de módulo entre 3072 y 4096 bits (ambos incluidos) o claves del algoritmo de firma digital de curva elíptica (ECDSA) en la curva P-256 del NIST.

allowedKeyTypes:
-   rsa:
  minModulusSize: 3072
  maxModulusSize: 4096
-   ellipticCurve:
      signatureAlgorithm: ECDSA_P256

Puedes elegir uno de los siguientes algoritmos de firma de curva elíptica:

• EC_SIGNATURE_ALGORITHM_UNSPECIFIED: se puede usar cualquier algoritmo de firma.
• ECDSA_P256: firma digital de curva elíptica sobre la curva P-256 de NIST.
• ECDSA_P384: firma digital de curva elíptica sobre la curva P-384 del NIST.
• EDDSA_25519: algoritmo de firma digital de curva de Edwards sobre la curva 25519, tal como se describe en RFC 8410.

Siguientes pasos

• Más información sobre los perfiles de certificados
• Más información sobre cómo solicitar certificados
• Consulta cómo configurar políticas de gestión de identidades y accesos.
• Consulta cómo usar el lenguaje de expresión común (CEL).
• Consulta cómo gestionar varios controles de políticas.