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

Apigee Edge belgelerini görüntülüyorsunuz.
. Git: Apigee X belgeleri.
bilgi

Belirti

İstemci uygulaması 503 Service Unavailable HTTP durum kodunu API yanıtı olarak messaging.adaptors.http.flow.SslHandshakeFailed hata kodu çağrısının en iyi yoludur.

Hata mesajı

İstemci uygulaması aşağıdaki yanıt kodunu alır:

HTTP/1.1 503 Service Unavailable

Ayrıca, aşağıdaki hata mesajını da görebilirsiniz:

{
   "fault":{
      "faultstring":"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",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.SslHandshakeFailed"
      }
   }
}

Olası nedenler

Hata koduyla birlikte 503 Service Unavailable durum kodunu alabilirsiniz SSL sırasındaki bir hata nedeniyle messaging.adaptors.http.flow.SslHandshakeFailed Apigee Edge'in Mesaj İşlemcisi ile arka uç sunucusu arasındaki el sıkışma işleminin neden. faultstring alanındaki hata mesajı genellikle bu hataya yol açmış olabilecek üst düzey olası bir nedendir.

faultstring içinde gözlemlenen hata mesajına bağlı olarak uygun teknikleri ifade eder. Bu başucu kitabında, sorun giderme faultstring içinde 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 mesajıyla karşılaşırsanız bu hatayı alabilirsiniz.

Bu hata, Apigee Edge'in Mesaj İşlemcisi ile SSL el sıkışma işlemi sırasında ortaya çıkar. arka uç sunucusuna gidin:

  • Apigee Edge'in Mesaj İşlemcisi'nin truststore'u varsa:
    • Arka uç sunucusunun tam sertifikasıyla eşleşmeyen bir sertifika zinciri içeriyor sertifika zinciri VEYA
    • Arka uç sunucusunun tam sertifika zincirini içermiyor
  • Arka uç sunucusu tarafından sunulan sertifika zinciri:
ziyaret edin.

Bu sorunun olası nedenleri aşağıda açıklanmıştır:

Neden Açıklama Şunun için geçerli sorun giderme talimatları:
İleti İşleyen'in güven deposunda yanlış/eksik sertifika veya sertifika zinciri Apigee Edge'in Mesaj İşlemcisi'nin güven deposunda depolanan sertifika ve/veya zinciri, arka uç sunucusunun sertifika zinciriyle eşleşmiyor veya arka uç sunucusunun tam sertifika zincirini içermiyor. Edge Özel ve Herkese Açık Bulut kullanıcıları
Arka uç sunucusunun sertifikasındaki FQDN ile hedef uç noktadaki ana makine adı eşleşmiyor Arka uç sunucusu tarafından sunulan sertifika, hedef uç noktasında belirtilen ana makine adıyla eşleşmeyen bir FQDN içeriyor. Edge Özel ve Herkese Açık Bulut kullanıcıları
Yanlış/eksik sertifika veya arka uç sunucusu tarafından sunulan sertifika zinciri Arka uç sunucusu tarafından sağlanan sertifika zinciri yanlış veya eksik. Edge Özel ve Herkese Açık Bulut kullanıcıları

Sık kullanılan teşhis adımları

Bu hatayı teşhis etmek için aşağıdaki araçlardan/tekniklerden birini kullanın:

API Monitoring

