TLS/SSL El Sıkışma Hataları

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi

Belirti

Bir istemci ve sunucu, TLS/SSL protokolünü kullanarak iletişim kuramadığında TLS/SSL el sıkışması hatası oluşur. Bu hata Apigee Edge'de oluştuğunda istemci uygulaması, Service Unavailable (Hizmet Kullanılamıyor) mesajıyla birlikte bir HTTP durumu 503 alır. Bu hatayı, TLS/SSL el sıkışma hatasının oluştuğu herhangi bir API çağrısından sonra görürsünüz.

Hata mesajları

HTTP/1.1 503 Service Unavailable

TLS/SSL el sıkışması hatası oluştuğunda da bu hata mesajını görebilirsiniz:

Received fatal alert: handshake_failure

Olası nedenler

TLS (Taşıma Katmanı Güvenliği, SSL'nin halefidir), bir web sunucusu ile tarayıcı veya uygulama gibi bir web istemcisi arasında şifrelenmiş bir bağlantı oluşturmaya yönelik standart güvenlik teknolojisidir. El sıkışma, TLS/SSL istemcisinin ve sunucusunun iletişim kurabilecekleri bir dizi gizli anahtar oluşturmasını sağlayan bir işlemdir. Bu işlem sırasında istemci ve sunucu:

1. Kullanılacak protokol sürümü üzerinde anlaşın.
2. Kullanılacak kriptografik algoritmayı seçin.
3. Dijital sertifikaları değiştirip doğrulayarak birbirlerinin kimliğini doğrulayın.

TLS/SSL el sıkışması başarılı olursa TLS/SSL istemcisi ve sunucusu birbirine güvenli bir şekilde veri aktarır. Aksi takdirde, TLS/SSL el sıkışma hatası oluşursa bağlantı sonlandırılır ve istemci 503 Service Unavailable hatası alır.

TLS/SSL el sıkışma hatalarının olası nedenleri şunlardır:

Protokol Uyuşmazlığı

İstemci tarafından kullanılan protokol, gelen (kuzeye doğru) veya giden (güneye doğru) bağlantıda sunucu tarafından desteklenmiyorsa TLS/SSL el sıkışması hatası oluşur. Ayrıca Kuzey ve güney yönlü bağlantıları anlama başlıklı makaleye de bakın.

Teşhis

1. Hatanın kuzeye veya güneye giden bağlantıda mı oluştuğunu belirleyin. Bu belirlemeyi yapma konusunda daha fazla bilgi için Sorunun kaynağını belirleme başlıklı makaleyi inceleyin.
2. Daha fazla bilgi toplamak için tcpdump yardımcı programını çalıştırın:
   • Özel bulut kullanıcısıysanız ilgili istemcide veya sunucuda tcpdump verilerini toplayabilirsiniz. İstemci, istemci uygulaması (gelen veya kuzeye doğru bağlantılar için) ya da ileti işlemcisi (giden veya güneye doğru bağlantılar için) olabilir. Sunucu, 1. adımda belirlediğinize bağlı olarak Edge yönlendirici (gelen veya kuzeye doğru bağlantılar için) ya da arka uç sunucusu (giden veya güneye doğru bağlantılar için) olabilir.
   • Herkese açık bulut kullanıcısıysanız, Edge Router veya Mesaj İşleyici'ye erişiminiz olmadığından tcpdump verileri yalnızca istemci uygulamasında (gelen veya kuzeye doğru bağlantılar için) ya da arka uç sunucusunda (giden veya güneye doğru bağlantılar için) toplayabilirsiniz.

   tcpdump -i any -s 0 host IP address -w File name
   

   tcpdump komutunu kullanma hakkında daha fazla bilgi için tcpdump verilerine bakın.
3. tcpdump verilerini Wireshark aracını veya benzer bir aracı kullanarak analiz edin.
4. Wireshark kullanılarak tcpdump ile ilgili örnek bir analiz aşağıda verilmiştir:
   • Bu örnekte, TLS/SSL el sıkışma hatası, Mesaj İşleyici ile arka uç sunucusu (giden veya güney yönlü bağlantı) arasında meydana geldi.
   • Aşağıdaki tcpdump çıkışındaki 4 numaralı mesaj, Mesaj İşleyici'nin (Kaynak) arka uç sunucusuna (Hedef) bir "Client Hello" mesajı gönderdiğini gösteriyor.
     

     

   • Client Hello mesajını seçerseniz aşağıdaki örnekte gösterildiği gibi, Mesaj İşleyici'nin TLSv1.2 protokolünü kullandığı gösterilir:

     

   • 5 numaralı mesaj, arka uç sunucusunun Mesaj İşleyici'den gelen "Client Hello" mesajını onayladığını gösterir.
   • Arka uç sunucusu, Fatal Alert : Close Notify mesajını hemen Mesaj İşleyici'ye (6 numaralı ileti) gönderir. Bu, TLS/SSL el sıkışma işleminin başarısız olduğu ve bağlantının kapatılacağı anlamına gelir.

   • 6 numaralı ileti daha ayrıntılı olarak incelendiğinde TLS/SSL el sıkışma hatasının nedeninin, arka uç sunucusunun yalnızca TLSv1.0 protokolünü desteklediği anlaşılıyor.

     

   • Mesaj İşleyici tarafından kullanılan protokol ile arka uç sunucusu arasında uyuşmazlık olduğundan arka uç sunucusu şu iletiyi gönderdi: Fatal Alert Message: Close Notify.

Çözünürlük

Mesaj İşleyici, Java 8'de çalışır ve varsayılan olarak TLSv1.2 protokolünü kullanır. Arka uç sunucusu TLSv1.2 protokolünü desteklemiyorsa bu sorunu çözmek için aşağıdaki adımlardan birini uygulayabilirsiniz:

1. Arka uç sunucunuzu TLSv1.2 protokolünü destekleyecek şekilde yükseltin. TLSv1.2 protokolü daha güvenli olduğundan bu çözüm önerilir.
2. Arka uç sunucunuzu herhangi bir nedenle hemen yükseltemiyorsanız aşağıdaki adımları uygulayarak ileti işlemcisinin arka uç sunucuyla iletişim kurmak için TLSv1.0 protokolünü kullanmasını zorunlu kılabilirsiniz:
   1. Proxy'nin TargetEndpoint tanımında hedef sunucu belirtmediyseniz aşağıdaki örnekte gösterildiği gibi Protocol öğesini TLSv1.0 olarak ayarlayın:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. Proxy'niz için bir hedef sunucu yapılandırdıysanız protokolü belirli hedef sunucu yapılandırmasında TLSv1.0 olarak ayarlamak için bu yönetim API'sini kullanın.

Şifre Uyuşmazlığı

İstemci tarafından kullanılan şifre paketi algoritması, Apigee Edge'deki gelen (kuzeye doğru) veya giden (güneye doğru) bağlantıda sunucu tarafından desteklenmiyorsa TLS/SSL el sıkışma hatası görebilirsiniz. Ayrıca Kuzey ve güney yönlü bağlantıları anlama başlıklı makaleye de bakın.

Teşhis

1. Hatanın kuzeye veya güneye giden bağlantıda mı oluştuğunu belirleyin. Bu belirlemeyi yapma konusunda daha fazla bilgi için Sorunun kaynağını belirleme başlıklı makaleyi inceleyin.
2. Daha fazla bilgi toplamak için tcpdump yardımcı programını çalıştırın:
   • Özel bulut kullanıcısıysanız ilgili istemcide veya sunucuda tcpdump verilerini toplayabilirsiniz. İstemci, istemci uygulaması (gelen veya kuzeye doğru bağlantılar için) ya da ileti işlemcisi (giden veya güneye doğru bağlantılar için) olabilir. Sunucu, 1. adımda belirlediğinize bağlı olarak Edge yönlendirici (gelen veya kuzeye doğru bağlantılar için) ya da arka uç sunucusu (giden veya güneye doğru bağlantılar için) olabilir.
   • Herkese açık bulut kullanıcısıysanız, Edge Router veya Mesaj İşleyici'ye erişiminiz olmadığından tcpdump verileri yalnızca istemci uygulamasında (gelen veya kuzeye doğru bağlantılar için) ya da arka uç sunucusunda (giden veya güneye doğru bağlantılar için) toplayabilirsiniz.

   tcpdump -i any -s 0 host IP address -w File name
   

   tcpdump komutunu kullanma hakkında daha fazla bilgi için tcpdump verilerine bakın.
3. tcpdump verilerini Wireshark aracını veya bildiğiniz başka bir aracı kullanarak analiz edin.
4. Wireshark kullanılarak tcpdump çıkışının örnek analizini aşağıda bulabilirsiniz:
   • Bu örnekte, TLS/SSL el sıkışma hatası istemci uygulaması ile Edge yönlendirici (kuzeye doğru bağlantı) arasında meydana geldi. tcpdump çıkışı, Edge yönlendiricide toplandı.

   • Aşağıdaki tcpdump çıkışındaki 4 numaralı mesaj, istemci uygulamasının (kaynak) Edge yönlendiriciye (hedef) bir "Client Hello" mesajı gönderdiğini gösteriyor.

     

   • Client Hello mesajı seçildiğinde istemci uygulamasının TLSv1.2 protokolünü kullandığı gösterilir.

     

   • 5 numaralı mesaj, Edge yönlendiricinin istemci uygulamasından gelen "Client Hello" mesajını onayladığını gösterir.
   • Edge yönlendirici, istemci uygulamasına hemen bir Fatal Alert : Handshake Failure (Önemli Uyarı: El Sıkışma Hatası) gönderir (6 numaralı ileti). Bu, TLS/SSL el sıkışma işleminin başarısız olduğu ve bağlantının kapatılacağı anlamına gelir.
   • 6 numaralı ileti daha ayrıntılı olarak incelendiğinde aşağıdaki bilgiler gösterilir:
     • Edge yönlendirici, TLSv1.2 protokolünü destekler. Bu, istemci uygulaması ile Edge Router arasındaki protokolün eşleştiği anlamına gelir.

     • Ancak Edge yönlendirici, aşağıdaki ekran görüntüsünde gösterildiği gibi istemci uygulamasına Fatal Alert: Handshake Failure (Önemli Uyarı: El Sıkışma Hatası) mesajını göndermeye devam eder:

       

   • Bu hata, aşağıdaki sorunlardan birinin sonucu olabilir:
     • İstemci uygulaması, Edge yönlendirici tarafından desteklenen şifre paketi algoritmalarını kullanmıyor.
     • Edge yönlendirici SNI özellikli ancak istemci uygulaması sunucu adını göndermiyor.
   • tcpdump çıkışındaki 4. mesajda, istemci uygulaması tarafından desteklenen şifre paketi algoritmaları aşağıdaki gibi listelenir:

     

   • Edge yönlendirici tarafından desteklenen şifre paketi algoritmalarının listesi /opt/nginx/conf.d/0-default.conf dosyasında yer alır. Bu örnekte, Edge Router yalnızca Yüksek Şifreleme şifre paketi algoritmalarını desteklemektedir.
   • İstemci uygulaması, Yüksek Şifreleme şifreleme paketi algoritmalarından hiçbirini kullanmıyor. Bu uyuşmazlık, TLS/SSL el sıkışma hatasının nedenidir.
   • Edge yönlendirici SNI özellikli olduğundan tcpdump çıktısında 4. mesaja gidin ve istemci uygulamasının, aşağıdaki şekilde gösterildiği gibi sunucu adını doğru şekilde gönderdiğini doğrulayın:
     
     
     
   • Bu ad geçerliyse istemci uygulaması tarafından kullanılan şifreleme paketi algoritmaları Edge yönlendirici tarafından desteklenmediği için TLS/SSL el sıkışma hatasının oluştuğunu anlayabilirsiniz.

Çözünürlük

İstemcinin, sunucu tarafından desteklenen şifre paketi algoritmalarını kullandığından emin olmanız gerekir. Önceki Teşhis bölümünde açıklanan sorunu çözmek için Java Cryptography Extension (JCE) paketini indirip yükleyin ve Yüksek Şifreleme şifreleme paketi algoritmalarını desteklemek üzere Java kurulumuna dahil edin.

Yanlış Sertifika

Apigee Edge'deki gelen (kuzeye doğru) veya giden (güneye doğru) bağlantıda anahtar deposunda/güven deposunda yanlış sertifikalar varsa TLS/SSL el sıkışması hatası oluşur. Ayrıca Kuzey ve güney yönlü bağlantıları anlama başlıklı makaleye de bakın.

Sorun kuzeye doğru ise temel nedene bağlı olarak farklı hata mesajları görebilirsiniz.

Aşağıdaki bölümlerde örnek hata mesajları ve bu sorunu teşhis edip çözmek için gereken adımlar listelenmektedir.

Hata mesajları

TLS/SSL el sıkışma hatasının nedenine bağlı olarak farklı hata mesajları görebilirsiniz. Bir API proxy'sini çağırdığınızda görebileceğiniz örnek bir hata mesajı aşağıda verilmiştir:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

Olası nedenler

Bu sorunun tipik nedenleri şunlardır:

Ana makine adı uyuşmazlığı

Teşhis

1. Aşağıdaki Edge Management API çağrısı tarafından döndürülen URL'de kullanılan ana makine adını not edin:

   curl -v https://myorg.domain.com/v1/getinfo

   Örneğin:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. Belirli bir anahtar deposunda saklanan sertifikada kullanılan CN'yi alın. Sertifika ayrıntılarını almak için aşağıdaki Edge yönetim API'lerini kullanabilirsiniz:
   1. Anahtar deposundaki sertifika adını alma:
      
      Özel Cloud kullanıcısıysanız Management API'sini aşağıdaki gibi kullanın:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      Herkese açık bulut kullanıcısıysanız Management API'sini aşağıdaki gibi kullanın:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Edge Management API'yi kullanarak anahtar deposundaki sertifikanın ayrıntılarını alın.
      
      Private Cloud kullanıcısıysanız:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Herkese açık bulut kullanıcısıysanız:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Örnek sertifika::

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },

      Birincil sertifikadaki konu adı, CN olarak something.domain.com. içeriyor.

      API isteği URL'sinde kullanılan barındırıcı adı (yukarıdaki 1. adıma bakın) ile sertifikadaki konu adı eşleşmediği için TLS/SSL el sıkışması başarısız olur.

