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 kegagalan selama proses handshake SSL antara Message Processor Apigee Edge dan server backend karena sejumlah alasan. Pesan error di faultstring biasanya menunjukkan kemungkinan penyebab tingkat tinggi yang menyebabkan error ini.

Bergantung pada pesan error yang diamati di faultstring, Anda harus menggunakan teknik yang sesuai 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 di faultstring.

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

  • Jika truststore Message Processor 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 yang salah/tidak lengkap di truststore Message Processor Sertifikat dan/atau rantainya yang disimpan di truststore Message Processor Apigee Edge tidak cocok dengan rantai sertifikat server backend atau tidak berisi rantai sertifikat lengkap server backend. Pengguna Edge Private dan Public Cloud
Ketidakcocokan FQDN di sertifikat server backend dan nama host di endpoint target Sertifikat yang ditampilkan oleh server backend berisi FQDN yang tidak cocok dengan nama host yang ditentukan di endpoint target. Pengguna Edge Private dan Public Cloud
Sertifikat atau rantai sertifikat yang salah/tidak lengkap yang ditampilkan oleh server backend Rantai sertifikat yang ditampilkan oleh server backend salah atau tidak lengkap. Pengguna Edge Private dan Public Cloud

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 Pemantauan API:

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

  2. Beralih ke organisasi tempat Anda ingin menyelidiki masalah.

  3. Buka halaman Analyze > API Monitoring > Investigate.
  4. Pilih jangka waktu tertentu saat Anda mengamati error.

  5. Petakan Kode Kesalahan terhadap Waktu.

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

    ( lihat gambar yang lebih besar)

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

    ( 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, catat detail berikut:
    • ID Pesan Permintaan
    • Kode Status: 503
    • Sumber Kesalahan: target
    • Kode Kesalahan: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

Prosedur #2: Menggunakan alat Trace

Untuk mendiagnosis error menggunakan alat Trace:

  1. Aktifkan sesi rekaman aktivitas dan salah satu dari
    • Tunggu hingga error 503 Service Unavailable dengan kode error messaging.adaptors.http.flow.SslHandshakeFailed terjadi, atau
    • Jika Anda dapat mereproduksi masalah, lakukan 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. Telusuri berbagai fase rekaman aktivitas dan temukan tempat terjadinya kegagalan.

  5. Anda biasanya akan menemukan error setelah fase Target Request Flow Started seperti yang ditunjukkan di bawah:

    ( 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 Direkam) dalam rekaman aktivitas, lalu klik.

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

    ( lihat gambar yang lebih besar)

  9. Catat 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 utama tentang 503 Service Unavailable HTTP.

  2. Periksa log akses NGINX:

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

  3. Cari untuk melihat apakah ada error 503 dengan kode error messaging.adaptors.http.flow.SslHandshakeFailed selama durasi tertentu (jika masalah terjadi di masa lalu) 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, maka tentukan nilai X-Apigee-fault-source.

    Contoh error 503 dari log akses NGINX:

    ( lihat gambar yang lebih besar)

    Entri contoh di atas dari log akses NGINX 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 Message Processor

Prosedur #4: Menggunakan Log Message Processor

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

  2. Cari 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 dengan pengecualian dengan stack trace mendetail seperti yang ditunjukkan di bawah:

    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 Negosiasi SSL gagal karena Message Processor Apigee Edge tidak dapat memvalidasi sertifikat server backend.

Penyebab: Sertifikat atau rantai sertifikat salah/tidak lengkap di truststore Message Processor

Diagnosis

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

Anda dapat men-debug masalah ini dalam dua fase:

  1. Tahap 1: Tentukan rantai sertifikat server backend
  2. Tahap 2: Bandingkan rantai sertifikat yang disimpan di truststore Message Processor

Fase 1

Tahap 1: Tentukan 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, ambil paket TCP/IP di server backend.
  2. Jika Anda adalah pengguna Private Cloud, Anda dapat merekam paket TCP/IP di server backend atau Message Processor. Sebaiknya, ambil di server backend saat 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 sudah Anda kuasai.

    Analisis Contoh 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 mengirimkan pesan Server Hello bersama dengan sertifikatnya.
    • Paket #46: Message Processor mengonfirmasi penerimaan pesan Server Hello dan sertifikat.

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

      Hal ini menunjukkan bahwa validasi sertifikat server backend oleh Message Processor gagal. Hal ini karena Message Processor tidak memiliki sertifikat yang cocok dengan sertifikat server backend atau tidak dapat memercayai sertifikat server backend dengan sertifikat yang tersedia di (Message Processor) truststore.

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

      ( lihat gambar yang lebih besar)

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

    Jika Anda telah memastikan bahwa validasi sertifikasi server gagal, maka buka Fase 2: Bandingkan sertifikat server backend dan sertifikat yang disimpan di truststore Message Processor.

Fase 2

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

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

    1. Dapatkan nama referensi truststore dari elemen TrustStore di bagian SSLInfo dalam 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. Catat nama di kolom Reference untuk referensi truststore tertentu. Nama ini akan menjadi nama truststore Anda.

      ( lihat gambar yang lebih besar)

    4. Dalam 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"

      Dalam hal ini:

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

      Contoh output:

      Sertifikat dari truststore contoh 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"

      Dalam hal ini:

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

      Contoh Output

      Detail serverCert menampilkan subjek dan penerbit sebagai berikut:

      Sertifikat Leaf/Entitas:

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

      Intermediate Certificate:

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

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

    1. Sertifikat leaf:

      Dari server backend:

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

      Dari truststore Message Processor (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 sertifikat server backend.

    2. Sertifikat perantara:

      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 Message Processor (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 sertifikat 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

      Sertifikat root benar-benar tidak ada di truststore Message Processor.

    4. Karena sertifikat root tidak ada di truststore, Message Processor 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 yang tepat dan lengkap dari server backend.
  2. Jika Anda adalah pengguna Public Cloud, ikuti petunjuk di Memperbarui sertifikat TLS untuk Cloud guna memperbarui 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 dalam sertifikat server backend dan nama host di endpoint target

Jika server backend menyajikan rantai sertifikat yang berisi FQDN, yang tidak cocok dengan nama host yang ditentukan di endpoint target, maka Pemrosesan 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 di proxy API tempat Anda melihat 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>

    Dalam 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:

    openssl s_client -connect BACKEND_SERVER_HOST_NAME>:PORT_#>

    Contoh:

    openssl s_client -connect backend.company.com:443

    Periksa bagian Certificate chain dan perhatikan FQDN yang ditentukan sebagai bagian dari CN di subjek sertifikat leaf. 

    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 dari langkah 2 tidak cocok, itulah penyebab errornya.
  4. Dalam contoh yang dibahas di atas, nama host di endpoint target adalah backend.company.com. Namun, nama FQDN dalam sertifikat server backend adalah backend.apigee.net. Karena tidak cocok, Anda akan 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, maka dapatkan sertifikat yang tepat dari CA (Certificate Authority) yang sesuai.

  2. Validasi bahwa 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 di endpoint target, perbarui keystore backend dengan rantai sertifikat 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 salah ditentukan, Anda dapat memperbaikinya dengan menggunakan FQDN dari sertifikat server backend, yaitu backend.apigee.net sebagai 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 rantai sertifikat yang 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 tepat 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. Pastikan 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 mereproduksi error
    • File rekaman aktivitas yang menunjukkan error

    • Output perintah openssl:

      openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#

    • Paket TCP/IP yang diambil 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 Message Processor /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 diambil di server backend atau Message Processor.
    • Output dari Get all certificates for a keystore or truststore API dan juga detail setiap sertifikat yang diperoleh menggunakan Get Cert Details from a Keystore or Truststore API.

Referensi