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.
. Git: Apigee X belgeleri. bilgi

Belirti

İstemci uygulaması 503 HTTP durum kodunu alır ve "Hizmet Kullanılamıyor" mesajıyla yanıt verebilir. Kullanıcı arayüzü izlemesinde error.cause Hedef İstek Akışında Received fatal alert: bad_certificate başarısız olan API isteğini gönderin.

Mesaj İşleyici günlüklerine erişiminiz varsa şu hata mesajını göreceksiniz: Received fatal alert: bad_certificate başarısız olan API isteğini gönderin. Bu hata SSL anlaşması sırasında gözlemlenir. arka uç sunucusu arasında iki yönlü TLS kurulumu gerçekleştirecek şekilde gerçekleştirilir.

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ı, ilgili API isteği için aşağıdaki hatayı görür bölümünde /opt/apigee/var/log/edge-message-processor/system.log bulabilirsiniz:

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 aşağıda açıklanmıştır:

Neden	Açıklama	Aşağıdakiler İçin Geçerli Sorun Giderme Talimatları
İstemci Sertifikası Yok	Hedef Sunucunun Hedef Uç Noktasında kullanılan Anahtar Deposu'nun herhangi bir İstemci Sertifikası yok.	Edge Özel ve Herkese Açık Bulut Kullanıcıları
Sertifika Yetkilisi Uyuşmazlığı	Yaprak sertifikanın Sertifika Yetkilisi (Sertifika zincirindeki ilk Sertifika) değeri, arka uç sunucusu tarafından kabul edilen Sertifika Yetkililerinin hiçbiriyle eşleşmiyor.	Edge Ö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 Aşama arasında gezinin ve hata oluştu. Hata, Hedef İstek Akışı'nda ortaya çıkacaktı.
Hatayı gösteren Akışı inceleyin. Hatayı gösterildiği gibi gözlemlemeniz gerekir görebilirsiniz:
.
Yukarıdaki ekran görüntüsünde gördüğünüz gibi error.cause "Önemli uyarı alındı: bad_certificate".

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

Başarısız olan API isteğinin mesaj kimliğini, "X-Apigee.Message-ID" Hata Başlığının değeri gösteren aşamada AX ile gösterilen aşama.

İleti İşleyen günlüğünde bu ileti kimliğini arayın /opt/apigee/var/log/edge-message-processor/system.log ve belirley hatayla ilgili daha fazla bilgi bulabilirseniz:

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 hata ile ilgili bir yığın izleme (stack trace) vardı Received fatal alert: bad_certificate, ancak değil bu sorunun nedenini belirten daha fazla bilgiye sahip olabilir.

Bu sorunu daha ayrıntılı şekilde incelemek için TCP/IP paketlerini tcpdump aracını kullanın.
1. Private Cloud kullanıcısıysanız Arka uç sunucusundaki veya Mesaj İşleyicideki TCP/IP paketleri. Tercihen, paketlerin şifresi çözülürken bu dosyaları arka uç sunucusunda arka uç sunucusuna gidin.
2. Herkese açık Bulut kullanıcısıysanız TCP/IP'yi yakalayın arka uç sunucusunda arka uç sunucuya gönderilir.
3. TCP/IP paketlerini nerede yakalamak istediğinize karar verdikten sonra, tcpdump'ın altında komutunu kullanabilirsiniz.
Wireshark aracını veya alışkın olduğunuz benzer bir aracı kullanarak TCP/IP paketlerini analiz edin.

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

alternatif_metin

Yukarıdaki tcpdump'te yer alan 4. iletide, İleti İşleyen (kaynak) arka uç sunucusuna (hedef) bir "Client Hello" mesajı gönderdi.
5. mesaj, arka uç sunucusunun Client Hello mesajını onayladığını gösterir seçmeniz gerekir.
Arka uç sunucusu, "Sunucu Hello"yu gönderir mesajıyla birlikte sertifikasının ve sonra da İstemciden, İleti 7'de Sertifikasını göndermesini ister.
Mesaj İşleyen, Sertifika doğrulama işlemini tamamlar ve arka uç sunucusunun 8 numaralı İleti'deki ServerHello mesajı.
İleti İşleyici, Sertifikasını İleti 9'da arka uç sunucusuna gönderir.
Arka uç sunucusu Mesaj İşleyici'nin İleti 11’deki Sertifika.
Ancak, Kritik Uyarı: Hatalı Sertifika'yı İleti İşleyici (İleti 12). Bu, Google Ad Manager tarafından gönderilen ve bu nedenle Sertifika Doğrulama işlemi başarısız oldu. arka uç sunucusuna gidin. Sonuç olarak SSL El Sıkışması başarısız oldu ve bağlantı kapanacak.
Şimdi, İleti İşleyen tarafından gönderilen sertifikanın içeriğini kontrol etmek için 9 numaralı İleti'ye bakalım:
Sizin de fark edebileceğiniz gibi arka uç sunucusu, (Sertifika Uzunluğu: 0). Bu nedenle, arka uç sunucusu Önemli Uyarı: Hatalı Sertifika gönderir.
Bu genellikle İstemci, yani İleti İşleyici (Java tabanlı bir işlem) olduğunda ortaya çıkar:
1. KeyStore'da herhangi bir İstemci Sertifikası yoksa veya
2. İstemci Sertifikası gönderemiyor. Bu işlem, Arka Uç Sunucusu'nun kabul edilebilir Sertifika Yetkililerinden biri tarafından verilen bir Sertifika. Yani, müşterinin Yaprak Sertifikası'nın Sertifika Yetkilisi (yani zincirdeki ilk Sertifika), arka uç sunucusunun sertifika yetkilileri kabul edilmezse Mesaj İşleyici sertifikayı göndermez.