Çözünürlük

Bu sorun aşağıdaki iki yöntemden biriyle çözülebilir:

• Konu CN'sinin joker karakterli sertifikaya sahip olduğu bir sertifika edinin (henüz yoksa), ardından yeni tam sertifika zincirini anahtar deposuna yükleyin. Örneğin:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• Mevcut bir konu CN'si olan bir sertifika edinin (henüz yoksa) ancak your-org kullanın.your-domain olarak ekleyin ve ardından anahtar deposuna tam sertifika zincirini yükleyin.

Referanslar

Anahtar depoları ve güven depoları

Eksik veya yanlış sertifika zinciri

Teşhis

1. Belirli bir anahtar deposunda saklanan sertifikada kullanılan CN'yi alın. Sertifika ayrıntılarını almak için aşağıdaki Edge yönetim API'lerini kullanabilirsiniz:
   1. Anahtar deposundaki sertifika adını alma:
      
      Private Cloud kullanıcısıysanız:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      Herkese açık bulut kullanıcısıysanız:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Anahtar deposundaki sertifikanın ayrıntılarını alma:
      
      Private Cloud kullanıcısıysanız:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Herkese açık bulut kullanıcısıysanız:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. Geçerli ve eksiksiz bir sertifika zinciri olduğundan emin olmak için sertifikayı ve zincirini doğrulayın ve Sertifika zincirleri nasıl çalışır? başlıklı makalede belirtilen yönergelere uyduğunu doğrulayın. Sertifika zincirleri nasıl çalışır? Anahtar deposunda depolanan sertifika zinciri eksik veya geçersizse TLS/SSL el sıkışması hatası gösterilir.
   4. Aşağıdaki grafikte, ara ve kök sertifikaların eşleşmediği, geçersiz bir sertifika zincirine sahip örnek bir sertifika gösterilmektedir:

   Veren ve konu eşleşmediğinde ara ve kök sertifika örneği

   
   

