Layanan 503 Tidak Tersedia - Kegagalan Handshake SSL

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. Beralihlah ke organisasi tempat Anda ingin menyelidiki masalah tersebut.

   
3. Buka Analyze > Pemantauan API > Investigasi.
4. Pilih jangka waktu tertentu saat Anda melihat error.

5. Gambarkan Kode Kesalahan terhadap Waktu.

6. Pilih sel yang memiliki kode fault 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 sebagai yang ditampilkan di bawah ini:

   ( lihat gambar yang lebih besar)

   

8. Klik Lihat log , lalu 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

Trace

Prosedur #2: Menggunakan alat Rekaman Aktivitas

Untuk mendiagnosis error menggunakan alat Trace:

1. Aktifkan sesi rekaman aktivitas dan
   • Tunggu hingga error 503 Service Unavailable disertai 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 Tampilkan semua FlowInfos diaktifkan:

   
3. Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitasnya.
4. Menavigasi melalui berbagai fase pelacakan dan menemukan tempat terjadinya kegagalan.

5. Anda akan menemukan error ini, biasanya setelah fase Alur Permintaan Target Dimulai sebagaimana 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 Pemroses Pesan Apigee Edge tidak dapat memvalidasi CA {i>root<i}.
7. Buka Fase AX (Data Analytics Direkam) di rekaman aktivitas, lalu klik Fase tersebut.

8. Scroll ke bawah ke bagian Fase Details Error Headers dan tentukan 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:

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 apakah ada 503 error dengan kode error messaging.adaptors.http.flow.SslHandshakeFailed selama durasi tertentu (jika masalah terjadi di sudah lewat) atau jika ada permintaan yang masih gagal dengan 503.

4. Jika Anda menemukan error 503 dengan pencocokan X-Apigee-fault-code nilai messaging.adaptors.http.flow.SslHandshakeFailed, lalu 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 Trace, atau Log Akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum.

2. Menelusuri ID pesan permintaan tertentu di log Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log). Anda mungkin mengamati 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 di antara Pemroses Pesan dan server backend.

   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 Pemroses Pesan Apigee Edge tidak dapat memvalidasi sertifikat server backend.

Fase 1

Fase 1: Menentukan rantai sertifikat server backend

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

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

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

Fase 2

Tahap 2: Membandingkan sertifikat dan sertifikat server backend yang disimpan di Truststore Pemroses Pesan

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

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

      Mari kita lihat contoh bagian SSLInfo dalam TargetEndpoint konfigurasi:

      <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 > Referensi. Perhatikan nama dalam Kolom Reference untuk referensi truststore tertentu. Ini akan menjadi nama truststore.

      ( lihat gambar yang lebih besar)

      

   4. Dalam contoh di atas, nama truststore adalah:

      myCompanyTruststoreRef: myCompanyTruststore

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

   1. Dapatkan 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 lingkungan
      • KEYSTORE_NAME adalah nama keystore
      • $TOKEN disetel ke token akses OAuth 2.0 Anda seperti yang dijelaskan di Mendapatkan token akses OAuth 2.0
      • curl opsi yang digunakan dalam contoh ini dijelaskan di Menggunakan curl

      Contoh output:

      Sertifikat dari contoh truststore myCompanyTruststore adalah:

      [
        "serverCert"
      ]
      

   2. Dapatkan Detail Sertifikat untuk sertifikat tertentu dari Keystore atau Truststore. API ini menampilkan informasi tentang sertifikat tertentu dalam metode truststore.

      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 lingkungan
      • KEYSTORE_NAME adalah nama keystore
      • CERT_NAME adalah nama sertifikat
      • $TOKEN disetel ke token akses OAuth 2.0 Anda seperti yang dijelaskan di Mendapatkan token akses OAuth 2.0
      • curl opsi yang digunakan dalam contoh ini dijelaskan di Menggunakan curl

      Contoh Output

      Detail serverCert menampilkan subjek dan penerbit sebagai berikut:

      Sertifikat Daun Nest/Entitas:

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

      Sertifikat Menengah:

      "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 di langkah 1 dan sertifikat disimpan di truststore yang diperoleh pada langkah 3. Jika tidak cocok, maka itu adalah penyebab masalah tersebut.

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

   1. Sertifikat Daun Nest:

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

      leaf certificate yang disimpan di truststore cocok dengan backend server tertentu.

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

      {i>Root certificate<i} benar-benar hilang dalam Pemroses Pesan truststore.

   4. Karena {i>root certificate<i} tidak ada di {i>truststore<i}, maka Pemroses Pesan 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 kepada klien menggunakan berbagai aplikasi obrolan.

FQDN benar

Perbarui keystore server backend dengan FQDN yang benar, serta sertifikat yang valid dan lengkap jaringan bisnis:

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

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

3. Setelah Anda memiliki rantai sertifikat yang valid dan lengkap dengan FQDN yang benar dari server backend di leaf atau sertifikat entity yang identik dengan nama host yang ditentukan di endpoint target, update 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 metode endpoint target untuk memiliki nama host yang benar dan cocok dengan FQDN di backend sertifikat server.

2. Simpan perubahan pada proxy API.

   Dalam contoh yang dibahas di atas, jika nama {i>host<i} server backend salah tertentu, Anda dapat memperbaikinya dengan menggunakan {i>FQDN<i} dari sertifikat server {i>backend<i}, 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>