Layanan 503 Tidak Tersedia - Kegagalan Handshake SSL

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Gejala

Aplikasi klien mendapatkan kode status HTTP 503 Service Unavailable dengan kode error messaging.adaptors.http.flow.SslHandshakeFailed sebagai respons untuk panggilan API.

Pesan error

Aplikasi klien mendapatkan kode respons berikut: 

HTTP/1.1 503 Service Unavailable

Selain itu, Anda mungkin melihat pesan error berikut: 

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

Kemungkinan penyebab

Anda mungkin mendapatkan kode status 503 Service Unavailable dengan kode error messaging.adaptors.http.flow.SslHandshakeFailed karena terjadi kegagalan selama proses handshake SSL antara Prosesor Pesan Apigee Edge dan server backend karena sejumlah alasan. Pesan error dalam faultstring biasanya menunjukkan kemungkinan penyebab tingkat tinggi yang menyebabkan error ini.

Bergantung pada pesan error yang diamati dalam faultstring, Anda perlu menggunakan teknik yang tepat untuk memecahkan masalah tersebut. Playbook ini menjelaskan cara memecahkan masalah error ini jika Anda melihat pesan error 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 dalam faultstring.

Error ini terjadi selama proses handshake SSL antara Message Processor Apigee Edge dan server backend:

  • Jika truststore pada Pemroses Pesan Apigee Edge:
    • Berisi rantai sertifikat yang tidak cocok dengan rantai sertifikat lengkap server backend, ATAU
    • Tidak berisi rantai sertifikat lengkap server backend
  • Jika rantai sertifikat yang ditampilkan oleh server backend:

Kemungkinan penyebab masalah ini adalah sebagai berikut:

Penyebab Deskripsi Petunjuk pemecahan masalah yang berlaku untuk
Sertifikat atau rantai sertifikat salah/tidak lengkap di truststore Message Processor Sertifikat dan/atau rantainya yang disimpan di truststore pada Message Processor Apigee Edge tidak cocok dengan rantai sertifikat server backend atau tidak berisi rantai sertifikat lengkap server backend. Pengguna Cloud Pribadi dan Publik Edge
Ketidakcocokan FQDN di sertifikat server backend dan nama host di endpoint target Sertifikat yang diberikan oleh server backend berisi FQDN yang tidak cocok dengan nama host yang ditentukan di endpoint target. Pengguna Cloud Pribadi dan Publik Edge
Sertifikat atau rantai sertifikat salah/tidak lengkap yang diberikan oleh server backend Rantai sertifikat yang ditampilkan oleh server backend salah atau tidak lengkap. Pengguna Cloud Pribadi dan Publik Edge

Langkah-langkah diagnosis umum

Gunakan salah satu alat/teknik berikut untuk mendiagnosis error ini:

Pemantauan API

Prosedur #1: Menggunakan Pemantauan API

Untuk mendiagnosis error menggunakan API Monitoring:

  1. Login ke UI Apigee Edge sebagai pengguna dengan peran yang sesuai.

  2. Beralihlah ke organisasi tempat Anda ingin menyelidiki masalah.

  3. Buka halaman Analyze > API Monitoring > Menyelidiki.
  4. Pilih jangka waktu spesifik saat Anda melihat error.

  5. Tempatkan Kode Kesalahan terhadap Waktu.

  6. Pilih sel yang memiliki kode kesalahan messaging.adaptors.http.flow.SslHandshakeFailed seperti yang ditunjukkan di bawah ini:

    ( lihat gambar yang lebih besar)

  7. Informasi tentang kode kesalahan messaging.adaptors.http.flow.SslHandshakeFailed ditampilkan seperti yang ditunjukkan di bawah ini:

    ( lihat gambar yang lebih besar)

  8. Klik Lihat log dan luaskan baris untuk permintaan yang gagal.

    ( lihat gambar yang lebih besar)

  9. Dari jendela Logs, perhatikan detail berikut:
    • Minta ID Pesan
    • Kode Status: 503
    • Sumber Kesalahan: target
    • Kode Kesalahan: messaging.adaptors.http.flow.SslHandshakeFailed

Rekaman aktivitas

Prosedur #2: Menggunakan alat Trace