Çözünürlük

1. Tam ve geçerli bir sertifika zinciri içeren bir sertifika edinin (henüz yoksa).
2. Sertifika zincirinin doğru ve eksiksiz olduğunu doğrulamak için aşağıdaki openssl komutunu çalıştırın:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. Doğrulanmış sertifika zincirini anahtar deposuna yükleyin.

Sunucu veya istemci tarafından gönderilen süresi dolmuş ya da bilinmeyen sertifika

Kuzeye veya güneye giden bağlantıda sunucu/istemci tarafından yanlış/süresi dolmuş bir sertifika gönderilirse diğer uç (sunucu/istemci) sertifikayı reddeder ve bu durum TLS/SSL el sıkışma hatasına yol açar.

Teşhis

1. Hatanın kuzeye veya güneye giden bağlantıda mı oluştuğunu belirleyin. Bu belirlemeyi yapma hakkında daha fazla bilgi için Sorunun kaynağını belirleme başlıklı makaleyi inceleyin.
2. Daha fazla bilgi toplamak için tcpdump yardımcı programını çalıştırın:
   • Özel bulut kullanıcısıysanız ilgili istemcide veya sunucuda tcpdump verilerini toplayabilirsiniz. İstemci, istemci uygulaması (gelen veya kuzeye doğru bağlantılar için) ya da ileti işlemcisi (giden veya güneye doğru bağlantılar için) olabilir. Sunucu, 1. adımda belirlediğinize bağlı olarak Edge yönlendirici (gelen veya kuzeye doğru bağlantılar için) ya da arka uç sunucusu (giden veya güneye doğru bağlantılar için) olabilir.
   • Herkese açık bulut kullanıcısıysanız, Edge Router veya Mesaj İşleyici'ye erişiminiz olmadığından tcpdump verileri yalnızca istemci uygulamasında (gelen veya kuzeye doğru bağlantılar için) ya da arka uç sunucusunda (giden veya güneye doğru bağlantılar için) toplayabilirsiniz.

   tcpdump -i any -s 0 host IP address -w File name
   

   tcpdump komutunu kullanma hakkında daha fazla bilgi için tcpdump verilerine bakın.