1. Prosedür: API İzlemeyi Kullanma

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

  1. Apigee Edge kullanıcı arayüzünde uygun role sahip olur.
  2. Sorunu incelemek istediğiniz kuruluşa geçin.

  3. Analiz > API İzleme > İnceleme sayfası.
  4. Hataları gözlemlediğiniz zaman aralığını seçin.
  5. Zaman ile Hata Kodu'nun grafiğini çizin.

  6. Hata kodunun bulunduğu bir hücre seçin Gösterildiği şekliyle messaging.adaptors.http.flow.SslHandshakeFailed aşağıda bulabilirsiniz:

    ( resmi büyüt)

  7. Hata koduyla ilgili bilgi messaging.adaptors.http.flow.SslHandshakeFailed gösteriliyor aşağıda gösterilmiştir:

    ( resmi büyüt)

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

    ( resmi büyüt)

  9. Günlükler penceresinde aşağıdaki ayrıntılara dikkat edin:
    • Mesaj Kimliği İste
    • Durum Kodu: 503
    • Hata Kaynağı: target
    • Hata Kodu: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

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

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

  1. İzleme oturumunu etkinleştirin ve
    • Hata kodu içeren 503 Service Unavailable hatasını bekleyin messaging.adaptors.http.flow.SslHandshakeFailed veya
    • Sorunu yeniden oluşturabiliyorsanız API çağrısını yaparak sorunu yeniden oluşturun 503 Service Unavailable.
  2. Show all FlowInfos (Tüm Akış Bilgilerini Göster) seçeneğinin etkin olduğundan emin olun:

  3. Başarısız isteklerden birini seçin ve izini inceleyin.
  4. İzlemenin farklı aşamaları arasında gezinin ve hatanın nerede oluştuğunu bulun.
  5. Hatayı genellikle Hedef İstek Akışı Başlatıldı aşamasından sonra görürsünüz aşağıdaki gibidir:

    ( resmi büyüt)

  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, SSL El Sıkışmasının başarısız olduğunu gösterir. bunun nedeni, Apigee Edge'in Mesaj İşlemcisinin arka uç sunucusunun sertifikası.
  7. İzlemedeki AX (Analytics Verilerinin Kaydedilen) Aşamasına gidin ve tıklayın.
  8. Aşama Ayrıntıları Hata Üstbilgileri bölümüne ilerleyin ve X-Apigee-fault-code ve X-Apigee-fault-source değerleri ve Aşağıda gösterildiği gibi X-Apigee-Message-ID:

    ( resmi büyüt)

  9. X-Apigee-fault-code, X-Apigee-fault-source değerlerini not edin. ve X-Apigee-Message-ID:
  10. Hata başlıkları 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 aşağıdakileri belirlemek için NGINX erişim günlüklerini kullanabilirsiniz: HTTP 503 Service Unavailable ile ilgili önemli bilgileri girin.
  2. NGINX erişim günlüklerini kontrol edin:

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

  3. Hata kodu içeren 503 hatası olup olmadığını görmek için arama yapın Belirli bir süre boyunca messaging.adaptors.http.flow.SslHandshakeFailed (sorun ) veya 503 ile hâlâ başarısız olan istekler varsa bunları kontrol edin.
  4. X-Apigee-fault-code eşleşmesinde 503 hatası bulursanız messaging.adaptors.http.flow.SslHandshakeFailed değerini, ardından X-Apigee-fault-source.'un değerini belirleyin.

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

    ( resmi büyüt)

    NGINX erişim günlüğünden alınan yukarıdaki örnek giriş, X-Apigee-fault-code ve X-Apigee-fault-source:

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

İleti işleyen günlükleri

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

  1. API Monitoring, İzleme aracını kullanarak başarısız isteklerden birinin ileti kimliğini belirleyin. veya NGINX Erişim Günlükleri'ni yaygın teşhis adımlarında açıklandığı şekilde tanımlar.
  2. Mesaj İşleyen günlüğünde belirli bir istek iletisi kimliğini arayın (/opt/apigee/var/log/edge-message-processor/logs/system.log). Şunları görebilirsiniz: şu hata oluştu:

    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, İleti İşleyen ile SSL anlaşmasının başarısız olduğunu gösterir. arka uç sunucusuna gidin.

    Bunun ardından aşağıda gösterildiği gibi ayrıntılı yığın izlemeyle ilgili bir istisna gelir:

    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 aşağıdaki nedenlerden 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 simge, Apigee Edge'in Mesaj İşleyicisi olarak SSL El Sıkışması'nın başarısız olduğunu gösterir. arka uç sunucusunun sertifikasını doğrulayamadı.

Neden: İleti İşleyen'in güven deposunda yanlış/eksik sertifika veya sertifika zinciri