Untuk mendiagnosis error menggunakan alat Trace:

  1. Aktifkan sesi perekaman aktivitas dan
    • Tunggu hingga error 503 Service Unavailable dengan kode error messaging.adaptors.http.flow.SslHandshakeFailed terjadi, atau
    • Jika Anda dapat merekonstruksi masalah, buat panggilan API untuk mereproduksi masalah 503 Service Unavailable

  2. Pastikan Show all FlowInfos diaktifkan:

  3. Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitas.
  4. Jelajahi berbagai fase rekaman aktivitas dan temukan lokasi terjadinya kegagalan.

  5. Anda akan menemukan error biasanya setelah fase Alur Permintaan Target Dimulai seperti yang ditunjukkan di bawah ini:

    ( lihat gambar yang lebih besar)

  6. Perhatikan nilai berikut dari rekaman aktivitas:
    • error: 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
    • Nilai error 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 menunjukkan bahwa SSL Handshake gagal, karena Message Processor Apigee Edge tidak dapat memvalidasi sertifikat server backend.
  7. Buka Fase AX (Data Analytics Dicatat) di trace, lalu klik Fase tersebut.

  8. Scroll ke bawah ke bagian Phase Details Error Headers, lalu tentukan nilai X-Apigee-fault-code dan X-Apigee-fault-source, serta X-Apigee-Message-ID seperti yang ditunjukkan di bawah ini:

    ( lihat gambar yang lebih besar)

  9. Perhatikan nilai X-Apigee-fault-code, X-Apigee-fault-source, dan X-Apigee-Message-ID:
    10. Header error Nilai
    X-Apigee-fault-code messaging.adaptors.http.flow.SslHandshakeFailed
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

Prosedur #3: Menggunakan log akses NGINX

Untuk mendiagnosis error menggunakan log akses NGINX:

  1. Jika Anda adalah pengguna Private Cloud, Anda dapat menggunakan log akses NGINX untuk menentukan informasi penting tentang HTTP 503 Service Unavailable.

  2. Periksa log akses NGINX:

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

  3. Telusuri untuk melihat apakah ada error 503 dengan kode error messaging.adaptors.http.flow.SslHandshakeFailed selama durasi tertentu (jika masalah terjadi sebelumnya) atau apakah ada permintaan yang masih gagal dengan 503.

  4. Jika Anda menemukan error 503 dengan X-Apigee-fault-code yang cocok dengan nilai messaging.adaptors.http.flow.SslHandshakeFailed, tentukan nilai X-Apigee-fault-source.

    Contoh error 503 dari log akses NGINX:

    ( lihat gambar yang lebih besar)

    Contoh entri dari log akses NGINX di atas memiliki nilai berikut untuk X-Apigee-fault-code dan X-Apigee-fault-source:

    Header Nilai
    X-Apigee-fault-code messaging.adaptors.http.flow.SslHandshakeFailed
    X-Apigee-fault-source target

Log Pemroses Pesan

Prosedur #4: Menggunakan Log Pemroses Pesan

  1. Tentukan ID pesan dari salah satu permintaan yang gagal menggunakan Pemantauan API, Alat Rekaman Aktivitas, atau Log Akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum.

  2. Telusuri ID pesan permintaan tertentu di log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log). Anda mungkin melihat error berikut:

    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

    Error di atas menunjukkan bahwa handshake SSL gagal antara Message Processor dan server backend.

    Hal ini akan diikuti oleh pengecualian dengan pelacakan tumpukan mendetail seperti yang ditunjukkan di bawah ini:

    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>

    Perhatikan bahwa kegagalan handshake disebabkan oleh:

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

    Hal ini menunjukkan bahwa SSL Handshake gagal karena Message Processor Apigee Edge tidak dapat memvalidasi sertifikat server backend.

Penyebab: Sertifikat atau rantai sertifikat salah/tidak lengkap di truststore Pemroses Pesan

Diagnosis

  1. Tentukan Kode Kesalahan, Sumber Kesalahan untuk error yang diamati menggunakan Pemantauan API, Alat Pelacakan, atau log akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum.
  2. Jika Kode Kesalahan adalah messaging.adaptors.http.flow.SslHandshakeFailed, tentukan pesan error menggunakan salah satu metode berikut:
  3. Jika pesan error adalah sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target", maka ini menunjukkan bahwa SSL Handshake gagal, karena Message Processor Apigee Edge tidak dapat memvalidasi sertifikat server backend.

