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

API Monitoring

1. Prosedür: API İzleme'yi kullanma

API İzleme'yi kullanarak hatayı teşhis etmek için:

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

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

   
3. Analyze > API Monitoring > Investigate (Analiz > API İzleme > İnceleme) sayfasına gidin.
4. Hataları gözlemlediğiniz belirli zaman aralığını seçin.

5. Hata Kodunu Zaman ile karşılaştırın.

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

   ( daha büyük resmi görüntüle)

   

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

   ( daha büyük resmi görüntüle)

   

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

   ( daha büyük resmi görüntüle)

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

Trace

2. Prosedür: Trace aracını kullanma

İzleme aracını kullanarak hatayı teşhis etmek için:

1. İzleme oturumunu etkinleştirin ve şunlardan birini yapın:
   • 503 Service Unavailable hata kodlu messaging.adaptors.http.flow.SslHandshakeFailed 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'in etkinleştirildiğinden emin olun:

   
3. Başarısız olan isteklerden birini seçip izlemeyi inceleyin.
4. İzlemenin farklı aşamalarında gezinin ve hatanın nerede oluştuğunu bulun.

5. Hatayı genellikle aşağıdaki örnekte gösterildiği gibi Target Request Flow Started aşamasından sonra görürsünüz:

   ( daha büyük resmi görüntüle)

   
6. İzleme işleminden 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 hata değeri, Apigee Edge'in mesaj işlemcisi arka uç sunucusunun sertifikasını doğrulayamadığı için SSL el sıkışmasının başarısız olduğunu gösterir.
7. İzleme işleminde AX (Analytics Verileri Kaydedildi) aşamasına gidin ve bu aşamayı tıklayın.

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

   ( daha büyük resmi görüntüle)

   
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. Özel bulut kullanıcısıysanız HTTP 503 Service Unavailable ile ilgili temel 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 503 hata koduyla messaging.adaptors.http.flow.SslHandshakeFailed hata olup olmadığını (sorun geçmişte yaşandıysa) veya 503 ile hâlâ başarısız olan istekler olup olmadığını arayın.

4. X-Apigee-fault-code değerinin messaging.adaptors.http.flow.SslHandshakeFailed değeriyle eşleştiği 503 hataları bulursanız X-Apigee-fault-source değerini belirleyin.

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

   ( daha büyük resmi görüntüle)

   

   NGINX erişim günlüğündeki yukarıdaki örnek girişte, X-Apigee-fault-code ve X-Apigee-fault-source için aşağıdaki değerler yer almaktadır:

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

Mesaj işleyici günlükleri

4. İşlem: Mesaj İşleyici günlüklerini kullanma

1. Genel teşhis adımları bölümünde açıklandığı gibi API İzleme, Trace aracı veya NGINX Erişim Günlükleri'ni kullanarak başarısız olan isteklerden birinin ileti kimliğini belirleyin.

2. Mesaj İşleyici günlüğünde (/opt/apigee/var/log/edge-message-processor/logs/system.log) belirli istek ileti 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, ileti işlemcisi ile arka uç sunucusu arasında SSL el sıkışma işleminin başarısız olduğunu gösterir.

   Bunu, aşağıda gösterildiği gibi ayrıntılı yığın izleme (stack trace) içeren bir istisna izler:

   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 nedenleri:

   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 İşleyici arka uç sunucusunun sertifikasını doğrulayamadığı için SSL el sıkışmasının başarısız olduğunu gösterir.

1. Aşama

1. aşama: Arka uç sunucusunun sertifika zincirini belirleyin

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 Message Processor'ın güvenilir sertifika deposunda saklanan sertifikaları karşılaştırın

1. Arka uç sunucusunun sertifika zincirini belirleyin.
2. Aşağıdaki adımları kullanarak ileti işlemcisinin güvenli deposunda depolanan sertifikayı belirleyin:

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

      SSLInfo yapılandırmasındaki bir TargetEndpoint bölümüne bakalım:

      <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'dir.

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

      ( daha büyük resmi görüntüle)

      

   4. Yukarıdaki örnekte güvenli depo adı şöyledir:

      myCompanyTruststoreRef: myCompanyTruststore

3. Aşağıdaki API'leri kullanarak güvenli depoda (önceki adımda belirlenmiştir) depolanan sertifikaları alın:

   1. Bir anahtar deposu veya güven deposu için tüm sertifikaları alın. Bu API, belirli bir 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"
      

      Nerede:

      • 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 jetonunuza ayarlanır.
      • Bu örnekte kullanılan curl seçenekleri, curl kullanma başlıklı makalede açıklanmıştır.

      Örnek çıkış:

      Örnek güvenilir sertifika deposundaki myCompanyTruststore sertifikalar şunlardır:

      [
        "serverCert"
      ]

   2. Bir anahtar deposu veya güven deposundan belirli bir sertifikanın sertifika ayrıntılarını alın. 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"
      

      Nerede:

      • 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 jetonunuza ayarlanır.
      • Bu örnekte kullanılan curl seçenekleri, curl kullanma başlıklı makalede açıklanmıştır.

      Örnek Çıkış

      serverCert ayrıntılarında konu ve veren kuruluş aşağıdaki gibi gösterilir:

      Leaf/Entity Certificate:

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

      Ara 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ı ile 3. adımda alınan güvenli depoda saklanan sertifikanın eşleştiğini doğrulayın. Eşleşmiyorlarsa sorunun nedeni budur.

   Yukarıdaki örnekte gösterilen sertifikalara tek tek bakalım:

   1. Varlık sertifikası:

      Arka uç sunucusundan:

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

      İleti İşlemcisi'nin (istemci) güvenli deposundan:

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

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

   2. Ara sertifika:

      Arka uç sunucusundan:

      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 İşlemcisi'nin (istemci) güvenli 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 saklanan ara sertifika, arka uç sunucusunun sertifikasıyla eşleşiyor.

   3. Kök sertifika:

      Arka uç sunucusundan:

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

      Kök sertifika, Message Processor'ın güvenilir sertifika deposunda tamamen eksik.

   4. Kök sertifika güvenli depoda eksik olduğundan, Mesaj İşleyici aşağıdaki istisnayı oluşturur:

      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 döndürür.

Doğru FQDN

Arka uç sunucusunun anahtar deposunu doğru FQDN, geçerli ve eksiksiz sertifika zinciriyle güncelleyin:

1. Doğru FQDN'ye sahip bir arka uç sunucusu sertifikanız yoksa uygun bir CA'dan (sertifika yetkilisi) doğru sertifikayı edinin.

2. Geçerli ve eksiksiz bir arka uç sunucusu sertifika zincirine sahip olduğunuzu doğrulayın.

3. Yaprak veya tüzel kişi sertifikasında, hedef uç noktada belirtilen ana makine adıyla aynı olan arka uç sunucusunun doğru FQDN'siyle geçerli ve eksiksiz bir sertifika zincirine sahip olduğunuzda arka ucun anahtar deposunu eksiksiz 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ç noktada yanlış belirtilmişse hedef uç noktayı, arka uç sunucusunun sertifikasındaki FQDN ile eşleşen doğru ana makine adını içerecek şekilde güncelleyin.

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

   Yukarıda bahsedilen örnekte, arka uç sunucusu ana makine adı yanlış belirtilmişse arka uç sunucusunun sertifikasındaki FQDN'yi kullanarak bu sorunu düzeltebilirsiniz. Bu durumda, backend.apigee.net şu şekilde olur:

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