3. tcpdump verilerini Wireshark veya benzer bir araç kullanarak analiz edin.
4. tcpdump çıktısından, doğrulama adımı sırasında sertifikayı reddeden ana makineyi (istemci veya sunucu) belirleyin.
5. Veriler şifrelenmemişse diğer uçtan gönderilen sertifikayı tcpdump çıkışından alabilirsiniz. Bu, sertifikanın güvenli depoda bulunan sertifikayla eşleşip eşleşmediğini karşılaştırmak için yararlıdır.
6. Mesaj İşleyici ile arka uç sunucusu arasındaki SSL iletişimi için örnek tcpdump'yi inceleyin.

   Sertifika bilinmiyor hatasını gösteren tcpdump örneği

   
   

   1. Mesaj İşleyici (istemci), 59 numaralı iletide "Client Hello"yu arka uç sunucusuna (sunucu) gönderir.
   2. Arka uç sunucusu, 61 numaralı mesajda Mesaj İşleyici'ye "Server Hello" mesajını gönderir.
   3. Kullanılan protokolü ve şifre paketi algoritmalarını karşılıklı olarak doğrularlar.
   4. Arka uç sunucusu, 68 numaralı mesajda Sertifika ve Server Hello Done mesajını Mesaj İşleyici'ye gönderir.
   5. Mesaj İşleyici, 70 numaralı iletide Önemli Uyarı "Açıklama: Sertifika Bilinmiyor"'yu gönderir.
   6. 70 numaralı iletiyi daha ayrıntılı incelediğimizde, aşağıdaki uyarı mesajı dışında ek ayrıntı olmadığını görüyoruz:

      
      

   7. Aşağıdaki grafikte gösterildiği gibi, arka uç sunucusu tarafından gönderilen sertifikayla ilgili ayrıntıları öğrenmek için 68 numaralı iletiyi inceleyin:

      

   8. Arka uç sunucusunun sertifikası ve sertifika zincirinin tamamı, yukarıdaki şekilde gösterildiği gibi "Sertifikalar" bölümünde yer alır.
