Agrega una política de emisión de certificados a un grupo de AC

En esta página, se describe cómo agregar una política de emisión de certificados a un grupo de autoridad certificadora (AC).

Una política de emisión de certificados te permite especificar el asunto y los nombres alternativos del asunto (SAN) que se pueden incluir en los certificados emitidos. Puedes especificar la política de emisión de certificados cuando creas un grupo de AC o puedes actualizar un grupo de AC existente para agregar una política de emisión.

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

Antes de comenzar

• Asegúrate de tener el rol de IAM de Administrador de operaciones del servicio de AC (roles/privateca.caManager) o de Administrador del servicio de AC (roles/privateca.admin). Para obtener información sobre cómo otorgar un IAM a un principal, consulta Otorga un solo rol.

• Crea un grupo de CA.

Agrega un archivo de política de emisión de certificados

Para agregar una política de emisión de certificados a un grupo de AC existente, haz lo siguiente:

Restricciones admitidas

El servicio de AC 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.

Restringe o fuerza los valores X.509 permitidos

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

Un grupo de AC también puede especificar explícitamente los valores de X.509 que se agregarán a todos sus certificados emitidos, reemplazando cualquier valor solicitado, mediante el campo baseline_values.

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

• Uso de la clave
• Opciones de AC
• Servidores OCSP de AIA
• Extensiones X.509 adicionales

También puedes usar estas opciones en conjunto.

Si actualizas cualquier parte del campo baseline_values, la actualización reemplazará todo el conjunto de valores del campo baseline_values.

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

  policy.yaml

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

• Ejemplo: Restringe una AC para que emita solo certificados de firma de código de entidad final con una URL de 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.

Restringe los campos de identidad permitidos

Para restringir la identidad de los certificados emitidos a través de un grupo de AC, puedes agregar una expresión de Common Expression Language (CEL) al campo identity_constraints de la política de emisión. Las expresiones de CEL permiten restricciones arbitrarias sobre el nombre de dominio del sujeto (incluido el nombre común) y los SAN de un certificado.

Para obtener más información sobre el uso de una expresión CEL para restringir el asunto y los SAN, consulta Cómo usar CEL.

• Ejemplo: Permite que la AC emita solo certificados que coincidan con un sujeto 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 Common Expression Language (CEL) para validar el asunto y el SAN X.509 resueltos antes de firmar un certificado. Para obtener más información sobre el uso de expresiones CEL, consulta Cómo usar CEL.

• Ejemplo: Permite solo SAN que tengan nombres de 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 SAN que tengan URIs https://google.com/webhp o que comiencen con 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 SAN que tengan direcciones de correo electrónico [email protected] 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 == "[email protected]" || san.value.endsWith("@google.org")) )'
  

• Ejemplo: Permite solo SAN personalizadas 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" )'
  

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

Para restringir la vida útil de los certificados emitidos, usa el campo maximum_lifetime. Si la vida útil solicitada de un certificado es mayor que la máxima, se trunca de forma explícita.

Ejemplo

Para permitir un ciclo de vida máximo de 30 días, usa el siguiente archivo policy.yaml:

maximumLifetime: 2592000s

Restringe los modos de emisión de certificados permitidos

Puedes solicitar un certificado a través de una solicitud de firma de certificado (CSR) o una descripción intercalada de los valores solicitados. Algunas organizaciones pueden preferir agregar limitaciones a la opción que se puede usar porque el último método no requiere un comprobante de posesión de la clave privada asociada. Puedes establecer estas limitaciones con el campo allowedIssuanceModes.

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

Para obtener más información sobre cómo solicitar certificados, consulta Cómo crear una solicitud de certificado.

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

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

Restringe 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, puedes usar el campo allowedKeyTypes en el 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 claves que se indican en el archivo YAML. Si no se especifica este campo, puedes usar cualquier clave, a excepción de las claves RSA cuyo tamaño de módulo sea inferior a 2048 bits. Si deseas usar una clave RSA con un tamaño de módulo inferior a 2048 bits, debes permitirlo de forma explícita con la política de emisión de certificados.

Ejemplo: Permite claves RSA con un tamaño de módulo entre 3072 bits y 4096 bits (inclusive), o claves de algoritmo de firma digital de curva elíptica (ECDSA) sobre la curva P-256 de 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, como se describe en RFC 8410.

¿Qué sigue?

• Obtén más información sobre los perfiles de certificado.
• Obtén más información para solicitar certificados.
• Obtén más información para configurar políticas de IAM.
• Obtén información para usar Common Expression Language (CEL).
• Obtén información para administrar varios controles de políticas.