503 Hizmeti Kullanılamıyor - SSL El Sıkışma Hatası

API Monitoring

1. Prosedür: API Monitoring'i Kullanma

API Monitoring'i kullanarak hatayı teşhis etmek için:

1. Uygun role sahip bir kullanıcı olarak Apigee Edge kullanıcı arayüzünde oturum açın.

2. Sorunu incelemek istediğiniz kuruluşa geçin.

   
3. Analiz > API İzleme > Araştır sayfasına gidin.
4. Hataları gözlemlediğiniz belirli zaman aralığını seçin.

5. Hata Kodu'nu Zamana göre çizin.

6. Aşağıda gösterildiği gibi messaging.adaptors.http.flow.SslHandshakeFailed hata koduna sahip bir hücre seçin:

   ( büyük resmi göster)

   

7. messaging.adaptors.http.flow.SslHandshakeFailed hata kodu ile ilgili bilgi aşağıda gösterildiği gibi görüntülenir:

   ( büyük resmi göster)

   

8. Günlükleri görüntüle 'yi tıklayın ve başarısız isteğin satırını genişletin.

   ( büyük resmi göster)

   
9. Günlükler penceresinde aşağıdaki ayrıntıları dikkate alın:
   • İstek İletisi Kimliği
   • Durum Kodu: 503
   • Hata Kaynağı: target
   • Hata Kodu: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

2. Prosedür: İzleme aracını kullanma

Hatayı İzle aracını kullanarak teşhis etmek için:

1. İzleme oturumunu ve aşağıdakilerden birini etkinleştirin:
   • messaging.adaptors.http.flow.SslHandshakeFailed hata koduna sahip 503 Service Unavailable hatasının oluşmasını bekleyin veya
   • Sorunu yeniden oluşturabiliyorsanız sorunu yeniden oluşturmak için API çağrısı yapın 503 Service Unavailable

2. Tüm FlowInfo'ları göster seçeneğinin etkin olduğundan emin olun:

   
3. Başarısız isteklerden birini seçip izi inceleyin.
4. İzin farklı aşamaları arasında gezinin ve hatanın nerede gerçekleştiğini bulun.

5. Hatayı genellikle aşağıda gösterildiği gibi Hedef İstek Akışı Başlatıldı aşamasından sonra görürsünüz:

   ( büyük resmi göster)

   
6. İzdeki aşağıdaki değerleri not edin:
   • hata: 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
   • 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 hatasının değeri, Apigee Edge'in Mesaj İşleyicisi arka uç sunucusunun sertifikasını doğrulayamadığından SSL El Sıkışması'nın başarısız olduğunu gösterir.
7. İzdeki AX (Analytics Data Recorded) Aşamalı Sunumu'na gidin ve bunu tıklayın.

8. Aşama Ayrıntıları Hata Başlıkları bölümüne ilerleyin ve X-Apigee-fault-code, X-Apigee-fault-source ve X-Apigee-Message-ID değerlerini aşağıda gösterildiği gibi belirleyin:

   ( büyük resmi göster)

   
9. X-Apigee-fault-code, X-Apigee-fault-source ve X-Apigee-Message-ID değerlerini not edin:

Hata üstbilgileri	Değer
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

3. Prosedür: NGINX erişim günlüklerini kullanma

NGINX erişim günlüklerini kullanarak hatayı teşhis etmek için:

1. Private Cloud kullanıcısıysanız HTTP 503 Service Unavailable ile ilgili önemli bilgileri belirlemek için NGINX erişim günlüklerini kullanabilirsiniz.

2. NGINX erişim günlüklerini kontrol edin:

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

3. Belirli bir süre boyunca messaging.adaptors.http.flow.SslHandshakeFailed hata koduna sahip 503 hatası (sorun geçmişte gerçekleştiyse) veya 503 nedeniyle başarısız olmaya devam eden bir istek olup olmadığını görmek için arama yapın.

