Google, içerikleri tercih ettiğiniz dile çevirmek için yapay zeka teknolojisini kullanır. Yapay zeka çevirilerinde hata olabilir.

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ı, bir API isteğine yanıt olarak "Service Unavailable" (Hizmet Kullanılamıyor) mesajıyla birlikte 503 HTTP durum kodunu alır. Kullanıcı arayüzü izinde, başarısız olan API isteği için Hedef İstek Akışı'nda error.cause 'un Received fatal alert: bad_certificate olduğunu görürsünüz.

Mesaj İşleyici günlüklerine erişiminiz varsa başarısız olan API isteği için hata mesajının Received fatal alert: bad_certificate olduğunu görürsünüz. Bu hata, 2 yönlü TLS kurulumunda ileti işlemcisi ile arka uç sunucusu arasındaki SSL el sıkışması işlemi sırasında görülür.

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

Özel bulut kullanıcıları, Mesaj İşleyici günlüklerindeki /opt/apigee/var/log/edge-message-processor/system.log belirli 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	Aşağıdaki Durumlarda Geçerli Sorun Giderme Talimatları
İstemci Sertifikası Yok	Hedef sunucunun hedef uç noktasında kullanılan anahtar deposunda istemci sertifikası yok.	Edge Private ve Public Cloud kullanıcıları
Sertifika Yetkilisi Uyuşmazlığı	İleti işlemcinin anahtar deposundaki yaprak sertifikasının (sertifika zincirindeki ilk sertifika) sertifika yetkilisi, arka uç sunucusu tarafından kabul edilen sertifika yetkililerinden biriyle eşleşmiyor.	Edge Private ve Public Cloud kullanıcıları

Sık Karşılaşılan Teşhis Adımları

Edge kullanıcı arayüzünde izlemeyi etkinleştirin, API çağrısını yapın ve sorunun yeniden oluşmasını sağlayın.
Kullanıcı arayüzü izleme sonuçlarında her Aşamaya gidin ve hatanın nerede oluştuğunu belirleyin. Hata, hedef istek akışında oluşmuş olmalıdır.
Hatayı gösteren akışı inceleyin. Hatayı aşağıdaki örnek izde gösterildiği gibi görmelisiniz:
Yukarıdaki ekran görüntüsünde gördüğünüz gibi error.cause , "Received fatal alert: bad_certificate" şeklindedir.

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

İzleme işleminde AX ile belirtilen aşamada "X-Apigee.Message-ID" hata başlığının değerini belirleyerek başarısız olan API isteğinin mesaj kimliğini alabilirsiniz.

Mesaj İşleyici günlüğünde /opt/apigee/var/log/edge-message-processor/system.log bu ileti 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]

İleti İşleyici günlüğünde Received fatal alert: bad_certificate hatasıyla ilgili bir yığın izleme vardı ancak bu sorunun nedenini gösteren başka bir bilgi yoktu.

Bu sorunu daha ayrıntılı bir şekilde incelemek için tcpdump aracını kullanarak TCP/IP paketlerini yakalamanız gerekir.
1. Özel Cloud kullanıcısıysanız TCP/IP paketlerini arka uç sunucusunda veya mesaj işlemcisinde yakalayabilirsiniz. Tercihen, paketlerin arka uç sunucusunda şifresi çözüldüğü için bunları 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, TCP/IP paketlerini yakalamak için aşağıdaki tcpdump komutunu kullanın.
Wireshark aracını veya benzeri bir aracı kullanarak TCP/IP paketlerini analiz edin.

Wireshark aracı kullanılarak örnek TCP/IP paketleri verilerinin analizi aşağıda verilmiştir:

alt_text

