Adicionar uma política de emissão de certificados a um pool de ACs

Esta página descreve como adicionar uma política de emissão de certificados a um pool de autoridades certificadoras (ACs, na sigla em inglês).

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.

Adicionar um arquivo de política de emissão de certificados

Para adicionar uma política de emissão de certificados a um pool de ACs, faça o seguinte:

Console

1. Acesse a página Serviço de autoridade certificadora no console do Google Cloud.

   Acesse 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.

Configurar valores de referência

Para configurar valores de referência nos certificados emitidos pelo pool de ACs, faça o seguinte:

1. Clique no botão.
2. Clique em Configurar valores de referência.

Definir o uso da chave base

É possível usar essa configuração para definir as maneiras de usar a chave contida no certificado. As opções de uso da chave incluem a codificação de chaves, a codificação de dados, a assinatura de certificados, a assinatura de CRL e muito mais.

Para mais informações, consulte Uso da chave.

Para definir os usos de chave base, faça o seguinte:

1. Opcional: na janela que aparece, clique no botão de alternância se você quiser especificar usos de chaves básicas para os certificados.
2. Marque as caixas de seleção das formas em que você quer que uma chave seja usada.

3. Clique em Próxima.

Definir o uso estendido de chave

É possível usar essa configuração para selecionar cenários mais granulares em que a chave contida no certificado pode ser usada. As opções incluem autenticação do servidor, autenticação do cliente, assinatura de código, proteção de e-mail e muito mais.

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.

Para mais informações, consulte Uso estendido da chave.

Para definir os usos de chave estendidos, faça o seguinte:

1. Opcional: para especificar os usos de chave estendidos dos certificados emitidos pelo pool de CAs, clique na chave.
2. Marque as caixas de seleção para os cenários de uso estendido de chave.
3. 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. Opcional: adicione o identificador de política no campo Identificadores de políticas.
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 autoridades.

Para adicionar os servidores OCSP que aparecem no campo de extensão AIA nos certificados, faça o seguinte. O procedimento a seguir é opcional.

1. Opcional: 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.

Configurar outras extensões

Para configurar outras extensões personalizadas a serem incluídas nos certificados emitidos pelo pool de ACs, faça o seguinte. O procedimento a seguir é opcional.

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.

Configurar restrições de extensão

Para impedir que todas as extensões de solicitações de certificado sejam incluídas nos certificados emitidos, clique na chave.

Depois de clicar no botão, você vai encontrar o campo Extensões de certificado conhecidas, que pode ser usado para selecionar as extensões de certificado. Para selecionar as extensões de certificado, faça o seguinte:

1. Opcional: clique no campo Extensões de certificado conhecidas e limpe as extensões não obrigatórias do menu.
2. Opcional: no campo Extensões personalizadas, adicione os identificadores de objetos das extensões que você quer incluir nos certificados emitidos pelo pool de ACs.

Configurar restrições de identidade

Para configurar restrições no assunto e nos SANs nos certificados emitidos pelo pool de ACs, faça o seguinte:

1. Opcional: para impedir a transmissão do assunto nas solicitações de certificado, clique no botão de alternância.
2. Opcional: para impedir a transmissão de nomes alternativos de assunto em solicitações de certificado, clique na chave.
3. Opcional: adicione uma expressão da Common Expression Language (CEL) para colocar restrições nos sujeitos do certificado. Para mais informações, consulte Como usar a CEL.
4. Clique em Próxima.

Para saber como configurar outros parâmetros na política de emissão de certificados, consulte IssuancePolicy.

gcloud

Para usar a Google Cloud CLI e adicionar uma política de emissão de certificados a um pool de ACs, crie 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 do 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 \
     --issuance-policy FILE_PATH
   

   Substitua:

   • POOL_NAME: nome do pool de ACs.
   • 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 AC aceita as seguintes restrições de política de emissão. Você pode 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 ao configurar o campo passthrough_extensions.

Um pool de ACs 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 todo o conjunto de valores 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: restrinja 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 da linguagem de expressão comum (CEL) 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 determinado assunto.

  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 começam 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 o máximo, 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

É possível solicitar um certificado com 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 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 de um pool de ACs, consulte IssuanceModes.

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

• Exemplo: permitir 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, permita-a explicitamente usando a política de emissão de certificados.

Exemplo: permita 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) na 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 na RFC 8410.

A seguir

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