Teşhis

  1. API kullanılarak gözlemlenen hatanın Hata Kodu ve Hata Kaynağı'nı belirleme Yaygın Uygulamalarda açıklandığı üzere İzleme, İzleme aracı veya NGINX erişim günlükleri adımları inceleyin.
  2. Hata Kodu messaging.adaptors.http.flow.SslHandshakeFailed ise Aşağıdaki yöntemlerden birini kullanarak hata mesajını belirleyin:
    • Aşağıdaki talimatları uygulayarak İzleme aracını kullanarak error.cause dosyasını bulun Yaygın teşhis adımları
    • İstisnayı, İleti İşlemci Günlüklerini kullanarak bulun: Yaygın teşhis adımları
    • Şurada görüldüğü gibi API çağrınıza verilen hata yanıtında faultstring bilgisini bulun Hata mesajı
  3. Hata mesajı sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target" ise bu, SSL El Sıkışması'nın mevcut olduğunu gösterir. başarısız oldu. Bunun nedeni, Apigee Edge'in Mesaj İşlemcisinin arka uç sunucusunun sertifikası.

Bu sorunu iki aşamada hata ayıklayabilirsiniz:

  1. 1. Aşama: Arka uç sunucusunun sertifika zincirini belirleme
  2. 2. Aşama: İleti İşleyen'in güven deposunda depolanan sertifika zincirini karşılaştırma

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

Arka uç sunucusunun ana makinesinde openssl komutunu yürütün şu şekilde ekleyin:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Yukarıdaki komutun çıkışındaki Sertifika zincirini not edin:

opensl komut çıkışından örnek arka uç sunucusu Sertifika zinciri:

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