Anda dapat men-debug masalah ini dalam dua fase:

  1. Fase 1: Menentukan rantai sertifikat server backend
  2. Fase 2: Membandingkan rantai sertifikat yang disimpan di truststore Message Processor

Tahap 1

Fase 1: Menentukan rantai sertifikat server backend

Gunakan salah satu metode berikut untuk menentukan rantai sertifikat server backend:

openssl

Jalankan perintah openssl terhadap nama host server backend sebagai berikut:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Perhatikan rantai Sertifikat dari output perintah di atas:

Contoh rantai Sertifikat server backend dari output perintah openssl:

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. Jika Anda adalah pengguna Cloud Publik, rekam paket TCP/IP di server backend.
  2. Jika Anda adalah pengguna Private Cloud, Anda dapat merekam paket TCP/IP di server backend atau Pemroses Pesan. Sebaiknya, ambil data di server backend karena paket didekripsi di server backend.

  3. Gunakan perintah tcpdump berikut untuk merekam paket TCP/IP:

    tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

  4. Analisis paket TCP/IP menggunakan alat Wireshark atau alat serupa yang Anda ketahui.

    Contoh Analisis Tcpdump

    ( lihat gambar yang lebih besar)

    • Paket #43: Pemroses Pesan (Sumber) mengirim pesan Client Hello ke server backend (Tujuan).
    • Paket #44: Server backend mengonfirmasi penerimaan pesan Client Hello dari Pemroses Pesan.
    • Paket #45: Server backend mengirim pesan Server Hello bersama dengan sertifikatnya.
    • Paket #46: Pemroses Pesan mengonfirmasi penerimaan pesan Server Hello dan sertifikat.

    • Paket #47: Pemroses Pesan mengirim pesan FIN, ACK yang diikuti dengan RST, ACK dalam Paket #48.

      Hal ini menunjukkan bahwa validasi sertifikat server backend oleh Pemroses Pesan gagal. Hal ini terjadi karena Pemroses Pesan tidak memiliki sertifikat apa pun yang cocok dengan sertifikat server backend atau tidak dapat memercayai sertifikat server backend dengan sertifikat yang tersedia di truststore (Pemroses Pesan).

    • Anda dapat kembali dan meninjau Paket #45 dan menentukan rantai sertifikat yang dikirim oleh server backend

      ( lihat gambar yang lebih besar)

    • Dalam contoh ini, Anda dapat melihat bahwa server telah mengirimkan sertifikat leaf dengan common name (CN) = mocktarget.apigee.net, diikuti oleh intermediate certificate dengan CN= GTS CA 1D4 dan root certificate dengan CN = GTX Root R1.

    Jika Anda yakin bahwa validasi sertifikasi server gagal, buka Tahap 2: Membandingkan sertifikat dan sertifikat server backend yang disimpan di truststore Pemroses Pesan.

Tahap 2

