Adicionar políticas de emissão de certificados

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

Uma política de emissão de certificados permite especificar o assunto e os nomes alternativos de assunto (SANs, na sigla em inglês) 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 para adicionar uma política de emissão.

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

Atenção: as mudanças na política de emissão entram em vigor imediatamente. Antes de usar a política de emissão na produção, recomendamos que você teste as mudanças em uma instância de pool de AC de teste.

Antes de começar

• Verifique se você tem o papel do IAM de Gerente de operações de serviço de CA (roles/privateca.caManager) ou de administrador do serviço de CA (roles/privateca.admin). Para informações sobre como conceder um IAM a um membro, 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 ACs ao criar um pool de ACs ou atualizar um pool de ACs existente.

Use um dos seguintes métodos:

Console

1. Acesse a página Certificate Authority Service no console do Google Cloud. Acesse o Certificate Authority Service

2. Na página Gerenciador de pools de AC, clique no nome do pool de AC para o qual você quer adicionar uma política de emissão de certificados.

3. Na página Pool de AC, clique em Editar.

Definir o uso da chave base

Essa configuração se refere ao campo Key Usage em um certificado digital. Ele especifica como a chave privada do certificado pode ser usada, como para criptografia de chaves, criptografia de dados, assinatura de certificados e assinatura de CRLs. Para mais informações, consulte Uso da chave.

1. Para selecionar os usos de chave base, clique no botão Especificar usos de chave base em certificados emitidos neste pool de ACs e selecione uma das opções listadas.
2. Clique em Próxima.

Definir o uso estendido de chave

Essa configuração se refere ao campo Extended Key Usage (EKU) em um certificado digital. Ele oferece restrições mais específicas e refinadas sobre como a chave pode ser usada, como para autenticação do servidor, autenticação do cliente, assinatura de código e proteção de e-mail. Para mais informações, consulte Uso estendido da chave.

Os usos de chave estendidos são definidos usando identificadores de objeto (OIDs). Se você não configurar os usos de chave estendidos, todos os cenários de uso de chaves serão permitidos.

1. Para selecionar os usos de chave estendidos, clique no botão Gravar usos de chave estendidos para certificados emitidos neste pool de ACs e selecione uma das opções listadas.
2. Clique em Próxima.

Definir identificadores de políticas

A extensão de políticas de certificados no certificado expressa as políticas que o pool de ACs emissor segue. Essa extensão pode incluir informações sobre como as identidades são validadas antes da emissão de certificados, como os certificados são revogados e como a integridade do pool de ACs é garantida. Essa extensão ajuda você a verificar os certificados emitidos pelo pool de ACs e a conferir como eles são usados.

Para mais informações, consulte Políticas de certificados.

Para especificar a política que define o uso do certificado, faça o seguinte:

1. Adicione o identificador da política no campo Identificadores da política.
2. Clique em Próxima.

Adicionar servidores OCSP de acesso a informações de autoridade (AIA)

A extensão AIA em um certificado fornece as seguintes informações:

• Endereço dos servidores OCSP em que você pode verificar o status de revogação do certificado.
• O método de acesso do emissor do certificado.

Para mais informações, consulte Acesso a informações de autoridade.

Para adicionar os servidores OCSP que aparecem no campo de extensão AIA nos certificados, faça o seguinte:

1. Clique em Adicionar item.
2. No campo URL do servidor, adicione o URL do servidor OCSP.
3. Clique em Concluído.
4. Clique em Próxima.

Opções de assinatura digital

O campo Opções de AC em um modelo de certificado define como o certificado resultante pode ser usado em uma hierarquia de autoridades certificadoras (AC). As opções de AC determinam se um certificado pode ser usado para assinar outros certificados e, em caso afirmativo, as restrições nos certificados que ele emite.

Escolha entre as opções a seguir:

1. Incluir as configurações para descrever as extensões de X.509 da AC: especifique as configurações em um modelo de certificado que controlam as extensões de X.509.

2. Restrinja os certificados emitidos para uso apenas em ACs: essa opção aparece somente se você marcar a caixa de seleção mencionada na etapa anterior. Esse valor booleano indica se o certificado é um certificado de AC. Se definido como true, o certificado poderá ser usado para assinar outros certificados. Se false, o certificado é de entidade final e não pode assinar outros certificados. Ao clicar no botão, você vai precisar definir restrições de nome para a extensão em certificados de AC.

3. Incluir as configurações para descrever as extensões X.509 de restrição de tamanho do caminho: especifique as configurações que controlam o tamanho máximo de uma cadeia de certificados, originados de um certificado específico. Se o tamanho máximo do caminho do emissor estiver definido como 0, a AC só poderá emitir certificados de entidade final. Se estiver definido como 1, a cadeia abaixo desse certificado de AC poderá incluir apenas uma CA subordinada. Se um valor não for declarado, o número de ACs subordinados na cadeia abaixo dessa AC não terá limite.