Yukarıdaki tcpdump'taki 4 numaralı ileti, Mesaj İşleyici'nin (kaynak) arka uç sunucusuna (hedef) "Client Hello" iletisini gönderdiğini gösteriyor.
5 numaralı mesaj, arka uç sunucusunun, mesaj işlemcisinden gelen Client Hello mesajını onayladığını gösterir.
Arka uç sunucusu, "Server Hello" mesajını sertifikasıyla birlikte gönderir ve ardından istemciden 7 numaralı mesajda sertifikasını göndermesini ister.
Mesaj İşleyici, Sertifika'nın doğrulanmasını tamamlar ve 8 numaralı iletide arka uç sunucusunun ServerHello iletisini onaylar.
Mesaj İşleyici, 9 numaralı iletide sertifikasını arka uç sunucusuna gönderir.
Arka uç sunucusu, 11 numaralı iletideki İleti İşleyici'nin Sertifikası'nın alındığını onaylar.
Ancak, Mesaj İşleyiciye (Mesaj #12) hemen Fatal Alert: Bad Certificate (Önemli Uyarı: Kötü Sertifika) gönderir. Bu, Mesaj İşleyici tarafından gönderilen sertifikanın kötü olduğunu ve bu nedenle arka uç sunucusunda sertifika doğrulamasının başarısız olduğunu gösterir. Bu nedenle, SSL el sıkışma işlemi başarısız oldu ve bağlantı kapatılacak.
Şimdi de Mesaj İşleyici tarafından gönderilen sertifikanın içeriğini kontrol etmek için 9 numaralı iletiye bakalım:
Arka uç sunucusunun istemciden herhangi bir sertifika almadığını fark edebilirsiniz (Sertifika Uzunluğu: 0). Bu nedenle, arka uç sunucusu Fatal Alert: Bad Certificate (Önemli Uyarı: Kötü Sertifika) mesajını gönderir.
Bu durum genellikle istemci, yani mesaj işleyici (Java tabanlı bir işlem) aşağıdaki durumlarda gerçekleşir:
1. KeyStore'unda istemci sertifikası yoksa veya
2. İstemci sertifikası gönderemez. Bu durum, arka uç sunucusunun kabul edilebilir sertifika yetkililerinden biri tarafından verilmiş bir sertifika bulunamadığında ortaya çıkabilir. Yani, istemcinin yaprak sertifikasının sertifika yetkilisi (zincirdeki ilk sertifika) arka uç sunucusunun kabul edilebilir sertifika yetkililerinden biriyle eşleşmiyorsa Mesaj İşleyici sertifikayı göndermez.

Bu nedenlerin her birini ayrı ayrı inceleyelim.

Neden: İstemci sertifikası yok

Teşhis

Hedef uç noktanın SSL bilgileri bölümünde veya hedef uç noktada kullanılan hedef sunucuda belirtilen anahtar deposunda sertifika yoksa bu hatanın nedeni budur.

Bunun nedeni olup olmadığını belirlemek için aşağıdaki adımları uygulayın:

Aşağıdaki adımları uygulayarak belirli API proxy'si için hedef uç noktada veya hedef sunucuda kullanılan anahtar deposunu belirleyin:
1. Hedef uç noktadaki veya hedef sunucudaki SSLInfo bölümünde yer alan Keystore öğesinden anahtar deposu referans adını alın.
  Bir hedef uç nokta yapılandırmasındaki örnek bir SSLInfo bölümüne bakalım:
```
<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
```
2. Yukarıdaki örnekte, Keystore referans adı "myKeystoreRef" şeklindedir.
3. Edge kullanıcı arayüzüne gidip API Proxies -> Environment Configurations'ı (API Proxy'leri -> Ortam Yapılandırmaları) seçin.
  Referanslar sekmesini seçin ve Keystore referans adını arayın. Belirli bir anahtar deposu referansı için Referans sütunundaki adı not edin. Bu, anahtar deponuzun adı olacaktır.
4. Yukarıdaki örnekte, myKeystoreRef'in "myKeystore"a referansı olduğunu görebilirsiniz. Bu nedenle, Keystore adı myKeystore'dur.
Bu anahtar deposunun sertifika içerip içermediğini Edge kullanıcı arayüzünü veya List certs for keystore API'yi kullanarak kontrol edin.
Anahtar deposu sertifika içeriyorsa Neden: Sertifika Yetkilisi Uyuşmazlığı bölümüne gidin.
Anahtar deposunda sertifika yoksa istemci sertifikasının Mesaj İşleyici tarafından gönderilmeme nedeni budur.

Çözünürlük

Uygun ve eksiksiz istemci sertifikası zincirinin, Mesaj İşleyici'deki belirli anahtar deposuna yüklendiğinden emin olun.

Neden: Sertifika yetkilisi eşleşmiyor