4. messaging.adaptors.http.flow.SslHandshakeFailed değeriyle eşleşen X-Apigee-fault-code ile eşleşen herhangi bir 503 hatası bulursanız X-Apigee-fault-source değerinin değerini belirleyin.

   NGINX erişim günlüğünden örnek 503 hatası:

   ( büyük resmi göster)

   

   NGINX erişim günlüğünden yukarıdaki örnek giriş, X-Apigee-fault-code ve X-Apigee-fault-code için aşağıdaki değerlere sahiptir:

   Üst bilgiler	Değer
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Mesaj İşleyici günlükleri

4. Prosedür: İleti İşleyici Günlüklerini Kullanma

1. Yaygın teşhis adımları bölümünde açıklandığı şekilde API İzleme, İzleme aracı veya NGINX Erişim Günlüklerini kullanarak başarısız isteklerden birinin mesaj kimliğini belirleyin.

2. Mesaj İşleyici günlüğünde (/opt/apigee/var/log/edge-message-processor/logs/system.log) ilgili istek mesajı kimliğini arayın. Aşağıdaki hatayı görebilirsiniz:

   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
   

   Yukarıdaki hata, Mesaj İşleyici ile arka uç sunucusu arasındaki SSL el sıkışmasının başarısız olduğunu gösterir.

   Bunun ardından, aşağıda gösterildiği gibi ayrıntılı yığın izleme (stack trace) ile ilgili bir istisna takip edilir:

   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>
     

   El sıkışma hatasının şunlardan kaynaklandığını unutmayın:

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

   Bu, Apigee Edge'in Mesaj İşleyicisi arka uç sunucusunun sertifikasını doğrulayamadığı için SSL El Sıkışmanın başarısız olduğunu gösterir.

1. Aşama

1. Aşama: Arka uç sunucusunun sertifika zincirini belirleme

Arka uç sunucusunun sertifika zincirini belirlemek için aşağıdaki yöntemlerden birini kullanın:

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

2. Aşama

2. Aşama: Arka uç sunucusunun sertifikası ile Mesaj İşleyen'in güven deposunda saklanan sertifikaları karşılaştırın

1. Arka uç sunucunun sertifika zincirini belirleyin.
2. Aşağıdaki adımları uygulayarak Mesaj İşleyen'in güven deposunda depolanan sertifikayı belirleyin:

   1. TargetEndpoint içindeki SSLInfo bölümündeki TrustStore öğesinden güven deposu referans adını alın.

      Bir TargetEndpoint yapılandırmasında örnek SSLInfo bölümünü inceleyelim:

      <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. Yukarıdaki örnekte TrustStore referans adı myCompanyTruststoreRef'dır.

   3. Edge kullanıcı arayüzünde Ortamlar > Referanslar'ı seçin. İlgili güven deposu referansı için Referans sütunundaki adı not edin. Bu, güven deposu adınız olacaktır.

      ( büyük resmi göster)

      

   4. Yukarıdaki örnekte güven deposu adı şu şekildedir:

      myCompanyTruststoreRef: myCompanyTruststore

