502 Gateway inválido - Certificado autoassinado na cadeia

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Sintoma

O aplicativo cliente recebe um código de resposta HTTP 502 com a mensagem Bad Gateway como resposta para chamadas de API no Edge Microgateway.

Como alternativa, o administrador receberá um erro self signed certificate in certificate chain ao executar o comando edgemicro configure.

Mensagem de erro

O cliente verá a seguinte mensagem de resposta:

HTTP/1.1 502 Bad Gateway

Dois exemplos comuns de respostas de erro são:

{"message":"self signed certificate in certificate chain","code":"SELF_SIGNED_CERT_IN_CHAIN"}

{"message":"self signed certificate","code":"DEPTH_ZERO_SELF_SIGNED_CERT"}

Como alternativa, esse erro pode ocorrer ao executar edgemicro configure:

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

Causas possíveis

Causa: o servidor de destino apresenta um certificado autoassinado

Se um certificado autoassinado for apresentado pelo servidor de destino na conexão de saída, o Edge Microgateway vai gerar esse erro por padrão, porque não confia em certificados autoassinados.

Diagnóstico

Você pode observar o seguinte erro nos registros (/var/tmp/edgemicro-`hostname`- *.log):

2021-05-18T10:52:46.425Z [error][0:8000][1][gsc][test][edgemicro_badtargethost][][][2db53f80-
b7c7-11eb-9abe-05b6297863f1][microgateway-core][][GET][502][self signed certificate in certificate
chain][SELF_SIGNED_CERT_IN_CHAIN][]

O código de erro SELF_SIGNED_CERT_IN_CHAIN indica que o Edge Microgateway provavelmente recebeu um certificado autoassinado do servidor de destino. Para confirmar isso, siga estas etapas:

1. Execute o seguinte openssl comando para verificar a cadeia de certificados do servidor de destino:

   echo | openssl s_client -connect TARGET_SERVER_HOSTNAME:PORT -servername TARGET_SERVER_HOSTNAME | openssl x509 -noout
   

2. Se a cadeia de certificados do servidor de destino for autoassinada, essa será a causa de o problema.

   No exemplo a seguir, observe que o servidor de destino apresenta um certificado autoassinado:

   echo | openssl s_client -connect untrusted-root.badssl.com:443 -servername untrusted-root.badssl.com | openssl x509 -noout
   

   depth=1 C = US, ST = California, L = San Francisco, O = BadSSL, CN = BadSSL Untrusted Root Certificate Authority
   verify error:num=19:self signed certificate in certificate chain
   verify return:0
   DONE

Resolução

1. Trabalhe com a equipe proprietária do servidor de destino para adquirir um certificado TLS adequado assinado por uma autoridade certificadora (CA, na sigla em inglês) confiável.

2. Se isso não for possível, considere uma das seguintes opções para permitir certificados autoassinados no Edge Microgateway.

   Opção 1: definir uma propriedade do sistema para permitir que o Edge Microgateway confie em todos os certificados

   1. Se você estiver usando o Docker, consulte Como usar uma CA que não é confiável pelo Node.js

   2. Caso contrário, exporte uma variável de ambiente chamada NODE_EXTRA_CA_CERTS, apontando para o arquivo da CA raiz.

      Isso está documentado no site oficial do Node.js.

   Opção 2: configurar o arquivo de configuração YAML do Edge Microgateway para confiar nesse certificado específico para esse servidor de destino

   1. Verifique se você tem o certificado (ou cadeia) do servidor de destino no formato PEM. Para converter outros formatos de certificado em PEM, siga as instruções em Converter certificados para o formato compatível.

   2. Se houver uma cadeia de certificados, verifique se os certificados estão na ordem correta. O certificado de folha sempre precisa ser o primeiro, seguido pelo certificado intermediário e, em seguida, o certificado raiz. Há mais explicações sobre isso em Validar cadeia de certificados.

      No exemplo a seguir, configuramos o arquivo de CA confiável para untrusted-root.badssl.com.

      edgemicro:
      ...
      targets:
        - host: 'untrusted-root.badssl.com'
          ssl:
            client
              ca: /opt/apigee/certs/untrusted-root.pem

   As instruções para configurar isso também são abordadas no Módulo do Edge Microgateway: configurar o TLS de saída unidirecional e bidirecional vídeo. Consulte Como configurar o SSL no servidor do Edge Microgateway para mais informações.

Se o problema persistir, acesse Precisa de informações de diagnóstico.

Causa: o servidor de gerenciamento do Apigee Edge usa um certificado autoassinado

Quando o Edge Microgateway é configurado pela primeira vez, um dos comandos que você precisa executar é edgemicro configure ou edgemicro private configure. Esse comando vai inicializar o cluster e entrar em contato com o Apigee Edge para fazer o download das informações necessárias.

Para a nuvem privada do Edge, o URL do servidor de gerenciamento é determinado pelo argumento -m. Se você ativou o TLS para o servidor de gerenciamento, o Edge Microgateway vai tentar verificar o certificado apresentado pelo servidor de gerenciamento.

Confira um exemplo de comando edgemicro configure para a nuvem privada do Edge:

edgemicro private configure -u <username> -p <password> -o apigee -e dev -v secure -r https://apigee-dev.net -m https://management.apigee-dev.net:8443

Se o servidor de gerenciamento estiver configurado com um certificado autoassinado, você vai receber o seguinte erro na saída do console.

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

Diagnóstico

1. Nesse caso, o servidor de gerenciamento (management.apigee-dev.net) pode estar retornando um certificado TLS autoassinado.
2. É provável que o administrador do sistema do Apigee Edge tenha fornecido o certificado e tenha uma cópia dele.
3. Caso contrário, execute o seguinte comando para receber informações sobre o certificado:

   echo | openssl s_client -connect management.apigee-dev.net:8443 -servername management.apigee-dev.net | openssl x509 -noout
   

4. Se o servidor de gerenciamento tiver um certificado autoassinado, essa será a causa do problema.

Resolução

1. Trabalhe com a equipe proprietária do servidor de destino para adquirir um certificado TLS adequado assinado por uma autoridade certificadora (CA, na sigla em inglês) confiável.

2. Se isso não for possível, faça o seguinte para permitir certificados autoassinados no Edge Microgateway.

3. Defina uma propriedade do sistema para permitir que o Edge Microgateway confie em todos os certificados.
4. Se você estiver usando o Docker, consulte Como usar uma CA que não é confiável pelo Node.js.
5. Caso contrário, exporte uma variável de ambiente chamada NODE_EXTRA_CA_CERTS, apontando para o arquivo da CA raiz. Isso está documentado no site oficial do Node.js

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e entre em contato com o Suporte do Apigee Edge:

• Arquivos de registro: a pasta padrão é /var/tmp, mas ela pode ser substituída no arquivo config.yaml principal (logging > dir parameter). É recomendado mudar o log > level para info antes de fornecer os arquivos de registro ao Suporte do Apigee Edge.
• Arquivo de configuração: a configuração principal do Edge Microgateway reside no arquivo YAML na pasta padrão do Edge Microgateway, $HOME/.edgemicro. Há um arquivo de configuração padrão chamado default.yaml e outro para cada ambiente ORG-ENV-config.yaml. Faça o upload desse arquivo completo para a organização e o ambiente afetados.

  Documentos de referência

  Configurar a interface do Edge para usar o TLS para acessar a API Edge