Fase 2: Membandingkan sertifikat dan sertifikat server backend yang disimpan di truststore Message Processor

  1. Tentukan rantai sertifikat server backend.
  2. Tentukan sertifikat yang disimpan dalam truststore Message Processor menggunakan langkah-langkah berikut:

    1. Dapatkan nama referensi truststore dari elemen TrustStore dalam bagian SSLInfo di TargetEndpoint.

      Mari kita lihat contoh bagian SSLInfo dalam konfigurasi TargetEndpoint:

      <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. Dalam contoh di atas, nama referensi TrustStore adalah myCompanyTruststoreRef.

    3. Di UI Edge, pilih Environments > References. Perhatikan nama di kolom Reference untuk referensi truststore tertentu. Nama ini akan menjadi nama truststore Anda.

      ( lihat gambar yang lebih besar)

    4. Pada contoh di atas, nama truststore adalah:

      myCompanyTruststoreRef: myCompanyTruststore

  3. Dapatkan sertifikat yang disimpan di truststore (ditentukan pada langkah sebelumnya) menggunakan API berikut:

    1. Mendapatkan semua sertifikat untuk keystore atau truststore. API ini mencantumkan semua sertifikat di truststore tertentu.

      Pengguna Cloud Publik:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"

      Pengguna Private Cloud:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"

      Tempat:

      • ORGANIZATION_NAME adalah nama organisasi
      • ENVIRONMENT_NAME adalah nama lingkungannya
      • KEYSTORE_NAME adalah nama keystore
      • $TOKEN ditetapkan ke token akses OAuth 2.0 seperti yang dijelaskan dalam Mendapatkan token akses OAuth 2.0
      • Opsi curl yang digunakan dalam contoh ini dijelaskan dalam Menggunakan curl

      Contoh output:

      Sertifikat dari contoh truststore myCompanyTruststore adalah: 

      [
  "serverCert"
]

    2. Mendapatkan Detail Sertifikat untuk sertifikat tertentu dari Keystore atau Truststore. API ini menampilkan informasi tentang sertifikat tertentu di truststore tertentu.

      Pengguna Cloud Publik:

      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"

      Pengguna Private Cloud

      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"

      Tempat:

      • ORGANIZATION_NAME adalah nama organisasi
      • ENVIRONMENT_NAME adalah nama lingkungannya
      • KEYSTORE_NAME adalah nama keystore
      • CERT_NAME adalah nama sertifikat
      • $TOKEN ditetapkan ke token akses OAuth 2.0 seperti yang dijelaskan dalam Mendapatkan token akses OAuth 2.0
      • Opsi curl yang digunakan dalam contoh ini dijelaskan dalam Menggunakan curl

      Contoh Output

      Detail serverCert menampilkan subjek dan penerbit sebagai berikut:

      Sertifikat Daun/Entitas:

      "subject": "CN=mocktarget.apigee.net",
"issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      Sertifikat Perantara:

      "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. Pastikan sertifikat server sebenarnya yang diperoleh di langkah 1 dan sertifikat yang disimpan di truststore diperoleh pada langkah 3 cocok. Jika tidak cocok, berarti itulah penyebab masalahnya.

    Dari contoh yang ditunjukkan di atas, mari kita lihat satu per satu sertifikat:

    1. Sertifikat daun:

      Dari server backend:

      s:/CN=mocktarget.apigee.net
i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4

      Dari truststore Pemroses Pesan (klien):

      "subject": "CN=mocktarget.apigee.net",
"issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      Sertifikat leaf yang disimpan di truststore cocok dengan yang ada di server backend.

    2. Intermediate certificate:

      Dari server backend:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      Dari truststore Pemroses Pesan (klien):

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
"issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",

      Sertifikat perantara yang disimpan di truststore cocok dengan yang ada di server backend.

    3. Root certificate:

      Dari server backend:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      Root certificate tidak ada sama sekali di truststore Pemroses Pesan.

    4. Karena root certificate tidak ada di truststore, Pemroses Pesan akan menampilkan pengecualian berikut:

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

      dan menampilkan 503 Service Unavailable dengan kode error messaging.adaptors.http.flow.SslHandshakeFailed ke aplikasi klien.

Resolusi

  1. Pastikan Anda memiliki rantai sertifikat server backend yang benar dan lengkap.
  2. Jika Anda adalah pengguna Cloud Publik, ikuti petunjuk di Mengupdate sertifikat TLS untuk Cloud guna mengupdate sertifikat ke truststore Message Processor Apigee Edge.
  3. Jika Anda adalah pengguna Private Cloud, ikuti petunjuk di Memperbarui sertifikat TLS untuk Private Cloud guna memperbarui sertifikat ke truststore Message Processor Apigee Edge.

Penyebab: Ketidakcocokan FQDN di sertifikat server backend dan nama host di endpoint target

Jika server backend menampilkan rantai sertifikat yang berisi FQDN, yang tidak cocok dengan nama host yang ditentukan dalam endpoint target, Proses Pesan Apigee Edge akan menampilkan error 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.

