Agrega políticas de emisión de certificados

Agregar políticas de emisión de certificados en CA Service implica definir reglas y restricciones que rigen los tipos de certificados que emite una autoridad certificadora (AC). Para obtener más información sobre las políticas de emisión de certificados, consulta Acerca de las políticas de emisión de certificados.

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 administrador del servicio de AC (roles/privateca.admin). Para obtener información sobre cómo otorgar un rol de IAM a un principal, consulta Otorga un solo rol.

• Crea un grupo de CA.

Puedes agregar una política de emisión de certificados a un grupo de CA cuando creas un grupo de CA o cuando actualizas uno existente.

Usa uno de los siguientes métodos:

Restricciones admitidas

El servicio de CA admite las siguientes restricciones de políticas 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 CA puede restringir los valores de X.509 permitidos en las solicitudes de certificados configurando el campo passthrough_extensions.

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

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

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

También puedes usar estas opciones juntas.

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

• Ejemplo: Restringe una CA para que solo emita 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 para 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 CA, puedes agregar una expresión de [Common Expression Language (CEL)][4]{: .external} 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 cómo usar una expresión CEL para restringir el sujeto y los SAN, consulta Uso de CEL.

• Ejemplo: Permite que la CA 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 resueltos de X.509 antes de que se firme un certificado. Para obtener más información sobre el uso de expresiones CEL, consulta Uso de CEL.

• Ejemplo: Permite solo los 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 los 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 los SAN que tengan direcciones de correo electrónico example@google.com o que terminen con @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 los SAN personalizados que tienen 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 de la fecha anterior de los certificados emitidos

Para establecer un valor de not_before_time anterior para los certificados emitidos, usa el campo backdate_duration. Cuando se configuran, los certificados de este grupo de CA tienen un not_before_time igual a la hora de emisión menos la duración especificada. El parámetro not_after_time se ajusta para mantener la vida útil del certificado solicitada. La backdate_duration debe ser menor o igual que 48 horas.

Ejemplo

Para adelantar la fecha de los certificados en 1 hora, usa el siguiente archivo policy.yaml:

backdateDuration: 3600s

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 vida útil máxima, se trunca explícitamente la vida útil del certificado.

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 tal vez prefieran agregar limitaciones a la opción que se puede usar, ya que el último método no requiere una prueba 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 CA, consulta IssuanceModes.

Para obtener más información sobre cómo solicitar certificados, consulta Crea 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 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 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 3,072 y 4,096 bits (inclusive), o claves del algoritmo de firma digital de curva elíptica (ECDSA) sobre la curva NIST P-256.

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 el RFC 8410.

¿Qué sigue?

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