Esta página descreve os erros mais comuns que pode encontrar quando usa o Gestor de certificados. Também fornece passos para diagnosticar e resolver esses erros.
Problemas relacionados com certificados TLS (SSL)
Para receber ajuda na resolução de problemas relacionados com certificados TLS (SSL), consulte o artigo Resolução de problemas de certificados SSL.
Erro ao desassociar um mapeamento de certificados de um proxy de destino
Quando desanexa um mapeamento de certificados de um proxy de destino, recebe o seguinte erro:
"There must be at least one certificate configured for a target proxy."
Este erro ocorre quando não existem certificados atribuídos ao proxy de destino, exceto os especificados no mapeamento de certificados que está a tentar desassociar. Para desassociar o mapa, atribua primeiro um ou mais certificados diretamente ao proxy.
Erro ao associar uma entrada do mapa de certificados a um certificado
Quando associa uma entrada do mapa de certificados a um certificado, recebe o seguinte erro:
"certificate can't be used more than 100 times"
Este erro ocorre quando tenta associar uma entrada do mapa de certificados a um certificado que já está associado a 100 entradas do mapa de certificados. Para resolver o problema, faça o seguinte:
- Para certificados geridos pela Google, crie outro certificado. Associe as entradas do mapa de certificados ao novo certificado e anexe o novo certificado ao equilibrador de carga.
- Para certificados autogeridos, carregue novamente o certificado com um novo nome. Associe as novas entradas do mapa de certificados a este novo certificado e anexe o novo certificado ao equilibrador de carga.
Problemas relacionados com certificados emitidos por uma instância do serviço de AC
Esta secção apresenta os erros mais comuns que pode encontrar quando usa o gestor de certificados para implementar certificados geridos pela Google emitidos pela sua instância do serviço de AC e as respetivas causas possíveis.
Se receber o erro Failed to create Certificate Issuance Config resources
, verifique o seguinte:
- A duração total. Os valores válidos do tempo de vida útil do certificado variam entre 21 e 30 dias.
- A percentagem do período de rotação. As percentagens válidas do período de rotação variam entre 1 e 99 por cento. Tem de definir a percentagem da janela de rotação em relação ao tempo de vida do certificado para que a renovação do certificado ocorra, pelo menos, 7 dias após a emissão do certificado e, pelo menos, 7 dias antes da respetiva expiração.
- O algoritmo da chave. Os valores válidos do algoritmo de chave são:
RSA_2048
eECDSA_P256
. - O grupo de ACs. O conjunto de ACs não existe ou está configurado incorretamente.
O conjunto de ACs tem de conter, pelo menos, uma AC ativada e o autor da chamada tem de ter a autorização
privateca.capools.use
no projetoGoogle Cloud alvo. Para certificados regionais, o recurso de configuração de emissão de certificados tem de ser criado na mesma localização que o conjunto de ACs.
Se receber um erro Failed to create a managed certificate
, verifique o seguinte:
- O recurso de configuração de emissão de certificados que especificou quando criou o certificado existe.
- O autor da chamada tem a autorização
certificatemanager.certissuanceconfigs.use
no recurso de configuração de emissão de certificados que especificou quando criou o certificado. - O certificado está na mesma localização que o recurso de configuração de emissão de certificados.
Se receber um erro Failed to renew certificate
ou Failed to provision
certificate
, verifique o seguinte:
A conta de serviço do Gestor de certificados tem a autorização
roles/privateca.certificateRequester
no conjunto de ACs especificado no recurso de configuração de emissão de certificados usado para este certificado.Use o seguinte comando para verificar as autorizações no conjunto de ACs de destino:
gcloud privateca pools get-iam-policy CA_POOL --location REGION
Substitua o seguinte:
CA_POOL
: o caminho e o nome completos do recurso do grupo de ACs de destinoREGION
: a região Google Cloud alvo
Está em vigor uma política de emissão de certificados. Para mais informações, consulte o artigo Problemas relacionados com restrições da política de emissão.
Problemas relacionados com restrições da política de emissão
Se o Gestor de certificados não suportar as alterações a um certificado feitas pela política de emissão de certificados, o aprovisionamento de certificados falha e o estado do certificado gerido muda para Failed
. Para resolver o problema, confirme o seguinte:
- As restrições de identidade do certificado permitem a transferência direta do requerente e do nome alternativo do requerente (SAN).
- A restrição de duração máxima do certificado é superior à duração do recurso de configuração de emissão de certificados.
Para os problemas anteriores, uma vez que o serviço de AC já emitiu o certificado, a faturação é feita de acordo com os preços do serviço de AC.
Se receber o erro Rejected for issuing certificates from the configured
CA Pool
, significa que a política de emissão de certificados bloqueou o certificado pedido. Para resolver o erro, verifique o seguinte:
- O modo de emissão do certificado permite pedidos de assinatura de certificados (CSRs).
- Os tipos de chaves permitidos são compatíveis com o algoritmo de chave do recurso de configuração de emissão de certificados que está a ser usado.
Para os problemas anteriores, uma vez que o serviço de AC não emitiu o certificado, não recebe faturação do serviço de AC.
Problemas relacionados com a correspondência do nome do anfitrião da IAP
Se receber inesperadamente o erro The host name provided does not match the
SSL certificate on the server
quando usar o Gestor de certificados com o
Identity-Aware Proxy (IAP), verifique se está a usar um certificado
válido para esse nome de anfitrião. Também lista as entradas do mapa de certificados
que configurou no seu mapa de certificados. Todos os nomes de anfitrião ou nomes de anfitrião com carateres universais que pretenda usar com a IAP têm de ter uma entrada dedicada. Se a entrada do mapa de certificados para o seu nome de anfitrião estiver em falta, crie uma
entrada do mapa de certificados.
Os pedidos que recorrem à entrada do mapa de certificados principal durante a seleção de certificados são sempre rejeitados pela IAP.
Falhas na validação de domínio de várias perspetivas
Google Cloud renova periodicamente os seus certificados geridos pela Google pedindo-os às autoridades de certificação (ACs). As ACs com as quais Google Cloud trabalha para renovar os seus certificados usam um método de validação de domínio de várias perspetivas conhecido como Multi-Perspective Issuance Corroboration (MPIC). Como parte deste processo, as autoridades de certificação validam o controlo do domínio verificando as definições de DNS do domínio e, no caso da autorização do equilibrador de carga, tentando contactar o servidor através do endereço IP do domínio. Estas validações são realizadas a partir de vários pontos de vista na Internet. Se o processo de validação falhar, os certificados geridos pela Google não são renovados. Consequentemente, o seu equilibrador de carga apresenta um certificado expirado aos clientes, o que faz com que os utilizadores do navegador encontrem erros de certificado e os clientes da API tenham falhas de ligação.
Para evitar falhas de validação de domínio com várias perspetivas devido a registos de DNS configurados incorretamente, tenha em atenção o seguinte:
- Os seus registos A de DNS (IPv4) e registos AAAA de DNS (IPv6) para os seus domínios e subdomínios apontam apenas para o endereço IP (ou endereços) associado à regra (ou regras) de encaminhamento do balanceador de carga. A existência de outros endereços no registo pode fazer com que a validação falhe.
- A AC, que realiza a validação de registos DNS, consulta registos DNS a partir de várias localizações. Certifique-se de que o seu fornecedor de DNS responde de forma consistente a todos os pedidos de validação de domínio global.
- A utilização de GeoDNS (devolver diferentes endereços IP com base na localização do pedido) ou políticas de DNS baseadas na localização pode originar respostas inconsistentes e fazer com que a validação falhe. Se o seu fornecedor de DNS usar o GeoDNS, desative-o ou certifique-se de que todas as regiões devolvem o endereço IP do balanceador de carga.
- Se estiver a usar o método de autorização do equilibrador de carga para aprovisionar certificados geridos pela Google, tem de especificar explicitamente os endereços IP do equilibrador de carga na configuração de DNS. As camadas intermédias, como uma RFC, podem causar um comportamento imprevisível. O endereço IP tem de estar diretamente acessível sem redirecionamentos, firewalls ou CDNs no caminho do pedido. Para saber mais, consulte a secção Equilibradores de carga atrás de uma RFC neste documento.
- Recomendamos que use um verificador de propagação global de DNS à sua escolha para verificar se todos os registos de DNS relevantes são resolvidos corretamente e de forma consistente em todo o mundo.
Valide as alterações de configuração
Depois de configurar os Registos de DNS, pode verificar se estão corretos criando um novo certificado e associando-o ao equilibrador de carga juntamente com o certificado existente. Este passo força uma verificação imediata do aprovisionamento de certificados junto da AC, o que lhe permite validar as alterações de configuração em poucos minutos. Sem esta opção, as renovações automáticas do certificado existente podem demorar dias ou semanas, o que gera incerteza acerca da sua configuração.
Se o estado do certificado se tornar ACTIVE
, indica que o certificado foi emitido, confirmando assim que a sua configuração de DNS está correta. Neste ponto, recomendamos que remova o certificado anterior para evitar ter dois certificados separados para o mesmo domínio. Este processo
não interrompe o tráfego para o equilibrador de carga.
O novo certificado serve como ferramenta de validação. A sua criação confirma que a validação de domínio com várias perspetivas através do MPIC funciona corretamente para a sua configuração.
Balanceadores de carga atrás de uma RFC
Para balanceadores de carga com a RFC ativada, alguns fornecedores de RFC de terceiros no caminho do pedido podem impedir que os pedidos de validação sejam bem-sucedidos. Isto pode acontecer se o fornecedor de RFC estiver a usar ativamente um proxy para o tráfego HTTP(S).
Nestes casos, recomendamos que use o método de autorização de DNS para aprovisionar certificados geridos pela Google. Esta abordagem não requer que a AC contacte o seu equilibrador de carga.