7. Sertifikanın yukarıdaki örnekte gösterildiği gibi yönlendirici (kuzeye doğru) veya mesaj işlemci (güneye doğru) tarafından bilinmediği tespit edilirse aşağıdaki adımları uygulayın:
   1. Belirli bir güven deposunda saklanan sertifikayı ve sertifika zincirini alın. (Yönlendirici için sanal ana makine yapılandırmasına ve Mesaj İşleyici için hedef uç nokta yapılandırmasına bakın). Sertifika ayrıntılarını almak için aşağıdaki API'leri kullanabilirsiniz:
      1. Güvenli depoda sertifika adını alın:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Güven deposundaki sertifikanın ayrıntılarını alma:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. Yönlendiricinin (kuzeye doğru) veya Mesaj İşleyici'nin (güneye doğru) güvenli deposunda depolanan sertifikanın, istemci uygulamasının (kuzeye doğru) veya hedef sunucunun (güneye doğru) anahtar deposunda depolanan sertifikayla ya da tcpdump çıkışından alınan sertifikayla eşleşip eşleşmediğini kontrol edin. Uyuşmazlık varsa TLS/SSL el sıkışma işleminin başarısız olmasının nedeni budur.
8. Sertifikanın istemci uygulaması (kuzeye giden) veya hedef sunucu (güneye giden) tarafından bilinmediği tespit edilirse aşağıdaki adımları uygulayın:
   1. Belirli bir anahtar deposunda depolanan sertifikada kullanılan sertifika zincirinin tamamını alın. (Yönlendirici için sanal ana makine yapılandırmasına ve Mesaj İşleyici için hedef uç nokta yapılandırmasına bakın.) Sertifika ayrıntılarını almak için aşağıdaki API'leri kullanabilirsiniz:
      1. Anahtar deposundaki sertifika adını alın:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. Anahtar deposundaki sertifikanın ayrıntılarını alma:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. Yönlendiricinin (kuzeye doğru) veya Mesaj İşleyicinin (güneye doğru) anahtar deposunda depolanan sertifikanın, istemci uygulamasının (kuzeye doğru) veya hedef sunucunun (güneye doğru) güven deposunda depolanan sertifikayla ya da tcpdump çıkışından alınan sertifikayla eşleşip eşleşmediğini kontrol edin. Uyuşmazlık varsa SSL el sıkışma işleminin başarısız olmasının nedeni budur.
