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 autoridade de certificação (CA).
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 atual para adicionar uma política de emissão.
Para mais informações, consulte Visão geral de modelos e políticas de emissão.
Antes de começar
Verifique se você tem o papel do IAM de CA Service Operation Manager (
roles/privateca.caManager
) ou de Administrador de serviço de CA (roles/privateca.admin
). Para mais informações sobre como conceder um IAM a um principal, consulte Conceder um único papel.
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
Acesse a página Certificate Authority Service no console do Google Cloud.
Na página Gerenciador de pools de CAs, clique no nome do pool de CAs a que você quer adicionar uma política de emissão de certificados.
Na página Pool de CA, clique em
Editar.
Para configurar valores de referência nos certificados emitidos pelo pool de ACs, faça o seguinte:
- Clique no botão de alternância.
- Clique em Configurar valores de referência.
Use esta configuração para definir como a chave contida no certificado pode ser usada. As opções para uso de chaves incluem criptografia de chaves, de dados, de certificados, de CRL e muito mais.
Para mais informações, consulte Uso de chaves.
Para definir os usos básicos de chave, faça o seguinte:
- Opcional: na janela exibida, clique no botão de alternância se quiser especificar os usos de chave base nos certificados.
- Marque as caixas de seleção para as formas em que você deseja que uma chave seja usada.
- Clique em Próxima.
Use 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 com identificadores de objeto (OIDs). Se você não configurar os usos de chave estendidos, todos os cenários de uso de chave serão permitidos.
Para saber mais, consulte Uso estendido de chave.
Para definir os usos de chave estendidos, faça o seguinte:
- Opcional: para especificar o uso de chave estendido nos certificados emitidos pelo pool de ACs, clique no botão de alternância.
- Marque as caixas de seleção dos cenários de uso de chave estendido.
- Clique em Próxima.
A extensão das políticas de certificado no certificado expressa as políticas que o pool de ACs emissoras segue. Essa extensão pode incluir informações sobre como as identidades são validadas antes da emissão do certificado, como os certificados são revogados e como a integridade do pool de AC é garantida. Essa extensão ajuda a verificar os certificados emitidos pelo pool de ACs e a ver como os certificados são usados.
Saiba mais em Políticas de certificado.
Para especificar a política que define o uso do certificado, faça o seguinte:
- Opcional: adicione o identificador da política no campo Identificadores da política.
- Clique em Próxima.
A extensão AIA em um certificado fornece as seguintes informações:
- Endereço dos servidores OCSP em que é possível verificar o status de revogação do certificado.
- O método de acesso do emissor do certificado.
Para saber mais, 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. O procedimento a seguir é opcional.
- Opcional: clique em Adicionar item.
- No campo URL do servidor, adicione o URL do servidor OCSP.
- Clique em Concluído.
- Clique em Próxima.
Para configurar mais extensões personalizadas a serem incluídas nos certificados emitidos pelo pool de ACs, faça o seguinte. O procedimento a seguir é opcional.
- Clique em Adicionar item.
- No campo Identificador de objeto, adicione um identificador de objeto válido formatado como dígitos separados por pontos.
- No campo Valor, adicione o valor codificado em base64 para o identificador.
- Se a extensão for essencial, selecione A extensão é essencial.
Para salvar todas as configurações dos valores de referência, clique em Concluído.
Configurar restrições da extensãoPara impedir que todas as extensões de solicitações de certificado sejam incluídas nos certificados emitidos, clique no botão de alternância.
Depois de clicar no botão, você verá o campo Extensões de certificado conhecidas, que pode ser usada para selecionar as extensões de certificado. Para selecionar as extensões de certificado, faça o seguinte:
- Opcional: clique no campo Extensões de certificado conhecidas e limpe as extensões desnecessárias no menu.
- Opcional: no campo Extensões personalizadas, adicione os identificadores de objeto das extensões que você quer incluir nos certificados emitidos pelo pool de ACs.
Para configurar restrições de assunto e SANs nos certificados emitidos pelo pool de ACs, faça o seguinte:
- Opcional: para não permitir que o assunto de solicitações de certificado seja transmitido, clique no botão de alternância.
- Opcional: para impedir a transmissão de nomes alternativos de assunto em solicitações de certificado, clique no botão de alternância.
- Opcional: adicione uma expressão Common Expression Language (CEL) para impor restrições aos assuntos do certificado. Para mais informações, consulte Como usar a CEL.
- 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 para adicionar uma política de emissão de certificados a um pool de ACs, é preciso 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.
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 campoallowSubjectPassthrough
estiver definido comotrue
, 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 comotrue
, a extensão SubjectAltNames será copiada para o certificado assinado de uma solicitação. Caso contrário, os SubjectAltNames solicitados serão descartados.
- O campo
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 CA Service é compatível com as restrições de política de emissão a seguir. É possível combinar as restrições a seguir, conforme necessário, para criar uma política de emissão de certificados personalizados.
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 ACs também pode especificar explicitamente valores X.509 para serem adicionados a todos os certificados emitidos, substituindo os valores solicitados, usando o campo baseline_values.
Os valores baseline_values de um pool de ACs permitem especificar as seguintes propriedades:
Você também pode usar essas opções juntas.
Se você atualizar qualquer parte do campo baseline_values
, a atualização 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: restringir uma AC para emitir apenas certificados de assinatura de código de entidade final com um URL OCSP 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 saber mais sobre o perfil de certificado para mTLS de entidade final, consulte mTLS de entidade final.
Restringir campos de identidade permitidos
Para restringir a identidade de certificados emitidos por um pool de CAs, adicione uma expressão Common Expression Language (CEL) ao campo identity_constraints da política de emissão. As expressões CEL permitem restrições arbitrárias sobre o nome de domínio do assunto (incluindo o nome comum) e as SANs de um certificado.
Para mais informações sobre como usar uma expressão CEL para restringir assunto e SANs, consulte Como usar CEL.
Exemplo: permite 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 Common Expression Language (CEL) para validar o assunto X.509 resolvido e o SAN antes de um certificado ser assinado. Para mais informações sobre como usar expressões CEL, consulte Como usar CEL.Exemplo: permitir apenas SANs que tenham nomes 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: permitir apenas SANs que tenham URIs
https://google.com/webhp
ou começarem comspiffe://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 que tenham endereços de e-mail
example@google.com
ou terminados em@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 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 a vida útil máxima dos certificados emitidos
Para restringir a vida útil dos certificados emitidos, use o campo maximum_lifetime. Se o ciclo de vida solicitado de um certificado for maior que o ciclo de vida máximo, o ciclo de vida do certificado será explicitamente truncado.
Exemplo
Para permitir um ciclo de vida máximo de 30 dias, use este arquivo policy.yaml
:
policy.yaml
maximumLifetime: 2592000s
Restringir modos de emissão de certificados permitidos
Você pode solicitar um certificado por uma solicitação de assinatura de certificado (CSR, na sigla em inglês) ou por uma descrição em linha dos valores solicitados. Algumas organizações podem preferir acrescentar limitações à opção que pode ser usada porque o último método não requer 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 como os certificados podem ser solicitados de um pool de ACs, consulte IssuanceModes.
Para mais informações sobre a solicitação de 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 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 do certificado precisará corresponder a um dos tipos de chave listados no arquivo YAML. Se esse campo não for especificado, será possível usar qualquer chave, exceto as chaves 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, será necessário permitir explicitamente usando a política de emissão de certificados.
Exemplo: permita chaves RSA com tamanho de módulo entre 3.072 bits e 4.096 bits (inclusive) ou chaves do algoritmo de assinatura digital de curva elíptica (ECDSA, na sigla em inglês) 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 sobre a curva NIST P-256.ECDSA_P384
: assinatura digital de curva elíptica sobre a curva NIST P-384.EDDSA_25519
: algoritmo de assinatura digital de curvas Edwards sobre a 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.