Bu nedenlerin her birini aşağıda açıklandığı gibi ayrı ayrı inceleyelim.

Neden: İstemci Sertifikası Yok

Teşhis

SSL Bilgisi bölümünde belirtilen Anahtar Deposu'nda Sertifika yoksa belirlenen hedef uç noktanın veya hedef sunucunun verilerini bu hatanın nedeni budur.

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

Hedef Uç Nokta veya Hedef Sunucuda kullanılan Anahtar Deposunu belirleyin aşağıdaki adımları uygulayarak ilgili API Proxy için:
1. Keystore öğesinden Anahtar Deposu referans adını alma SSLInfo bölümünde ayarlayabilirsiniz.
  Hedef Uç Nokta Yapılandırmasındaki ö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"'dir.
3. Edge kullanıcı arayüzüne gidin ve API Proxy'leri -> seçeneğini belirleyin. Ortam Yapılandırmaları.
  Referanslar sekmesini seçin ve Anahtar Deposu referans adını arayın. Belirli Anahtar Deposu referansı için Referans sütunundaki adı not edin. Bu ad, Anahtar Deposu adınız olacaktır.
4. Yukarıdaki örnekte, myKeystoreRef referansının anahtar deposuna götüreceğiz. Bu nedenle Anahtar Deposu adı, myKeystore'dur.
Bu Anahtar Deposu'nun Sertifikayı içerip içermediğini kontrol etmek için Edge kullanıcı arayüzünü veya Anahtar deposu API'si için sertifikaları listeleyin.
Anahtar Deposu Sertifika içeriyorsa Neden: Sertifika Yetkilisi Uyuşmazlığı.
Anahtar Deposu herhangi bir Sertifika içermiyorsa, Sertifika İleti İşleyen tarafından gönderilmez.

Çözünürlük

İleti İşleyici'deki belirli Anahtar Deposu'na doğru ve eksiksiz İstemci Sertifikası zincirinin yüklendiğinden emin olun.

Neden: Sertifika Yetkilisi Uyuşmazlığı

Genellikle Sunucu, İstemcinin Sertifikasını göndermesini istediğinde kabul edilen Sertifika Verenler veya Sertifika Yetkilileri grubunu gösterir. Sertifikayı veren kuruluş/sertifika yetkilisi (ör. anahtar deposundaki [Sertifika] zincirindeki herhangi bir sertifika) arka uç sunucusu tarafından kabul edilen Sertifika Yetkililerinden hiçbiriyle eşleşmediğinde Mesaj İşlemci (Java tabanlı bir işlem) arka uç sunucusuna gönderilmez.

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ı Anahtar deposu API'si için sertifika alın.

Anahtar Deposu'nda depolanan yaprak Sertifikası'nı (yani, sertifika zincirindeki ilk Sertifika) not edin.

Örnek Yaprak Sertifika

{
  "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, sertifikayı veren/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ç sunucusunun kabul ettiği Verenler 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>
```
"Kabul Edilebilir İstemci Sertifikası CA adları" başlıklı bölüme bakın. bu komutun çıkışında aşağıdaki kodu kullanı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: Certificate Request paketini kontrol edin ve Arka uç sunucusunun İstemci'den sertifikasını göndermesini istediği TCP/IP Paketleri:

Yukarıda gösterilen örnek TCP/IP paketlerinde Certificate Request 7. mesajdır. "Ayırt Edici Adlar" bölümüne bakın, arka uç sunucusunun Kabul Edilebilir Sertifika Yetkilileri'ni içeren bir sertifika içe aktarılmalıdır.

Not: Arka uç sunucusunun "Kabul Edilebilir Sertifika Yetkilileri" listesi arka uç sunucusunun Truststore'da depolanan tüm Sertifikaları verenler eklenerek doldurulur.
3. adımda elde edilen Sertifika Yetkilisinin listeyle eşleşip eşleşmediğini kontrol edin arka uç sunucusunun kabul ettiği Sertifika Yetkilileri veya Sertifika Yetkilileri'nden 4. adımda edinilen bilgileri girin. Uyuşmazlık varsa İletiyi İşleyen, İstemci Sertifikası'nı göndermez. arka uç sunucusuna gönderilir.

Yukarıdaki örnekte, İstemcinin Yaprak Sertifikasını veren kuruluşun arka uç sunucusunun anahtar deposundaki herhangi bir Kabul Edilen Sertifika Yetkilileri. Dolayısıyla İleti İşleyen arka uç sunucuya istemci sertifikası gönderin. Bu, SSL anlaşmasının başarısız olmasına ve arka uç sunucusu "Fatal alert: bad_certificate" gönderir. mesajını alırsınız.

Çözünürlük

Sertifikayı verenin/sertifika yetkilisinin eşleşen sertifikaya sahip olduğundan emin olun İstemcinin Yaprak Sertifikasını veren/Sertifika Yetkilisi (ilk sertifika arka uç sunucusunun Truststore'da depolanır.
Bu Başucu Kitabı'nda açıklanan örnekte, sertifikayı veren kuruluşa ait sertifika "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" , sorunu çözmek için arka uç sunucusunun Truststore'a eklendi.

Sorun devam ederse Teşhis Bilgilerinin Toplanması Gerekenler bölümüne gidin.

Teşhis Bilgileri Toplanmalıdır

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

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ç sunucusunda 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ç sunucusunda veya Mesaj İşleyicide yakalanan TCP/IP paketleri.
6. Anahtar deposu API'si için sertifika alma çıktısı.
Bu Başucu Kitabı'nda hangi bölümleri denediğiniz ve diğer Bu sorunun çözümünü biraz daha hızlı bir şekilde çözmemize yardımcı olacak değerli bilgiler edineceğiz.