503 Serviço indisponível - Falha no handshake de SSL

Monitoramento de APIs

Procedimento no 1: como usar o monitoramento de APIs

Para diagnosticar o erro usando a API Monitoring:

1. Faça login na interface do Apigee Edge como usuário com um para o papel apropriado.

2. Alterne para a organização na qual você deseja investigar o problema.

   
3. Navegue até o menu Analisar > Monitoramento de APIs > Investigar.
4. Selecione o período específico em que você observou os erros.

5. Compare Código de falha com Time.

6. Selecione uma célula que contenha o código de falha messaging.adaptors.http.flow.SslHandshakeFailed conforme mostrado abaixo:

   ( ver imagem maior)

   

7. Informações sobre o código de falha messaging.adaptors.http.flow.SslHandshakeFailed aparece como mostrados abaixo:

   ( ver imagem maior)

   

8. Clique em Ver registros e expanda a linha da solicitação com falha.

   ( ver imagem maior)

   
9. Na janela Registros, observe os seguintes detalhes:
   • ID da mensagem da solicitação
   • Código de status: 503
   • Origem da falha: target
   • Código da falha:messaging.adaptors.http.flow.SslHandshakeFailed

Trace

Procedimento no 2: como usar a ferramenta Trace

Para diagnosticar o erro usando a ferramenta Trace:

1. Ative a sessão de rastreamento e
   • Aguarde o erro 503 Service Unavailable com o código do erro. messaging.adaptors.http.flow.SslHandshakeFailed ocorrer ou
   • Se você puder reproduzir o problema, faça a chamada de API para reproduzir o problema 503 Service Unavailable

2. Verifique se Mostrar todos os FlowInfos está ativado:

   
3. Selecione uma das solicitações com falha e examine o trace.
4. Navegar pelas diferentes fases do trace e localizar onde a falha ocorreu.

5. Normalmente, o erro ocorre após a fase Fluxo de solicitação de destino iniciado. conforme mostrado abaixo:

   ( ver imagem maior)

   
6. Observe os seguintes valores do trace:
   • erro: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.class::com.apigee.errors.http.server.ServiceUnavailableException
   • O valor do erro SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target indica que o handshake de SSL falhou. porque o processador de mensagens do Apigee Edge não conseguiu validar as configurações certificado.
7. Navegue até a fase AX (dados do Analytics registrados) no trace e clique nela.

8. Role para baixo até a seção Cabeçalhos de erro de detalhes da fase e determine os de X-Apigee-fault-code e X-Apigee-fault-source, e X-Apigee-Message-ID, conforme mostrado abaixo:

   ( ver imagem maior)

   
9. Anote os valores de X-Apigee-fault-code, X-Apigee-fault-source, e X-Apigee-Message-ID:

Cabeçalhos de erro	Valor
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

Procedimento no 3: como usar registros de acesso do NGINX

Para diagnosticar o erro usando registros de acesso do NGINX:

1. Se você for um usuário da nuvem privada, poderá usar os registros de acesso do NGINX para determinar as principais informações sobre o 503 Service Unavailable do HTTP.

2. Verifique os registros de acesso do NGINX:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

3. Pesquise se há algum erro 503 com o código de erro. messaging.adaptors.http.flow.SslHandshakeFailed durante um período específico (se o problema tiver acontecido anterior) ou se ainda há solicitações falhando com 503.

4. Se você encontrar erros 503 com a correspondência X-Apigee-fault-code o valor de messaging.adaptors.http.flow.SslHandshakeFailed, então determinar o valor de X-Apigee-fault-source.

   Exemplo de erro 503 do registro de acesso do NGINX:

   ( ver imagem maior)

   

   O exemplo de entrada do registro de acesso do NGINX acima tem os seguintes valores para X-Apigee-fault-code e X-Apigee-fault-code

   Cabeçalhos	Valor
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Registros do processador de mensagens

Procedimento no 4: como usar registros do processador de mensagens

1. Determinar o ID da mensagem de uma das solicitações com falha usando a API Monitoring, a ferramenta Trace ou Registros de acesso do NGINX, conforme explicado nas Etapas comuns de diagnóstico.

2. Pesquisar o ID da mensagem de solicitação específica no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log). Você pode observar o seguinte erro:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
   SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:192.168.194.140:55102]@64596 useCount=1
   bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
   isOpen=true handshake failed, message: General SSLEngine problem
   

   O erro acima indica que o handshake de SSL falhou entre o processador de mensagens e o servidor de back-end.

   Isso será seguido por uma exceção com um stack trace detalhado, conforme mostrado abaixo:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
   RequestWriteListener.onException(HTTPRequest@1522922c)
   javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
   	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
   	... <snipped>
   Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
   	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
   	... <snipped>
   Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
   sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
   certification path to requested target
   	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
   	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
   	... <snipped>
     

   Observe que a falha de handshake se deve ao seguinte:

   Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

   Isso indica que o handshake de SSL falhou enquanto o processador de mensagens do Apigee Edge estava não conseguiu validar o certificado do servidor de back-end.

Fase 1

Fase 1: determinar a cadeia de certificados do servidor de back-end

Use um dos métodos a seguir para determinar a cadeia de certificados do servidor de back-end:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

Fase 2

Fase 2: comparar os certificados do servidor de back-end armazenados no o truststore do processador de mensagens