9. Bir sunucu/istemci tarafından gönderilen sertifikanın süresinin dolduğu tespit edilirse alıcı istemci/sunucu sertifikayı reddeder ve tcpdump bölümünde aşağıdaki uyarı mesajını görürsünüz:

   Uyarı (Düzey: Kritik, Açıklama: Sertifikanın geçerlilik süresi doldu)

10. Uygun ana makinenin anahtar deposundaki sertifikanın süresinin dolduğunu doğrulayın.

Çözünürlük

Yukarıdaki örnekte belirtilen sorunu çözmek için geçerli arka uç sunucusunun sertifikasını Mesaj İşleyici'deki güvenilir sertifika deposuna yükleyin.

Aşağıdaki tabloda, sorunun nedenine bağlı olarak sorunu çözmek için gereken adımlar özetlenmektedir.

SNI Etkin Sunucu

TLS/SSL el sıkışması hatası, istemci bir Sunucu Adı Göstergesi (SNI) etkin sunucuyla iletişim kurarken ancak istemci SNI etkin değilken oluşabilir. Bu durum, Edge'deki kuzeye veya güneye giden bağlantıda meydana gelebilir.

Öncelikle, kullanılan sunucunun ana makine adını ve bağlantı noktası numarasını belirlemeniz ve SNI'nın etkin olup olmadığını kontrol etmeniz gerekir.