4. Clique em Próxima.

Configurar extensões adicionais

Para configurar outras extensões personalizadas a serem incluídas nos certificados emitidos pelo pool de ACs, faça o seguinte:

1. Clique em Adicionar item.
2. No campo Identificador do objeto, adicione um identificador de objeto válido que esteja formatado como dígitos separados por pontos.
3. No campo Valor, adicione o valor codificado em base64 para o identificador.
4. Se a extensão for essencial, selecione A extensão é essencial.

Para salvar todas as configurações de valor de referência, clique em Concluído.

gcloud

Para usar a CLI do Google Cloud e adicionar uma política de emissão de certificados a um pool de ACs, é necessário criar um arquivo YAML que descreva as restrições nos certificados que o pool de ACs pode emitir. O conteúdo corresponde a uma IssuancePolicy.

1. Usando o editor do Cloud Shell, crie um arquivo policy.yaml com o seguinte conteúdo:

   identityConstraints:
     allowSubjectPassthrough: true
     allowSubjectAltNamesPassthrough: true
   

   Em que:

   • O campo allowSubjectPassthrough é obrigatório. Se o campo allowSubjectPassthrough estiver definido como true, o campo de assunto será copiado de uma solicitação de certificado para o certificado assinado. Caso contrário, o assunto solicitado será descartado.
   • Se o campo allowSubjectAltNamesPassthrough estiver definido como true, a extensão SubjectAltNames será copiada de uma solicitação de certificado para o certificado assinado. Caso contrário, os SubjectAltNames solicitados serão descartados.

2. Para atualizar a política de emissão de certificados de um pool de ACs usando o arquivo criado na etapa anterior, execute o seguinte comando:

   gcloud privateca pools update POOL_NAME --location LOCATION --issuance-policy FILE_PATH
   

   Substitua:

   • POOL_NAME: o nome do pool de ACs.
   • LOCATION: o local do pool de ACs. Para conferir a lista completa de locais, consulte Locais.
   • FILE_PATH: o caminho do arquivo policy.yaml.

   Para mais informações sobre o comando gcloud privateca pools update, consulte gcloud privateca pools update.

Restrições compatíveis

O serviço de autoridade certificadora oferece suporte às seguintes restrições de política de emissão. É possível combinar as restrições a seguir conforme necessário para criar uma política de emissão de certificados personalizada.

Restringir ou forçar valores X.509 permitidos

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

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

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

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

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

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

• Exemplo: restrinja uma AC 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: restringir uma AC para emitir apenas certificados de assinatura de código de entidade final com um URL de OCSP de AIA de referência.

  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 da entidade final, consulte mTLS da entidade final.

Restringir os campos de identidade permitidos

Para restringir a identidade dos certificados emitidos por um pool de ACs, adicione uma expressão [linguagem de expressão comum (CEL, na sigla em inglês)][4]{: .external} ao campo identity_constraints da política de emissão. As expressões de CEL permitem restrições arbitrárias sobre o nome de domínio do assunto (incluindo o nome comum) e os SANs de um certificado.

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

• Exemplo: permitir que a AC emita apenas certificados correspondentes 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 de Common Expression Language (CEL) para validar o assunto X.509 resolvido e o SAN antes que um certificado seja assinado. Para mais informações sobre o uso de 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 [e-mail] 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 == "[e-mail]" || san.value.endsWith("@google.org")) )'
  

• Exemplo: permita apenas SANs personalizados 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 o ciclo de vida máximo dos certificados emitidos

Para restringir a vida útil dos certificados emitidos, use o campo maximum_lifetime. Se a vida útil solicitada de um certificado for maior que a máxima, ela será truncada explicitamente.

Observação: um certificado nunca pode sobreviver à AC que o emitiu. Se uma solicitação de certificado mencionar um período de validade que exceda a data not_after_time da AC, o período de validade será truncado para corresponder à data not_after_time da AC. O ciclo de vida do certificado é truncado mesmo que a política de emissão de certificados permita um ciclo de vida mais longo.

Exemplo

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

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, na sigla em inglês) 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 um comprovante 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 de solicitar certificados em um pool de ACs, consulte IssuanceModes.

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

• Exemplo: permita apenas a emissão de CSR.

policy.yaml

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

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

Para restringir o comprimento 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, com a exceção de chaves RSA com tamanho de módulo menor que 2048 bits. Se você quiser usar uma chave RSA com um tamanho de módulo menor que 2.048 bits, é necessário permitir explicitamente o uso da política de emissão de certificados.

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

policy.yaml

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 sobre a curva 25519, conforme descrito no RFC 8410.

A seguir

• Saiba mais sobre os perfis de certificados.
• Saiba mais sobre como solicitar certificados.
• Saiba como configurar políticas do IAM.
• Saiba como usar a linguagem de expressão comum (CEL).
• Saiba como gerenciar vários controles de política.