1. Determine a cadeia de certificados do servidor de back-end.
2. Determine o certificado armazenado no truststore do processador de mensagens usando as seguintes etapas:

   1. Consiga o nome de referência do truststore do elemento TrustStore na seção SSLInfo no TargetEndpoint.

      Vamos conferir um exemplo de seção de SSLInfo em um TargetEndpoint configuração:

      <TargetEndpoint name="default">
      ...
         <HTTPTargetConnection>
            <Properties />
            <SSLInfo>
               <Enabled>true</Enabled>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <KeyStore>ref://myKeystoreRef</KeyStore>
               <KeyAlias>myKey</KeyAlias>
               <TrustStore>
                  ref://myCompanyTrustStoreRef
               </TrustStore>
            </SSLInfo>
         </HTTPTargetConnection>
         ...
      </TargetEndpoint>
      

   2. No exemplo acima, o nome de referência TrustStore é myCompanyTruststoreRef.

   3. Na IU do Edge, selecione Ambientes > Referências. Anote o nome na Coluna Reference da referência do truststore específica. Ele será seu nome do truststore.

      ( ver imagem maior)

      

   4. No exemplo acima, o nome do truststore é:

      myCompanyTruststoreRef: myCompanyTruststore

3. Obter os certificados armazenados no truststore (determinado na etapa anterior) usando as seguintes APIs:

   1. Receber todos os certificados de um keystore ou truststore Essa API lista todas as certificados no truststore específico.

      Usuário da nuvem pública:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Usuário da nuvem privada:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Onde:

      • ORGANIZATION_NAME é o nome da organização.
      • ENVIRONMENT_NAME é o nome do ambiente;
      • KEYSTORE_NAME é o nome do keystore.
      • $TOKEN está definida para seu token de acesso OAuth 2.0, conforme descrito em Receber um token de acesso do OAuth 2.0
      • As opções de curl usadas neste exemplo estão descritas em Usar curl

      Exemplo de resposta:

      Os certificados do exemplo de truststore myCompanyTruststore são:

      [
        "serverCert"
      ]
      

   2. Acessar detalhes do certificado específico de um Keystore ou Truststore. Essa API retorna as informações sobre um certificado específico no determinado o truststore.

      Usuário da nuvem pública:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Usuário da nuvem privada

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Onde:

      • ORGANIZATION_NAME é o nome da organização.
      • ENVIRONMENT_NAME é o nome do ambiente;
      • KEYSTORE_NAME é o nome do keystore.
      • CERT_NAME é o nome do certificado.
      • $TOKEN é definida como seu token de acesso OAuth 2.0, conforme descrito em Receber um token de acesso do OAuth 2.0
      • As opções de curl usadas neste exemplo estão descritas em Usar curl

      Exemplo de saída

      Os detalhes de serverCert mostram o assunto e o emissor da seguinte forma:

      Certificado de entidade/folha:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      Certificado intermediário:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

4. Verifique se o certificado do servidor real obtido na etapa 1 e o certificado armazenados no truststore obtidos na correspondência da etapa 3. Se eles não forem correspondentes, causa do problema.

   No exemplo acima, vamos analisar um certificado de cada vez:

   1. Certificado de folha:

      No servidor de back-end:

      s:/CN=mocktarget.apigee.net
      i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      

      No truststore do processador de mensagens (cliente):

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      O certificado de folha armazenado no truststore corresponde ao do back-end servidor.

   2. Certificado intermediário:

      No servidor de back-end:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      No truststore do processador de mensagens (cliente):

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

      O certificado intermediário armazenado no truststore corresponde ao do servidor de back-end.

   3. Certificado raiz:

      No servidor de back-end:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      O certificado raiz está completamente ausente no arquivo o truststore.

   4. Como o certificado raiz está ausente no truststore, o O processador de mensagens gera a seguinte exceção:

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
      

      e retorna 503 Service Unavailable com o código do erro. messaging.adaptors.http.flow.SslHandshakeFailed, para o cliente aplicativos conteinerizados.

FQDN correto

Atualize o keystore do servidor de back-end com um FQDN correto, um certificado válido e completo rede:

1. Se você não tiver um certificado de servidor de back-end com o FQDN correto, Em seguida, consiga o certificado adequado de uma autoridade de certificação (CA, na sigla em inglês) apropriada.

2. Confirme se você tem cadeia de certificados do servidor de back-end completa e válida.

3. Quando você tiver uma cadeia de certificados completa e válida com o FQDN correto do servidor de back-end na folha ou certificado de entidade idêntico ao nome do host especificado no endpoint de destino, atualize o keystore do back-end com o cadeia de certificados completa.

Servidor de back-end correto

Atualize o endpoint de destino com o nome de host do servidor de back-end correto:

1. Se o nome do host tiver sido especificado incorretamente no endpoint de destino, atualize o endpoint de destino para ter o nome de host correto que corresponde ao FQDN no back-end do servidor de aplicativos da Web.

2. Salve as alterações no proxy de API.

   No exemplo discutido acima, se o nome do host do servidor de back-end estiver incorreto especificado, é possível corrigi-lo usando o FQDN do certificado do servidor de back-end que é backend.apigee.net desta maneira:

   <TargetEndpoint name="default">
      …
      <HTTPTargetConnection>
         <Properties />
         <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
         </SSLInfo>
         <URL>https://backend.apigee.net/resource</URL>
      </HTTPTargetConnection>
   </TargetEndpoint>