SNI etkin sunucunun tanımlanması

1. openssl komutunu çalıştırın ve aşağıda gösterildiği gibi sunucu adını iletmeden ilgili sunucu ana makine adına (Edge Router veya arka uç sunucusu) bağlanmayı deneyin:

   openssl s_client -connect hostname:port

   Sertifikaları alabilirsiniz ve bazen aşağıdaki örnekte gösterildiği gibi openssl komutunda el sıkışma hatası görebilirsiniz:
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

2. openssl komutunu çalıştırın ve aşağıdaki örnekte gösterildiği gibi sunucu adını ileterek ilgili sunucu ana makine adına (uç yönlendirici veya arka uç sunucusu) bağlanmayı deneyin:

   openssl s_client -connect hostname:port -servername hostname

3. 1. adımda el sıkışma hatası alırsanız veya 1. adım ile 2. adımda farklı sertifikalar alırsanız belirtilen sunucuda SNI'nın etkin olduğu anlaşılır.

Sunucuda SNI'nın etkinleştirildiğini belirledikten sonra, TLS/SSL el sıkışma hatasının istemcinin SNI sunucusuyla iletişim kuramamasından kaynaklanıp kaynaklanmadığını kontrol etmek için aşağıdaki adımları uygulayabilirsiniz.

Teşhis

1. Hatanın kuzeye veya güneye giden bağlantıda mı oluştuğunu belirleyin. Bu belirlemeyi yapma hakkında daha fazla bilgi için Sorunun kaynağını belirleme başlıklı makaleyi inceleyin.
2. Daha fazla bilgi toplamak için tcpdump yardımcı programını çalıştırın:
   • Özel bulut kullanıcısıysanız ilgili istemcide veya sunucuda tcpdump verilerini toplayabilirsiniz. İstemci, istemci uygulaması (gelen veya kuzeye doğru bağlantılar için) ya da ileti işlemcisi (giden veya güneye doğru bağlantılar için) olabilir. Sunucu, 1. adımda belirlediğinize bağlı olarak Edge yönlendirici (gelen veya kuzeye doğru bağlantılar için) ya da arka uç sunucusu (giden veya güneye doğru bağlantılar için) olabilir.
   • Herkese açık bulut kullanıcısıysanız, Edge Router veya Mesaj İşleyici'ye erişiminiz olmadığından tcpdump verileri yalnızca istemci uygulamasında (gelen veya kuzeye doğru bağlantılar için) ya da arka uç sunucusunda (giden veya güneye doğru bağlantılar için) toplayabilirsiniz.

   tcpdump -i any -s 0 host IP address -w File name
   

   tcpdump komutunu kullanma hakkında daha fazla bilgi için tcpdump verilerine bakın.
