Bu sayfa, Cloud Translation API ile çevrilmiştir.

SSL El Sıkışma Hataları - Hatalı İstemci Sertifikası

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

Belirti

İstemci uygulaması, API isteğine yanıt olarak "Hizmet Kullanılamıyor" mesajıyla birlikte 503 HTTP durum kodunu alır. Kullanıcı arayüzü izlemesinde, başarısız API isteği için Hedef İstek Akışı'nda error.cause değerinin Received fatal alert: bad_certificate olduğunu göreceksiniz.

Mesaj İşleyici günlüklerine erişiminiz varsa başarısız olan API isteği için Received fatal alert: bad_certificate hata mesajını görürsünüz. Bu hata, Mesaj İşleyici ile arka uç sunucu arasındaki SSL el sıkışması sürecinde 2 yönlü TLS kurulumu kullanılarak gözlemlenir.

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":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

Private Cloud kullanıcıları, /opt/apigee/var/log/edge-message-processor/system.log Message Processor günlüklerinde ilgili API isteği için aşağıdaki hatayı görür:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate

Olası Nedenler

Bu sorunun olası nedenleri şunlardır:

Neden	Açıklama	Geçerli Sorun Giderme Talimatları
İstemci Sertifikası Yok	Hedef Sunucunun Hedef Uç Noktasında kullanılan Anahtar Deposu'nun İstemci Sertifikası yok.	Edge'de Özel ve Herkese Açık Bulut Kullanıcıları
Sertifika Yetkilisi Uyuşmazlığı	İleti İşleyici'nin Anahtar Deposu'ndaki yaprak sertifikasının (Sertifika zincirindeki ilk Sertifika) Sertifika Yetkilisi, arka uç sunucusu tarafından kabul edilen Sertifika Yetkililerinin hiçbiriyle eşleşmiyor.	Edge'de Özel ve Herkese Açık Bulut Kullanıcıları

Genel Teşhis Adımları

Edge kullanıcı arayüzünde izlemeyi etkinleştirin, API çağrısı yapın ve sorunu yeniden oluşturun.
Kullanıcı arayüzü izleme sonuçlarında her bir aşamayı inceleyin ve hatanın nerede oluştuğunu belirleyin. Hata, Hedef İstek Akışı'nda oluşacaktır.
Hatayı gösteren Akışı inceleyin. Hatayı aşağıdaki örnek izde gösterildiği gibi görmeniz gerekir:
Yukarıdaki ekran görüntüsünde gördüğünüz gibi error.cause değeri, error.cause alındı.

Private Cloud kullanıcısıysanız aşağıdaki talimatları uygulayın:

İzdeki AX ile belirtilen Aşamada "X-Apigee.Message-ID" Hata Başlığının değerini belirleyerek başarısız API isteğinin mesaj kimliğini alabilirsiniz.

Mesaj İşleyicisi günlüğünde /opt/apigee/var/log/edge-message-processor/system.log bu mesaj kimliğini arayın ve hatayla ilgili daha fazla bilgi bulup bulamayacağınızı belirleyin:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@6071a73d)
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]

Mesaj İşleyici günlüğünde Received fatal alert: bad_certificate hatası için yığın izleme (stack trace) vardı, ancak bu sorunun nedenini belirten daha fazla bilgi içermiyor.

Bu sorunu daha ayrıntılı bir şekilde incelemek için TCP/IP paketlerini tcpdump aracıyla yakalamanız gerekir.
1. Private Cloud kullanıcısıysanız arka uç sunucudaki veya Mesaj İşleyici'deki TCP/IP paketlerini yakalayabilirsiniz. Tercihen bunları arka uç sunucusunda paketlerin şifresi çözülürken arka uç sunucusunda yakalayın.
2. Herkese Açık Bulut kullanıcısıysanız arka uç sunucusundaki TCP/IP paketlerini yakalayın.
3. TCP/IP paketlerini nerede yakalamak istediğinize karar verdikten sonra aşağıdaki tcpdump komutunu kullanarak TCP/IP paketlerini yakalayın.
TCP/IP paketlerini Wireshark veya bildiğiniz benzer bir araçla analiz edin.

Aşağıda, Wireshark aracını kullanarak örnek TCP/IP paket verilerinin analizini bulabilirsiniz:

alt_text

