Permintaan 400 Buruk - Kesalahan Sertifikat SSL

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

Gejala

Aplikasi klien menerima respons HTTP 400 - Permintaan buruk dengan pesan "Error sertifikat SSL". Error ini biasanya dikirim oleh Edge Router dalam penyiapan TLS dua arah yang diaktifkan untuk koneksi masuk ke Apigee Edge.

Pesan Error

Aplikasi Klien mendapatkan kode respons berikut:

HTTP/1.1 400 Bad Request

Diikuti dengan halaman error HTML di bawah:

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

Kemungkinan Penyebab

Kemungkinan penyebab masalah ini adalah sebagai berikut:

Cause Deskripsi Petunjuk Pemecahan Masalah yang Berlaku Untuk
Sertifikat klien yang sudah tidak berlaku Masa berlaku sertifikat yang dikirim oleh klien sudah berakhir. Pengguna Edge Private dan Public Cloud
Sertifikat Salah yang Dikirim oleh Klien Error ini akan ditampilkan jika sertifikat yang dikirim oleh aplikasi klien tidak cocok dengan sertifikat yang disimpan di truststore Router Edge. Pengguna Edge Private dan Public Cloud
Sertifikat Root Klien Tidak Ada di Truststore Error ini ditampilkan jika sertifikat root yang ditandatangani CA klien tidak ada di truststore router Edge. Pengguna Edge Private dan Public Cloud
Sertifikat Klien tidak dimuat di Edge Router Error ini ditampilkan jika sertifikat klien yang diupload ke truststore tidak dimuat di Router. Pengguna Edge Private Cloud

Penyebab: Masa Berlaku Sertifikat Klien Habis

Masalah ini biasanya terjadi pada TLS 2 Arah, saat sertifikat yang dikirim oleh klien sudah habis masa berlakunya. Dalam TLS 2 arah, klien dan server bertukar sertifikat publik mereka untuk menyelesaikan handshake. Klien memvalidasi sertifikat server dan server memvalidasi sertifikat klien.

Di Edge, TLS 2 arah diimplementasikan di host virtual, dengan sertifikat server ditambahkan ke Keystore dan sertifikat klien ditambahkan ke truststore.

Selama handshake TLS, jika ditemukan bahwa sertifikat klien telah habis masa berlakunya, server akan mengirim 400 - Permintaan salah dengan pesan "Error sertifikat SSL".