3. Wireshark veya benzer bir araç kullanarak tcpdump çıkışını analiz edin.
4. Wireshark kullanılarak tcpdump ile ilgili örnek analiz aşağıda verilmiştir:
   1. Bu örnekte, TLS/SSL el sıkışması hatası Edge Message Processor ile arka uç sunucusu (güney bağlantısı) arasında meydana geldi.
   2. Aşağıdaki tcpdump çıktısındaki 4 numaralı mesaj, Mesaj İşleyici'nin (kaynak) arka uç sunucusuna (hedef) "Client Hello" mesajı gönderdiğini gösteriyor.

      

   3. "Client Hello" mesajı seçildiğinde, Message Processor'ın TLSv1.2 protokolünü kullandığı gösterilir.

      

   4. 4 numaralı mesaj, arka uç sunucusunun Mesaj İşleyici'den gelen "Client Hello" mesajını onayladığını gösterir.
   5. Arka uç sunucusu, Mesaj İşleyiciye (5 numaralı ileti) hemen bir Fatal Alert : Handshake Failure (Önemli Uyarı: El Sıkışma Hatası) gönderir. Bu durumda TLS/SSL el sıkışma işlemi başarısız olur ve bağlantı kapatılır.
   6. Aşağıdaki bilgileri öğrenmek için 6 numaralı mesajı inceleyin.
      • Arka uç sunucusu TLSv1.2 protokolünü destekliyor. Bu, protokolün Mesaj İşleyici ile arka uç sunucusu arasında eşleştiği anlamına gelir.
      • Ancak arka uç sunucusu, aşağıdaki şekilde gösterildiği gibi Fatal Alert: Handshake Failure mesajını Mesaj İşleyici'ye göndermeye devam eder:

        

   7. Bu hata aşağıdaki nedenlerden biriyle karşılaşmanız durumunda oluşabilir:
      • Mesaj İşleyici, arka uç sunucu tarafından desteklenen şifre paketi algoritmalarını kullanmıyor.
      • Arka uç sunucusunda SNI etkinleştirilmiş ancak istemci uygulaması sunucu adını göndermiyor.
   8. tcpdump çıktısındaki 3 numaralı iletiyi (Client Hello) daha ayrıntılı olarak inceleyin. Aşağıda gösterildiği gibi Extension: server_name'in eksik olduğunu unutmayın:

      

   9. Bu, Mesaj İşleyici'nin SNI özellikli arka uç sunucusuna server_name göndermediğini onaylar.
   10. Bu, TLS/SSL el sıkışma hatasının nedeni ve arka uç sunucusunun ileti işlemcisine Fatal Alert: Handshake Failure (Önemli Uyarı: El Sıkışma Hatası) göndermesinin sebebidir.
5. İleti işlemcisinin SNI etkin sunucuyla iletişim kurmak üzere etkinleştirilmediğini doğrulamak için İleti İşlemcisi'nde jsse.enableSNIExtension property in system.properties değerinin false olarak ayarlandığını doğrulayın.

Çözünürlük

Aşağıdaki adımları uygulayarak Mesaj İşleyici'nin SNI etkin sunucularla iletişim kurmasını sağlayın:

1. /opt/apigee/customer/application/message-processor.properties dosyasını oluşturun (henüz yoksa).
2. Bu dosyaya aşağıdaki satırı ekleyin: conf_system_jsse.enableSNIExtension=true
3. Bu dosyanın sahibini apigee:apigee olarak değiştirin:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Mesaj İşleyici'yi yeniden başlatın.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. Birden fazla Mesaj İşleyiciniz varsa 1-4 arasındaki adımları tüm Mesaj İşleyicilerde tekrarlayın.

TLS/SSL el sıkışması hatasının nedenini belirleyemiyorsanız ve sorunu düzeltemiyorsanız ya da daha fazla yardıma ihtiyacınız varsa Apigee Edge Destek Ekibi ile iletişime geçin. Sorunla ilgili tüm ayrıntıları tcpdump çıkışıyla birlikte paylaşın.