3. Aşağıdaki API'leri kullanarak güven deposunda depolanan sertifikaları alın (bir önceki adımda belirtilmiştir):

   1. Anahtar deposu veya güven deposu için tüm sertifikaları alma. Bu API, belirli güven deposundaki tüm sertifikaları listeler.

      Herkese Açık Bulut kullanıcısı:

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

      Private Cloud kullanıcısı:

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

      Yer:

      • ORGANIZATION_NAME, kuruluşun adıdır
      • ENVIRONMENT_NAME ortamın adıdır.
      • KEYSTORE_NAME, anahtar deposunun adıdır
      • $TOKEN, OAuth 2.0 erişim jetonu alma bölümünde açıklandığı gibi OAuth 2.0 erişim jetonunuz olarak ayarlandı
      • Bu örnekte kullanılan curl seçenekleri Curl kullanma bölümünde açıklanmıştır.

      Örnek çıkış:

      myCompanyTruststore güven deposundaki sertifikalar şunlardır:

      [
        "serverCert"
      ]
      

   2. Bir Anahtar Deposu veya Truststore'dan belirli bir sertifikanın Sertifika Ayrıntılarını alma Bu API, belirli bir güven deposundaki belirli bir sertifika hakkındaki bilgileri döndürür.

      Herkese Açık Bulut kullanıcısı:

      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"
      

      Private Cloud kullanıcısı

      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"
      

      Yer:

      • ORGANIZATION_NAME, kuruluşun adıdır
      • ENVIRONMENT_NAME ortamın adıdır.
      • KEYSTORE_NAME, anahtar deposunun adıdır
      • CERT_NAME sertifikanın adıdır
      • $TOKEN, OAuth 2.0 erişim jetonu alma bölümünde açıklandığı gibi OAuth 2.0 erişim jetonunuz olarak ayarlandı
      • Bu örnekte kullanılan curl seçenekleri Curl kullanma bölümünde açıklanmıştır.

      Örnek Çıkış

      serverCert ayrıntılarında, konu ve kartı veren kuruluş şu şekilde gösterilir:

      Yaprak/Varlık Sertifikası:

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

      Orta Düzey Sertifika:

      "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. 1. adımda alınan gerçek sunucu sertifikasının ve 3. adımda alınan güven deposunda depolanan sertifikanın eşleştiğini doğrulayın. Eşleşmezlerse sorunun nedeni budur.

   Yukarıda gösterilen örnekten, aynı anda tek bir sertifikaya göz atalım:

   1. Yaprak sertifikası:

      Arka uç sunucudan:

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

      İleti İşleyici'nin (istemci) güven deposundan:

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

      Güven deposunda saklanan yaprak sertifikası, arka uç sunucusunun sertifikasıyla eşleşir.

   2. Orta düzey sertifika:

      Arka uç sunucudan:

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

      İleti İşleyici'nin (istemci) güven deposundan:

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

      Güven deposunda depolanan ara sertifika, arka uç sunucusunun sertifikasıyla eşleşir.

   3. Kök sertifika:

      Arka uç sunucudan:

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

      Mesaj İşleyici'nin güven deposunda kök sertifika tamamen eksiktir.

   4. Güven deposunda kök sertifika eksik olduğundan Mesaj İşleyici, aşağıdaki istisnayı uygular:

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

      ve istemci uygulamalarına messaging.adaptors.http.flow.SslHandshakeFailed hata koduyla 503 Service Unavailable değerini döndürür.

Doğru FQDN

Arka uç sunucunun anahtar deposunu doğru FQDN, geçerli ve eksiksiz sertifika zinciri ile güncelleyin:

1. Doğru FQDN'ye sahip bir arka uç sunucunuzun sertifikası yoksa uygun sertifikayı uygun bir CA'dan (Sertifika Yetkilisi) alın.

2. Arka uç sunucunuzun sertifika zincirinin geçerli ve eksiksiz olduğunu doğrulayın.

3. Hedef uç noktasında belirtilen ana makine adıyla aynı olan özellikte veya varlık sertifikasında arka uç sunucunun doğru FQDN'sine sahip geçerli ve eksiksiz sertifika zincirine sahip olduğunuzda, arka ucun anahtar deposunu tam sertifika zinciriyle güncelleyin.

Doğru arka uç sunucusu

Hedef uç noktayı, doğru arka uç sunucusunun ana makine adıyla güncelleyin:

1. Ana makine adı hedef uç noktasında yanlış belirtilmişse hedef uç noktayı, arka uç sunucusunun sertifikasındaki FQDN ile eşleşen doğru ana makine adına sahip olacak şekilde güncelleyin.

2. API proxy'sinde yapılan değişiklikleri kaydedin.

   Yukarıda açıklanan örnekte arka uç sunucusu ana makine adı yanlış belirtilmişse bu sorunu, arka uç sunucusunun sertifikasındaki FQDN'yi (backend.apigee.net) kullanarak düzeltebilirsiniz:

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