Adicionar políticas de emissão de certificados

Adicionar políticas de emissão de certificados no CA Service envolve definir regras e restrições que regem os tipos de certificados emitidos por uma autoridade certificadora (CA). Para saber mais sobre as políticas de emissão de certificados, consulte Sobre as políticas de emissão de certificados.

Com uma política de emissão de certificados, é possível especificar o assunto e os nomes alternativos do assunto (SANs) que podem ser incluídos nos certificados emitidos. É possível especificar a política de emissão de certificados ao criar um pool de ACs ou atualizar um pool de ACs existente para adicionar uma política de emissão.

Para mais informações, consulte Visão geral dos modelos e das políticas de emissão.

Antes de começar

• Verifique se você tem o papel do IAM de gerente de operações de serviço da CA (roles/privateca.caManager) ou administrador de serviço da CA (roles/privateca.admin). Para informações sobre como conceder um IAM a um principal, consulte Conceder um único papel.

• Criar um pool de CA.

É possível adicionar uma política de emissão de certificados a um pool de CAs ao criar ou atualizar um pool de CAs.

Use um dos seguintes métodos:

Restrições aceitas

O CA Service é compatível com as seguintes restrições de política de emissão. É possível combinar as seguintes restrições conforme necessário para criar uma política personalizada de emissão de certificados.

Restringir ou forçar valores X.509 permitidos

Um pool de CA pode restringir os valores X.509 permitidos em solicitações de certificado configurando o campo passthrough_extensions.

Um pool de CA também pode especificar explicitamente valores X.509 a serem adicionados a todos os certificados emitidos, substituindo os valores solicitados, usando o campo baseline_values.

Os valores baseline_values de um pool de CAs permitem especificar as seguintes propriedades:

• Uso da chave
• Opções de CA
• Servidores OCSP do AIA
• Outras extensões X.509

Também é possível usar essas opções juntas.

Se você atualizar qualquer parte do campo baseline_values, a atualização vai substituir todo o conjunto de valores nesse campo.baseline_values

• Exemplo: restrinja uma CA para emitir apenas certificados de entidade final com valores X.509 para TLS mútuo (mTLS).

  policy.yaml

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

• Exemplo: restrinja uma AC para emitir apenas certificados de assinatura de código de entidade final com um URL OCSP de AIA básico.

  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 mais informações sobre o perfil de certificado para mTLS de entidade final, consulte mTLS de entidade final.

Restringir campos de identidade permitidos

Para restringir a identidade dos certificados emitidos por um pool de CAs, adicione uma expressão da [Common Expression Language (CEL)][4]{: .external} ao campo identity_constraints da política de emissão. As expressões CEL permitem restrições arbitrárias no nome de domínio do assunto (incluindo o nome comum) e nos SANs de um certificado.

Para mais informações sobre como usar uma expressão CEL para restringir o assunto e os SANs, consulte Usar a CEL.

• Exemplo: permitir que a CA emita apenas certificados que correspondam a um assunto especificado.

  policy.yaml

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

  O campo celExpression é opcional. Use uma expressão da Common Expression Language (CEL) para validar o assunto e o SAN X.509 resolvidos antes da assinatura de um certificado. Para mais informações sobre como usar expressões CEL, consulte Como usar a CEL.

• Exemplo: permitir apenas SANs com nomes de DNS como us.google.org ou que terminem em .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")) )'
  

• Exemplo: permita apenas SANs com URIs https://google.com/webhp ou que comecem com 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/")) )'
  

• Exemplo: permitir apenas SANs com endereços de e-mail example@google.com ou que terminem com @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")) )'
  

• Exemplo: permitir apenas SANs personalizadas com um OID específico e um 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 a duração da data retroativa dos certificados emitidos

Para definir um not_before_time anterior para certificados emitidos, use o campo backdate_duration. Quando configurados, os certificados desse pool de ACs têm um not_before_time igual ao horário de emissão menos a duração especificada. O not_after_time é ajustado para manter o ciclo de vida solicitado do certificado. A backdate_duration precisa ser menor ou igual a 48 horas.

Exemplo

Para atrasar os certificados em uma hora, use o seguinte arquivo policy.yaml:

backdateDuration: 3600s

Restringir o ciclo de vida máximo dos certificados emitidos

Para restringir o ciclo de vida dos certificados emitidos, use o campo maximum_lifetime. Se o ciclo de vida solicitado de um certificado for maior que o máximo, ele será truncado explicitamente.

Exemplo

Para permitir uma duração máxima de 30 dias, use o seguinte arquivo policy.yaml:

maximumLifetime: 2592000s

Restringir os modos de emissão de certificados permitidos

Você pode solicitar um certificado usando uma solicitação de assinatura de certificado (CSR) ou uma descrição inline dos valores solicitados. Algumas organizações podem preferir adicionar limitações à opção que pode ser usada porque o último método não exige uma prova de posse da chave privada associada. É possível definir essas limitações usando o campo allowedIssuanceModes.

Para mais informações sobre como especificar as maneiras pelas quais os certificados podem ser solicitados de um pool de CAs, consulte IssuanceModes.

Para mais informações sobre como solicitar certificados, consulte Criar uma solicitação de certificado.

• Exemplo: permitir apenas a emissão de CSRs.

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

Restringir os algoritmos de chave pública da solicitação de certificado

Para restringir o tamanho mínimo da chave e os algoritmos de chave pública que os certificados podem usar, use o campo allowedKeyTypes no arquivo YAML da política de emissão de certificados. Se esse campo for especificado, a chave pública da solicitação de certificado precisará corresponder a um dos tipos de chave listados no arquivo YAML. Se esse campo não for especificado, você poderá usar qualquer chave, exceto as RSA com tamanho de módulo menor que 2.048 bits. Se você quiser usar uma chave RSA com tamanho de módulo menor que 2.048 bits, permita explicitamente usando a política de emissão de certificados.

Exemplo: permitir chaves RSA com um tamanho de módulo entre 3072 bits e 4096 bits (inclusive) ou chaves do algoritmo de assinatura digital de curva elíptica (ECDSA) na curva NIST P-256.

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

Você pode escolher um dos seguintes algoritmos de assinatura de curva elíptica:

• EC_SIGNATURE_ALGORITHM_UNSPECIFIED: qualquer algoritmo de assinatura pode ser usado.
• ECDSA_P256: assinatura digital de curva elíptica na curva NIST P-256.
• ECDSA_P384: assinatura digital de curva elíptica na curva NIST P-384.
• EDDSA_25519: algoritmo de assinatura digital de curva de Edwards na curva 25519, conforme descrito na RFC 8410.

A seguir

• Saiba mais sobre perfis de certificado.
• Saiba mais sobre como solicitar certificados.
• Saiba como configurar políticas do IAM.
• Saiba como usar a Common Expression Language (CEL).
• Saiba como gerenciar vários controles de política.