Diagnosis

  1. Periksa endpoint target tertentu dalam proxy API tempat Anda mengamati error ini dan catat nama host server backend:

    Contoh TargetEndpoint:

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

    Pada contoh di atas, nama host server backend adalah backend.company.com.

  2. Tentukan FQDN di sertifikat server backend menggunakan perintah openssl seperti yang ditunjukkan di bawah ini:

    openssl s_client -connect BACKEND_SERVER_HOST_NAME>:PORT_#>

    Contoh:

    openssl s_client -connect backend.company.com:443

    Periksa bagian Certificate chain dan catat FQDN yang ditentukan sebagai bagian dari CN dalam subjek leaf certificate. 

    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

    Pada contoh di atas, FQDN server backend adalah backend.apigee.net.

  3. Jika nama host server backend yang diperoleh dari langkah 1 dan FQDN yang diperoleh langkah 2 tidak cocok, berarti itulah penyebab error.
  4. Pada contoh yang dibahas di atas, nama host di endpoint target adalah backend.company.com. Namun, nama FQDN di sertifikat server backend adalah backend.apigee.net. Karena tidak cocok, Anda mendapatkan error ini.

Resolusi

Anda dapat memperbaiki masalah ini menggunakan salah satu metode berikut:

FQDN yang benar

Perbarui keystore server backend dengan FQDN yang benar, rantai sertifikat yang valid dan lengkap:

  1. Jika Anda tidak memiliki sertifikat server backend dengan FQDN yang benar, dapatkan sertifikat yang tepat dari CA (Certificate Authority) yang sesuai.

  2. Pastikan Anda memiliki rantai sertifikat server backend yang valid dan lengkap.

  3. Setelah Anda memiliki rantai sertifikat yang valid dan lengkap dengan FQDN server backend yang benar di sertifikat leaf atau entity yang identik dengan nama host yang ditentukan dalam endpoint target, perbarui keystore backend dengan rantai sertifikat yang lengkap.

Server backend yang benar

Perbarui endpoint target dengan nama host server backend yang benar:

  1. Jika nama host salah ditentukan di endpoint target, perbarui endpoint target agar memiliki nama host yang benar dan cocok dengan FQDN di sertifikat server backend.

  2. Simpan perubahan pada proxy API.

    Dalam contoh yang dibahas di atas, jika nama host server backend tidak ditentukan dengan benar, Anda dapat memperbaikinya menggunakan FQDN dari sertifikat server backend, yaitu backend.apigee.net seperti berikut:

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

Penyebab: Sertifikat atau rangkaian sertifikat salah/tidak lengkap yang ditampilkan oleh server backend

Diagnosis

  1. Dapatkan rantai sertifikat server backend dengan menjalankan perintah openssl terhadap nama host server backend sebagai berikut: 
    openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#

    Catat Certificate chain dari output perintah di atas.

    Contoh Rantai Sertifikat server backend dari output perintah openssl:

    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. Pastikan Anda memiliki rantai sertifikat yang benar dan lengkap seperti yang dijelaskan dalam Memvalidasi rantai sertifikat.

  3. Jika Anda tidak memiliki rantai sertifikat yang valid dan lengkap untuk server backend, maka itulah penyebab masalah ini.

    Dalam rantai sertifikat server backend contoh yang ditunjukkan di atas, root certificate tidak ada. Oleh karena itu, Anda mendapatkan error ini.

Resolusi

Perbarui keystore server backend dengan rantai sertifikat yang valid dan lengkap:

  1. Validasikan bahwa Anda memiliki rantai sertifikat server backend yang valid dan lengkap.

  2. Perbarui rantai sertifikat yang valid dan lengkap di keystore server backend.

Jika masalah masih berlanjut, buka Harus mengumpulkan informasi diagnostik.

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut dan hubungi Dukungan Apigee Edge:

  • Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:
    • Nama organisasi
    • Nama lingkungan
    • Nama Proxy API
    • Selesaikan perintah curl untuk memunculkan kembali error
    • File rekaman aktivitas yang menunjukkan error

    • Output perintah openssl:

      openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#

    • Paket TCP/IP yang ditangkap di server backend
  • Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
    • Pesan error lengkap yang diamati
    • Paket proxy API
    • File rekaman aktivitas yang menunjukkan error
    • Log Pemroses Pesan /opt/apigee/var/log/edge-message-processor/logs/system.log
    • Output perintah openssl:
      openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#
    • Paket TCP/IP yang ditangkap di server backend atau Prosesor Pesan.
    • Output dari Get all certificate for a keystore atau truststore API dan juga detail setiap sertifikat yang diperoleh menggunakan Get Cert Details from a Keystore atau Truststore API.

Referensi