Genellikle sunucu, istemciden sertifikasını göndermesini istediğinde kabul edilen verenler veya sertifika yetkilileri kümesini belirtir. İleti İşleyici'nin anahtar deposundaki yaprak sertifikasının (yani sertifika zincirindeki ilk sertifika) veren/sertifika yetkilisi, arka uç sunucusu tarafından kabul edilen sertifika yetkililerinden herhangi biriyle eşleşmiyorsa İleti İşleyici (Java tabanlı bir süreçtir) sertifikayı arka uç sunucusuna göndermez.

Bunun böyle olup olmadığını doğrulamak için aşağıdaki adımları uygulayın:

Keystore API için sertifikaları listeleme.
Get cert for keystore API'yi kullanarak yukarıdaki 1. adımda alınan her sertifikanın ayrıntılarını edinin.

Anahtar deposunda depolanan yaprak sertifikasının (yani sertifika zincirindeki ilk sertifika) verenini 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, veren/sertifika yetkilisi "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"'dir.

Aşağıdaki tekniklerden birini kullanarak arka uç sunucusunun kabul ettiği verenler veya sertifika yetkilileri listesini belirleyin:
1. teknik: Aşağıdaki openssl 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 "Kabul edilebilir istemci 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ç sunucunun istemciden 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, 7 numaralı mesajdır. Arka uç sunucusunun Kabul Edilebilir Sertifika Yetkililerini içeren "Ayırt Edici Adlar" bölümüne bakın.

Not: Arka uç sunucusunun "Kabul Edilebilir Sertifika Yetkilileri" listesi, arka uç sunucusunun güvenli sertifika deposunda saklanan tüm sertifikaların verenleri eklenerek doldurulur.
3. adımda alınan sertifika yetkilisinin, arka uç sunucusunun kabul ettiği verenler veya 4. adımda alınan sertifika yetkilileri listesiyle eşleşip eşleşmediğini doğrulayın. Bir uyuşmazlık varsa İleti İşleyici, istemci sertifikasını arka uç sunucusuna göndermez.

Yukarıdaki örnekte, İleti İşlemcisinin anahtar deposundaki İstemcinin Yaprak Sertifikası'nı veren kuruluşun, arka uç sunucusunun Kabul Edilen Sertifika Yetkilileri'nden herhangi biriyle eşleşmediğini görebilirsiniz. Bu nedenle, Mesaj İşleyici, istemci sertifikasını arka uç sunucusuna göndermez. Bu durum, SSL el sıkışmasının başarısız olmasına ve arka uç sunucusunun "Fatal alert: bad_certificate" mesajını göndermesine neden olur.

Çözünürlük

Veren/Sertifika Yetkilisi ile eşleşen sertifikanın, istemcinin yaprak sertifikasının (zincirdeki ilk sertifika) veren/sertifika yetkilisi ile birlikte arka uç sunucusunun güvenli deposunda saklandığından emin olun.
Bu Playbook'ta açıklanan örnekte, sorunu çözmek için veren "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" olan sertifika arka uç sunucusunun güven deposuna eklendi.

Sorun devam ederse Must Gather Diagnostic Information (Teşhis Bilgileri Toplama) bölümüne gidin.

Toplanması Gereken Teşhis Bilgileri

Yukarıdaki talimatları uyguladıktan sonra sorun devam ederse lütfen aşağıdaki teşhis bilgilerini toplayın. Aşağıdaki bilgileri Apigee Edge Destek Ekibi ile iletişime geçerek 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'sinin Adı
4. Hatayı yeniden oluşturmak için kullanılan curl komutunun tamamı
5. Hatayı gösteren izleme dosyası
6. Arka uç sunucusunda yakalanan TCP/IP paketleri
Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
1. Gözlemlenen hata mesajının tamamı
2. API proxy paketi
3. Hatayı gösteren izleme dosyası
4. Mesaj işleyici günlükleri /opt/apigee/var/log/edge-message-processor/logs/system.log
5. Arka uç sunucusunda veya Mesaj İşleyicisinde yakalanan TCP/IP paketleri.
6. Get cert for keystore API (Keystore API için sertifika alma) çıkışı.
Bu Playbook'taki hangi bölümleri denediğiniz ve bu sorunun çözümünü hızlandırmamıza yardımcı olacak diğer analizler hakkında ayrıntılar.