Diagnosis

  1. Login ke Edge UI dan lihat konfigurasi Virtual Host tertentu (Admin > Virtual Host) tempat permintaan API dibuat, atau gunakan Get virtual host API API pengelolaan untuk mendapatkan definisi Virtual Host tertentu.

    Biasanya, host virtual untuk komunikasi TLS dua arah terlihat sebagai berikut:

    <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. Tentukan referensi Truststore yang digunakan di Host Virtual. Dalam contoh di atas, nama referensi Truststore adalah myTruststoreRef.

  3. Tentukan Truststore yang ditunjuk oleh referensi Truststore.
    1. Di UI Edge, buka Admin > Environments > References dan cari nama referensi Truststore.
    2. Catat nama di kolom Reference untuk referensi Truststore tertentu. Ini akan menjadi nama Truststore Anda.

      UI Edge yang menampilkan daftar
                                                             referensi
      Gambar 1

      Dalam contoh di atas, perhatikan bahwa myTruststoreRef memiliki referensi ke myTruststore. Oleh karena itu, nama Truststore adalah myTruststore.

  4. Di Admin > Lingkungan > TLS Keystores di UI Edge, buka TLS Keystores dan cari Truststore yang ditemukan di langkah # 3.
  5. Pilih sertifikat di bagian Truststore tertentu (ditentukan pada langkah #3 di atas) seperti yang ditunjukkan di bawah:

    Gambar 2

    Sertifikat dengan alias client-cert-markw dalam contoh di atas menunjukkan bahwa masa berlakunya telah berakhir.

  6. Periksa apakah masa berlaku sertifikat untuk alias sertifikat di truststore Anda sudah habis.
  7. Jika sertifikat belum habis masa berlakunya, lanjutkan ke Langkah-Langkah Diagnostik Umum untuk Penyebab lainnya.

Resolusi

Dapatkan sertifikat baru dan upload sertifikat:

  1. Buat truststore baru, misalnya myNewTruststore.
  2. Upload sertifikat baru ke truststore yang baru dibuat.
  3. Ubah referensi trustore yang digunakan di Virtual Host tertentu agar mengarah ke trustore baru menggunakan langkah-langkah yang diberikan di Mengubah referensi.

    Dalam contoh yang dijelaskan di atas, arahkan referensi myTruststoreRef ke myNewTruststore.

Langkah-Langkah Diagnostik Umum untuk Penyebab Lainnya

  1. Untuk menyelidiki masalah ini, Anda perlu merekam paket TCP/IP menggunakan alat tcpdump.
    1. Jika Anda adalah pengguna Private Cloud, Anda dapat merekam paket TCP/IP di aplikasi klien atau Router.
    2. Jika Anda adalah pengguna Public Cloud, ambil paket TCP/IP di aplikasi klien.
    3. Setelah Anda memutuskan tempat untuk merekam paket TCP/IP, gunakan perintah tcpdump berikut untuk merekam paket TCP/IP:

      tcpdump -i any -s 0 host <IP address> -w <File name>

      Catatan: Jika Anda mengambil paket TCP/IP di Router, gunakan alamat IP publik aplikasi klien dalam perintah tcpdump.

      Jika Anda mengambil paket TCP/IP di aplikasi klien, gunakan alamat IP publik nama host yang digunakan di Host Virtual dalam perintah tcpdump.

      Lihat tcpdump untuk mengetahui informasi selengkapnya tentang alat ini dan varian lain dari perintah ini.

  2. Analisis paket TCP/IP yang dikumpulkan menggunakan alat Wireshark atau alat serupa yang Anda kuasai.

Berikut analisis data paket TCP/IP contoh menggunakan alat Wireshark:

  1. Paket #30 di tcpdump (gambar di bawah) menunjukkan bahwa Aplikasi Klien (sumber) mengirim pesan "Client Hello" ke Router (tujuan).
  2. Paket #34 menunjukkan bahwa Router mengonfirmasi pesan Client Hello dari aplikasi klien.
  3. Router mengirim "Server Hello" dalam paket #35, lalu mengirim sertifikatnya dan juga meminta aplikasi klien untuk mengirim sertifikatnya dalam paket #38.
  4. Dalam paket #38, saat Router mengirimkan paket "Permintaan Sertifikat", periksa bagian "Nama Khusus" yang memberikan detail tentang sertifikat klien, rantainya, dan otoritas sertifikat yang diterima oleh Router (server).
  5. Gambar 3
  6. Aplikasi klien mengirimkan sertifikatnya dalam Paket # 41. Periksa bagian Certificate Verify dalam paket # 41 dan tentukan sertifikat yang dikirim oleh aplikasi klien.

    Gambar 4
  7. Verifikasi apakah subjek dan penerbit sertifikat serta rantainya yang dikirim oleh aplikasi klien (paket #41) cocok dengan sertifikat dan rantainya yang diterima dari Router (paket #38). Jika ada ketidakcocokan, itulah penyebab error ini. Oleh karena itu, Router (Server) mengirimkan Encrypted Alert (paket #57) yang diikuti dengan FIN, ACK (paket 58) ke Aplikasi Klien dan akhirnya koneksi dihentikan.
  8. Ketidakcocokan sertifikat dan rantainya dapat disebabkan oleh skenario yang dijelaskan di bagian berikut.

Penyebab: Sertifikat salah yang dikirim oleh klien

Hal ini biasanya terjadi jika subjek/penerbit sertifikat dan/atau rantainya yang dikirim oleh aplikasi klien tidak cocok dengan sertifikat dan/atau rantainya yang disimpan di truststore Router (Server).

Diagnosis

  1. Login ke UI Edge dan lihat konfigurasi Host Virtual tertentu (Admin > Host Virtual) yang permintaan API-nya sedang dibuat, atau gunakan API Get virtual host API pengelolaan untuk mendapatkan definisi Host Virtual tertentu.

    Biasanya, host virtual untuk komunikasi TLS dua arah terlihat sebagai berikut:

        <VirtualHost name="myTLSVHost">
            <HostAliases>
                <HostAlias>api.myCompany.com</HostAlias>
            </HostAliases>
            <Port>443</Port>
            <SSLInfo>
                <Enabled>true</Enabled>
                <ClientAuthEnabled>true</ClientAuthEnabled>
                <KeyStore>ref://myKeystoreRef</KeyStore>
                <KeyAlias>myKeyAlias</KeyAlias>
                    <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
            </SSLInfo>
        </VirtualHost>
  2. Tentukan referensi Truststore yang digunakan di Host Virtual.

    Pada contoh di atas, nama referensi Truststore adalah myCompanyTruststoreRef.

  3. Tentukan Truststore yang ditunjukkan oleh referensi Truststore.
    1. Di UI Edge, buka Admin > Environment References dan cari nama referensi Truststore.
    2. Catat nama di kolom Reference untuk referensi Truststore tertentu. Ini akan menjadi nama Truststore Anda.

      UI Edge yang menampilkan
        referensi truststore.
      Gambar 5

      Dalam contoh di atas, perhatikan bahwa myCompanyTruststoreRef memiliki referensi ke myCompanyTruststore. Oleh karena itu, nama Truststore adalah myCompanyTruststore.

  4. Dapatkan sertifikat yang disimpan di Truststore (ditentukan pada langkah sebelumnya) menggunakan API berikut:
    1. Mencantumkan sertifikat untuk API keystore atau truststore.

      API ini mencantumkan semua sertifikat di Truststore tertentu.

    2. Mendapatkan detail sertifikat dari API keystore atau truststore.

      API ini menampilkan informasi tentang sertifikat tertentu di Truststore tertentu.

  5. Periksa apakah penerbit dan subjek setiap sertifikat dan rantainya yang disimpan di myCompanyTruststore cocok dengan sertifikat dan rantainya seperti yang terlihat di Paket TCP/IP (lihat paket #38) di atas. Jika ada ketidakcocokan, hal ini menunjukkan bahwa sertifikat yang diupload ke truststore tidak dimuat di Edge Router. Lanjutkan ke Penyebab: Sertifikat Klien tidak dimuat di Edge Router.
  6. Jika tidak ada ketidakcocokan yang ditemukan pada Langkah #5, berarti aplikasi klien tidak mengirimkan Sertifikat dan rantainya yang benar.

Resolusi

Pastikan sertifikat yang benar dan rantainya dikirim oleh aplikasi klien ke Edge.

Penyebab: Tidak Ada Sertifikat Root Klien di Truststore

Error ini ditampilkan jika sertifikat root yang ditandatangani CA klien tidak ada di truststore router Edge.

Diagnosis

  1. Login ke UI Edge dan lihat konfigurasi host virtual tertentu yang digunakan untuk membuat permintaan API (Admin > Host Virtual > virtual_host), atau gunakan Get virtual host API untuk mendapatkan definisi host virtual tertentu.

    Biasanya, host virtual untuk komunikasi TLS dua arah terlihat sebagai berikut:

        <VirtualHost name="myTLSVHost">
            <HostAliases>
                <HostAlias>api.myCompany.com</HostAlias>
            </HostAliases>
            <Port>443</Port>
            <SSLInfo>
                <Enabled>true</Enabled>
                <ClientAuthEnabled>true</ClientAuthEnabled>
                <KeyStore>ref://myKeystoreRef</KeyStore>
                <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
            </SSLInfo>
        </VirtualHost>
  2. Tentukan referensi truststore yang digunakan di host virtual. Pada contoh sebelumnya, nama referensi truststore adalah myCompanyTruststoreRef.
  3. Tentukan truststore sebenarnya yang digunakan oleh referensi truststore.
  4. Di UI Edge, buka Admin > Environments > References dan cari nama referensi truststore.
  5. Nama truststore untuk referensi truststore tertentu ada di kolom Reference.

    Gambar 6

    Dalam contoh ini, perhatikan bahwa myCompanyTruststoreRef memiliki myCompanyTruststore di kolom Referensi. Oleh karena itu, nama truststore adalah myCompanyTruststore.

  6. Dapatkan sertifikat yang disimpan di truststore (ditentukan pada langkah sebelumnya) menggunakan API berikut:
    1. Mencantumkan sertifikat untuk API keystore atau truststore. API ini mencantumkan semua sertifikat di truststore.
    2. Mendapatkan detail sertifikat dari API keystore atau truststore. API ini menampilkan informasi tentang sertifikat tertentu di truststore.
  7. Periksa apakah sertifikat menyertakan rantai lengkap, termasuk sertifikat root yang dikirim oleh klien tertentu seperti yang terlihat dalam Paket TCP/IP (lihat Gambar 4). Truststore harus menyertakan sertifikat root serta sertifikat entitas akhir klien atau sertifikat entitas akhir dan intermediate certificate. Jika sertifikat root valid klien tidak ada di truststore, itulah penyebab errornya.

    Namun, jika rantai sertifikat lengkap klien, termasuk sertifikat root, ada di truststore, hal ini menunjukkan bahwa sertifikat yang diupload ke truststore mungkin tidak dimuat di Edge Router. Jika demikian, lihat Penyebab: Sertifikat Klien tidak dimuat di Edge Router.

Resolusi

Pastikan sertifikat klien yang benar, termasuk root certificate, tersedia di truststore router Apigee Edge.

Penyebab: Sertifikat Klien tidak dimuat di Edge Router

  1. Jika Anda adalah pengguna Public Cloud, hubungi Dukungan Apigee Edge.
  2. Jika Anda adalah pengguna Private Cloud, ikuti petunjuk di bawah ini di setiap Router:
    1. Periksa apakah file /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem ada untuk host virtual tertentu. Jika file tidak ada, lanjutkan ke bagian Penyelesaian di bawah.
    2. Jika file ada, gunakan perintah openssl di bawah untuk mendapatkan detail sertifikat yang tersedia di Edge Router:
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. Periksa penerbit, subjek, dan tanggal habis masa berlaku sertifikat. Jika salah satu di antaranya tidak cocok dengan yang diamati di Truststore di Edge UI atau menggunakan API pengelolaan, maka itulah penyebab error.
    4. Router mungkin tidak memuat ulang sertifikat yang diupload.

Resolusi

Mulai ulang Router untuk memastikan Sertifikat terbaru dimuat menggunakan langkah di bawah:

apigee-service edge-router restart

Jalankan kembali API dan periksa hasilnya. Jika masalah berlanjut, buka Mengumpulkan Informasi Diagnostik.

Mengumpulkan Informasi Diagnostik

Jika masalah berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut. Hubungi dan bagikan informasi yang Anda kumpulkan kepada Dukungan Apigee Edge:

  1. Jika Anda adalah pengguna Public Cloud, berikan informasi berikut:
    1. Nama Organisasi
    2. Nama Lingkungan
    3. Nama Proxy API
    4. Nama Host Virtual
    5. Nama Alias Host
    6. Perintah curl lengkap untuk mereproduksi error
    7. Paket TCP/IP yang diambil di Aplikasi Klien
  2. Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
    1. Nama Host Virtual dan definisinya menggunakan Get virtual host API
    2. Nama Alias Host
    3. Pesan Error Lengkap yang diamati
    4. Paket TCP/IP yang direkam di Aplikasi Klien atau Router.
    5. Output List the certificates from the keystore API API dan juga detail setiap Sertifikat yang diperoleh menggunakan Get cert details API.
  3. Detail tentang bagian mana dalam Playbook ini yang telah Anda coba dan insight lain yang akan membantu kami mempercepat penyelesaian masalah ini.