Yukarıdaki tcpdump'ta yer alan 4. mesaj, Mesaj İşleyicinin (kaynak) arka uç sunucusuna (hedef) bir "Client Hello" mesajı gönderdiğini gösterir.
5. mesaj, arka uç sunucusunun Mesaj İşleyici'den gelen Client Hello mesajını kabul ettiğini gösterir.
Arka uç sunucusu, Sertifikasıyla birlikte "Server Hello" mesajını gönderir ve ardından İstemciden, Sertifikasını İleti 7'de göndermesini ister.
Mesaj İşleyici, Sertifikanın doğrulamasını tamamlar ve Mesaj 8'de arka uç sunucusunun ServerHello mesajını onaylar.
İleti İşleyici, Sertifikasını İleti 9'daki arka uç sunucusuna gönderir.
Arka uç sunucusu, Mesaj 11'de Mesaj İşleyici Sertifikası'nın alındığını onaylar.
Ancak, Mesaj İşleyiciye (İleti 12) hemen Önemli Uyarı: Hatalı Sertifika gönderir. Bu durum, Mesaj İşleyici tarafından gönderilen Sertifikanın bozuk olduğunu ve bu nedenle arka uç sunucusunda Sertifika Doğrulama işleminin başarısız olduğunu belirtir. Bunun sonucunda SSL El Sıkışması başarısız oldu ve bağlantı kapatılacak.
Şimdi, İleti İşleyici tarafından gönderilen sertifikanın içeriğini kontrol etmek için İleti 9'a bakalım:
Sizin de fark edebileceğiniz gibi, arka uç sunucusu İstemciden herhangi bir Sertifika almamıştır (Sertifika Uzunluğu: 0). Bu nedenle, arka uç sunucusu Önemli Uyarı: Hatalı Sertifika mesajını gönderir.
Bu durum genellikle istemcinin, yani Mesaj İşleyici'de (Java tabanlı bir işlem) ortaya çıkar:
1. KeyStore'da herhangi bir İstemci Sertifikası yoksa veya
2. İstemci Sertifikası gönderilemiyor. Bu durum, Arka Uç Sunucusu'nun kabul edilebilir Sertifika Yetkililerinden biri tarafından verilen bir Sertifika bulunamadığında meydana gelebilir. Yani, istemcinin Yaprak Sertifikasının Sertifika Yetkilisi (zincirdeki ilk Sertifika), arka uç sunucusunun kabul edilebilir Sertifika Yetkililerinin hiçbiriyle eşleşmiyorsa İleti İşleyici, sertifikayı göndermez.

Şimdi bu nedenlerin her birine aşağıda ayrı ayrı bakalım.

Neden: İstemci Sertifikası Yok

Teşhis

Hedef Uç Nokta'nın SSL Bilgisi bölümünde veya Hedef Uç Nokta'da kullanılan hedef sunucuda belirtilen Anahtar Deposu'nda Sertifika yoksa bu hatanın nedeni budur.

Sorunun nedeninin bu olup olmadığını belirlemek için aşağıdaki adımları uygulayın:

Aşağıdaki adımları uygulayarak belirli bir API proxy'si için hedef uç nokta veya hedef sunucuda kullanılan anahtar deposunu belirleyin:
1. Hedef Uç Nokta veya Hedef Sunucu'daki SSLInfo bölümündeki Keystore öğesinden Anahtar Deposu referans adını alın.
  Bir Hedef Uç Nokta Yapılandırması'nda örnek SSLInfo bölümünü inceleyelim:
```
<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
```
2. Yukarıdaki örnekte anahtar deposu referans adı "myKeystoreRef" şeklindedir.
3. Edge kullanıcı arayüzüne gidip API Proxy'leri -> Ortam Yapılandırmaları'nı seçin.
  Referanslar sekmesini seçin ve Anahtar deposu referans adını arayın. İlgili Anahtar Deposu referansı için Referans sütunundaki adı not edin. Bu, Anahtar Deposu adınız olacaktır.
4. Yukarıdaki örnekte, myKeystoreRef'in "myKeystore" referansına sahip olduğunu fark edebilirsiniz. Dolayısıyla, Anahtar Deposu adı myKeystore'dur.
Edge kullanıcı arayüzünü veya Anahtar deposu API'si için sertifikaları listeleme sayfasını kullanarak bu anahtar deposunun sertifikayı içerip içermediğini kontrol edin.
Anahtar deposu Sertifika içeriyorsa Neden: Sertifika Yetkilisi Uyuşmazlığı bölümüne geçin.
Anahtar Deposu herhangi bir Sertifika içermiyorsa Mesaj İşleyici tarafından İstemci Sertifikası gönderilmemesinin nedeni budur.

Çözünürlük

İleti İşleyici'deki ilgili Anahtar Deposu'na uygun ve eksiksiz bir İstemci Sertifikası zincirinin yüklendiğinden emin olun.

Neden: Sertifika Yetkilisi Uyuşmazlığı

Genellikle Sunucu, İstemci'den Sertifikasını göndermesini istediğinde bu not, genellikle kabul edilen Sertifika Verenler veya Sertifika Yetkilileri grubunu belirtir. Mesaj İşleyen'in Anahtar Deposu'ndaki yaprak sertifikasının Veren/Sertifika Yetkilisi (Sertifika zincirindeki ilk Sertifika), arka uç sunucusu tarafından kabul edilen Sertifika Yetkililerinden hiçbiriyle eşleşmiyorsa Java tabanlı bir süreç olan Mesaj İşleyici, Sertifika'yı arka uç sunucusuna göndermez.

Böyle bir durumun söz konusu olup olmadığını doğrulamak için aşağıdaki adımları uygulayın:

Anahtar deposu API'si için sertifikaları listeleyin.
Yukarıdaki 1. adımda aldığınız her Sertifikanın Ayrıntılarını Keystore API için sertifika alma'yı kullanarak alın.

Anahtar Deposu'nda depolanan yaprak sertifikasını (sertifika zincirindeki ilk Sertifika) veren yetkiliyi not edin.

Örnek Yaprak Sertifikası

{
  "certInfo" : [ {
    "basicConstraints" : "CA:FALSE",
    "expiryDate" : 1578889324000,
    "isValid" : "Yes",
    "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
    "publicKey" : "RSA Public Key, 2048 bits",
    "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
    "sigAlgName" : "SHA256withRSA",
    "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
    "subjectAlternativeNames" : [ ],
    "validFrom" : 1484281324000,
    "version" : 3
  } ],
  "certName" : "nonprod-api.mycompany.com.key.pem-cert"
}

Yukarıdaki örnekte, yayıncı/Sertifika Yetkilisi: "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

Aşağıdaki tekniklerden birini kullanarak arka uç sunucunun kabul edilen Sertifika Yetkilileri veya Sertifika Yetkilileri listesini belirleyin:
1. Teknik: Aşağıdaki Opensl komutunu kullanın:
```
openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>
```
Bu komutun çıktısında, aşağıda gösterildiği gibi "Kabul Edilebilir İstemci Sertifikası CA adları" başlıklı bölüme bakın:
```
Acceptable client certificate CA names
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
```
2. teknik: Arka uç sunucusu, istemcinin sertifikasını göndermesini istediği TCP/IP paketlerindeki Certificate Request paketini kontrol edin:

Yukarıda gösterilen örnek TCP/IP paketlerinde Certificate Request paketi, mesaj 7'dir. Arka uç sunucusunun Kabul Edilebilir Sertifika Yetkilileri'ni içeren"Ayırt Edici Adlar" bölümüne bakın.

Not: Arka uç sunucusunun "Kabul Edilebilir Sertifika Yetkilileri" listesi, arka uç sunucusunun Truststore'unda depolanan tüm Sertifikaları verenlerin yayıncıları eklenerek doldurulur.
3. adımda alınan Sertifika Yetkilisinin, arka uç sunucusunun kabul edilen Sertifika Yetkilileri veya 4. adımda edinilen Sertifika Yetkilileri listesiyle eşleşip eşleşmediğini doğrulayın. Uyuşmazlık varsa Mesaj İşleyici, istemci sertifikasını arka uç sunucusuna göndermez.

Yukarıdaki örnekte, İstemci'nin İleti İşleyici Anahtar Deposu'ndaki Yaprak Sertifikası'nı verenin, arka uç sunucusunun Kabul Edilen Sertifika Yetkililerinin hiçbiriyle eşleşmediğini fark edebilirsiniz. Bu nedenle, Mesaj İşleyici, İstemci Sertifikası'nı arka uç sunucusuna göndermez. Bu, SSL el sıkışmanın başarısız olmasına ve arka uç sunucusunun "Fatal alert: bad_certificate" mesajı göndermesine neden olur.

Çözünürlük

İstemcinin Yaprak Sertifikası'nı (zincirdeki ilk sertifika) veren kuruluşla/Sertifika Yetkilisi'yle eşleşen sertifikanın, arka uç sunucunun Truststore'da depolandığından emin olun.
Bu başucu kitabında açıklanan örnekte, sorunu çözmek için kartı veren "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" sertifikasına sahip sertifika arka uç sunucusunun Truststore'una eklenmiştir.

Sorun devam ederse Tanılama Bilgilerinin Toplanması Zorunludur bölümüne gidin.

Teşhis Bilgileri Toplanmalı

Yukarıdaki talimatları uygulamanıza rağmen sorun devam ederse lütfen aşağıdaki teşhis bilgilerini toplayın. Apigee Edge Destek Ekibi ile iletişime geçin ve paylaşın:

Herkese Açık Bulut kullanıcısıysanız aşağıdaki bilgileri sağlayın:
1. Kuruluş Adı
2. Ortam Adı
3. API Proxy Adı
4. Hatayı yeniden oluşturmak için curl komutunu tamamlayın
5. Hatayı gösteren İzleme Dosyası
6. Arka uç sunucuda yakalanan TCP/IP paketleri
Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
1. Tam Hata Mesajı gözlemlendi
2. API Proxy paketi
3. Hatayı gösteren İzleme Dosyası
4. Mesaj İşleyici günlükleri /opt/apigee/var/log/edge-message-processor/logs/system.log
5. Arka uç sunucuda veya Mesaj İşleyicide yakalanan TCP/IP paketleri.
6. Anahtar deposu API'si için sertifika alma çıktısı.
Bu Başucu Kitabı'nın hangi bölümlerini denediğinizle ilgili ayrıntılar ve bu sorunun çözümünü hızlandırmamıza yardımcı olacak diğer tüm bilgiler.