tcpdump

  1. Herkese açık bulut kullanıcısıysanız arka uç sunucusuna gidin.
  2. Private Cloud kullanıcısıysanız TCP/IP arka uç sunucusuna veya Mesaj İşleyici'ye gönderebilirsiniz. Tercihen, bu videoları arka uç sunucusuna gönderilir.
  3. Şunları kullanın: tcpdump komutunu girin:

    tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
    
    .
  4. TCP/IP paketlerini Wireshark aracı veya aşina olduğunuz benzer bir araçtır.

    Tcpdump Örnek Analizi

    ( resmi büyüt)

    • Packet 43: İleti İşleyen (Kaynak) bir Client Hello mesajını arka uç sunucuya gönderir (Hedef).
    • Paket 44: Arka uç sunucusu İleti İşleyen'den Client Hello ileti.
    • Paket 45: Arka uç sunucusu, Server Hello değerini gönderir mesajıyla birlikte gönderilir.
    • Packet #46: Mesajı İşleyen, Server Hello mesajı ve sertifika.
    • 47. Paket: İleti İşleyen, bir FIN, ACK gönderir mesajı ve ardından 48 numaralı pakette RST, ACK şeklindedir.

      Bu, web sunucusu tarafından sağlanan arka uç sunucu sertifikasının İleti İşleyici başarısız oldu. Bunun nedeni, İletiyi İşleyen’in arka uç sunucusunun sertifikasıyla eşleşen veya güvenemeyen herhangi bir sertifika arka uç sunucusunun sertifikasını, (İleti İşleyici'nin) güven deposu.

    • Geri dönüp 45 numaralı paket'i inceleyerek sertifikayı arka uç sunucusu tarafından gönderilen zincir

      ( resmi büyüt)

    • Bu örnekte, sunucunun bir yaprak sertifikası gönderdiğini görebilirsiniz. common name (CN) = mocktarget.apigee.net ve ardından bir CN= GTS CA 1D4 ve kök sertifika içeren ara sertifika CN = GTX Root R1 ile.

    Sunucunun sertifika doğrulamasının başarısız olduğundan eminseniz 2. Aşama: Arka uç sunucusunun sertifikasını karşılaştırabilirsiniz. güven deposunda depolanan sertifikaları ve sertifikaları kontrol eder.

2. Aşama

2. Aşama: Arka uç sunucusunun sertifikasını ve Mesaj İşleyici'nin güven deposu

  1. Arka uç sunucusunun sertifika zincirini belirleyin.
  2. İleti İşleyici’nin güven deposunda saklanan sertifikayı belirlemek için şu adımları uygulayın:
    1. TrustStore öğesinden güven deposu referans adını alın (TargetEndpoint etiketinin SSLInfo bölümüne bakın).

      TargetEndpoint öğesindeki örnek SSLInfo bölümüne göz atalım yapılandırma:

      <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.
    3. Edge kullanıcı arayüzünde Ortamlar > Referanslar. Dosyadaki adı not edin Belirli Trustedstore referansı için Referans sütunu. Bu, güven deposu adı.

      ( resmi büyüt)

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

      myCompanyTruststoreRef: myCompanyTruststore

  3. Truststore'da depolanan sertifikaları al (önceki adımda belirlenir) kullanın:

    1. Bir anahtar deposu veya güven deposu için tüm sertifikaları alın. Bu API, işletmenizin sertifikalarınız da var.

      Herkese açık Cloud 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 jetonunuz olarak şu şekilde ayarlanmıştır: OAuth 2.0 erişim jetonu alma
      • Bu örnekte kullanılan curl seçenek başlıklı konuda açıklanmaktadır. Curl kullanma

      Örnek çıkış:

      myCompanyTruststore örneği güven deposundaki sertifikalar şunlardır:

      [
        "serverCert"
      ]
      

    2. Bir Anahtar Deposu veya Truststore'dan belirli bir sertifikanın Sertifika Ayrıntılarını alın. Bu API, API'deki belirli bir sertifikadaki belirli bir sertifikanın güven deposu.

      Herkese açık Cloud 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 jetonunuz olarak şu şekilde ayarlanmıştır: OAuth 2.0 erişim jetonu alma
      • Bu örnekte kullanılan curl seçenek başlıklı konuda açıklanmaktadır. Curl kullanma

      Örnek Çıkış

      serverCert ayrıntılarında, konu ve kartı veren aşağıdaki şekilde gösterilmektedir:

      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 elde edilen gerçek sunucu sertifikasının ve sertifikanın 3. adımdaki eşleşmede bulunan güven deposunda saklanır. Bunlar eşleşmezse bir neden sunmalısınız.

    Yukarıda gösterilen örnekten her seferinde tek bir sertifikaya bakalım:

    1. Yaprak sertifikası:

      Arka uç sunucusundan:

      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",
      

      Truststore'da depolanan yaprak sertifikası, arka ucun sertifikasıyla eşleşir sunucu.

    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 İş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",
      

      Truststore'da depolanan ara sertifika, arka uç sunucusuna gidin.

    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, İleti İşleyen'in güven deposu.

    4. Truststore'da kök sertifika eksik olduğundan, İleti İşleyici şu istisnayı devreye sokar:

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

      ve hata koduyla 503 Service Unavailable değerini döndürür Müşteri için messaging.adaptors.http.flow.SslHandshakeFailed izin verir.

ziyaret edin.

Çözünürlük

  1. Arka uç sunucusunun uygun ve eksiksiz sertifika zincirine sahip olduğunuzdan emin olun.
  2. Herkese açık Cloud kullanıcısıysanız şu makaledeki talimatları uygulayın: Cloud için TLS sertifikasını güncelleyerek bu sertifikayı Apigee Edge'in İleti İşleyici güven deposu.
  3. Private Cloud kullanıcısıysanız şu sayfadaki talimatları uygulayın: Private Cloud için TLS sertifikasını güncelleyerek sertifikayı şu şekilde güncelleyin: Apigee Edge'in Mesaj İşlemci güven deposu.

Neden: Arka uç sunucusunun sertifikasındaki FQDN ile hedef uç noktadaki ana makine adı eşleşmiyor

Arka uç sunucusu, FQDN içeren ve hedef uç noktalarda belirtilen ana makine adını işaretlerseniz, Apigee Edge'in Mesaj İşlemi hatası 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

Teşhis

  1. Gözlemlediğiniz bu hedef uç noktasını API proxy'sinde inceleyin hatasını alın ve arka uç sunucusunun ana makine adını not edin:

    Örnek Hedef Uç Noktası:

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

    Yukarıdaki örnekte, arka uç sunucusunun ana makine adı backend.company.com şeklindedir.

  2. openssl kullanarak arka uç sunucusunun sertifikasındaki FQDN'yi belirleyin komutunu çalıştırın:

    openssl s_client -connect BACKEND_SERVER_HOST_NAME>:PORT_#>
    

    Örneğin:

    openssl s_client -connect backend.company.com:443
    

    Certificate chain bölümünü inceleyin ve şu şekilde belirtilen FQDN değerine dikkat edin: bir kısmı CN'ye eklenecek.

    Certificate chain
     0 s:/CN=backend.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
    

    Yukarıdaki örnekte, arka uç sunucusunun FQDN'si backend.apigee.net şeklindedir.

  3. 1. adımdan ve FQDN'den alınan arka uç sunucusunun ana makine adı uyuşmuyorsa hatanın nedeni budur.
  4. Yukarıda açıklanan örnekte, hedef uç noktadaki ana makine adı backend.company.com Ancak arka uç sunucusunun sertifikasındaki FQDN adı backend.apigee.net. Eşleşmiyorlarsa bu hatayı alırsınız.

Çözünürlük

Aşağıdaki yöntemlerden birini kullanarak bu sorunu düzeltebilirsiniz:

Doğru FQDN

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

  1. Doğru FQDN'ye sahip bir arka uç sunucusunun sertifikası yoksa uygun CA'dan (Sertifika Yetkilisi) uygun sertifikayı alın.
  2. arka uç sunucusunun sertifika zincirinin geçerli ve eksiksiz olmasını sağlayın.

  3. Sertifika zincirinin doğru FQDN'sini içeren geçerli ve eksiksiz sertifika zincirine sahip olduğunuzda, yaprak veya varlık sertifikasında, ana makine adıyla aynı olan arka uç sunucusu belirtilenden sonra, arka ucun anahtar deposunu tam sertifika zincirine sahip.
ziyaret edin.

Doğru arka uç sunucusu

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

  1. Ana makine adı, hedef uç noktasında yanlış belirtildiyse hedef uç noktasının arka uçtaki FQDN ile eşleşen doğru ana makine adına sahip olmasını sağlayın sunucu sertifikası.
  2. API proxy'sinde yapılan değişiklikleri kaydedin.

    Yukarıda açıklanan örnekte, arka uç sunucu ana makine adı yanlışsa arka uç sunucusunun sertifikasındaki FQDN'yi kullanarak sorunu düzeltebilirsiniz. Bu backend.apigee.net şu şekildedir:

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

Neden: Arka uç sunucusu tarafından sağlanan yanlış/eksik sertifika veya sertifika zinciri

Teşhis

  1. openssl komutunu çalıştırarak arka uç sunucusunun sertifika zincirini alın ana makine adına göre aşağıdaki şekilde değiştirin:
    openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#
    

    Yukarıdaki komutun çıkışındaki Certificate chain değerini not edin.

    opensl komut çıkışından örnek arka uç sunucusu Sertifika Zinciri:

    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. Aşağıdaki sayfada açıklandığı gibi, doğru ve eksiksiz sertifika zincirine sahip olduğunuzu doğrulayın Sertifika zinciri doğrulanıyor.
  3. Arka uç sunucusu için geçerli ve eksiksiz sertifika zincirine sahip değilseniz Bu sorunun nedeni budur.

    Yukarıda gösterilen örnek arka uç sunucusunun sertifika zincirinde kök sertifika eksik. Bu nedenle bu hatayı alırsınız.

Çözünürlük

Arka uç sunucusunun anahtar deposunu geçerli ve tam bir sertifika zinciriyle güncelleyin:

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

  2. Arka uç sunucusunun anahtar deposunda geçerli ve eksiksiz sertifika zincirini güncelleyin.
ziyaret edin.

Sorun devam ederse adresine gidin. Teşhis bilgileri toplanmalıdır.

Teşhis bilgileri toplanmalıdır

Yukarıdaki talimatları uygulamanıza rağmen sorun devam ederse aşağıdaki Apigee Edge Destek Ekibi ile iletişime geçin:

  • Herkese açık Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
    • Kuruluş adı
    • Ortam adı
    • API Proxy adı
    • Hatayı yeniden oluşturmak için curl komutunu tamamlayın
    • Hatayı gösteren izleme dosyası
    • openssl komutunun çıktısı:

      openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#

    • Arka uç sunucusunda yakalanan TCP/IP paketleri
  • Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
    • Tam hata mesajı görüntülendi
    • API proxy paketi
    • Hatayı gösteren izleme dosyası
    • Mesaj İşleyici günlükleri /opt/apigee/var/log/edge-message-processor/logs/system.log
    • openssl komutunun çıktısı:
      openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#
    • Arka uç sunucusunda veya Mesaj İşleyicide yakalanan TCP/IP paketleri.
    • Çıktı Bir anahtar deposu veya güven deposu API'si için tüm sertifikaları ve ayrıca kullanılan her sertifika Bir Anahtar Deposu veya Truststore API'sinden Sertifika Ayrıntılarını alın.

Referanslar