Permintaan 400 Buruk - Kesalahan Sertifikat SSL

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

ini.

Gejala

Aplikasi klien menerima respons HTTP 400 - Permintaan buruk dengan pesan "The SSL certificate error". Error ini biasanya dikirimkan oleh Router Edge dengan pengaturan TLS dua arah untuk koneksi masuk ke Apigee Edge.

Pesan Error

Aplikasi Klien mendapatkan kode respons berikut:

HTTP/1.1 400 Bad Request

Diikuti oleh halaman error HTML di bawah ini:

<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
Sertifikat klien sudah tidak berlaku Masa berlaku sertifikat yang dikirim oleh klien telah berakhir. Pengguna Edge Private Cloud dan Public Cloud
Sertifikat Salah yang dikirim oleh Klien Error ini ditampilkan jika sertifikat yang dikirim oleh aplikasi klien tidak cocok dengan sertifikat yang disimpan di truststore Router Edge. Pengguna Edge Private Cloud dan Public Cloud
Sertifikat Root Klien tidak ada di Truststore Error ini ditampilkan jika root certificate klien yang ditandatangani CA tidak ada di bagian {i>truststore<i} dari {i>router<i} Edge. Pengguna Edge Private Cloud dan Public Cloud
Sertifikat Klien tidak dimuat di Router Edge Error ini ditampilkan jika sertifikat klien yang diupload ke truststore tidak dimuat di {i>Router<i}. Pengguna Edge Private Cloud

Penyebab: Sertifikat Klien Kedaluwarsa

Masalah ini biasanya terjadi untuk TLS 2 Arah, saat sertifikat yang dikirim oleh klien kedaluwarsa. Pada TLS 2 arah, baik klien maupun server bertukar sertifikat publik mereka untuk berjabatan tangan. Klien memvalidasi sertifikat server dan server memvalidasi sertifikat klien.

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

Selama TLS handshake jika ditemukan bahwa sertifikat klien kedaluwarsa, maka server akan mengirim 400 - Bad request dengan pesan "The SSL certificate error".

Diagnosis

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

    Biasanya host virtual untuk komunikasi TLS dua arah terlihat seperti 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. Menentukan referensi Truststore yang digunakan dalam Host Virtual. Dalam contoh di atas, nama referensi Truststore adalah myTruststoreRef.

  3. Menentukan Truststore yang ditunjukkan oleh referensi Truststore.
    1. Di UI Edge, buka Admin > Lingkungan > Referensi dan cari nama referensi Truststore.

    2. Catat nama di kolom Reference untuk referensi Truststore tertentu. Nama ini akan menjadi nama Truststore Anda.

      UI Edge yang menampilkan daftar referensi
      Gambar 1

      Pada 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 Keystore dan cari Truststore yang ditemukan di langkah # 3.

  5. Pilih sertifikat di bawah Truststore tertentu (ditentukan pada langkah #3 di atas) seperti yang ditunjukkan di bawah:

    Gambar 2

    Sertifikat dengan alias client-cert-markw di contoh di atas, menunjukkan bahwa sertifikat kedaluwarsa.

  6. Periksa apakah masa berlaku sertifikat habis untuk alias sertifikat untuk truststore Anda.
  7. Jika masa berlaku sertifikat belum berakhir, lanjutkan ke Langkah-Langkah Diagnosis Umum untuk Penyebab lainnya.

Resolusi

Dapatkan sertifikat baru dan upload sertifikatnya:

  1. Buat truststore baru, misalnya myNewTruststore.
  2. Upload sertifikat baru ke truststore yang baru dibuat.

  3. Ubah referensi wali yang digunakan dalam Host Virtual tertentu agar mengarah ke versi baru truststore menggunakan langkah-langkah yang Mengubah referensi.

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

Langkah Diagnosis Umum untuk Penyebab Lainnya

  1. Untuk menyelidiki masalah ini, Anda harus menangkap paket TCP/IP menggunakan tcpdump.
    1. Jika Anda adalah pengguna Private Cloud, Anda dapat menangkap paket TCP/IP di aplikasi klien, atau {i>Router<i}.
    2. Jika Anda adalah pengguna Cloud Publik, tangkap paket TCP/IP di aplikasi klien.

    3. Setelah Anda memutuskan di mana Anda ingin menangkap paket TCP/IP, gunakan tcpdump perintah untuk menangkap 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 pada aplikasi klien, maka gunakan IP publik dari nama host yang digunakan dalam Host Virtual di perintah tcpdump.

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

  2. Analisis paket TCP/IP yang dikumpulkan menggunakan Tool Wireshark atau alat serupa yang sudah Anda pahami.

Berikut adalah analisis sampel data paket TCP/IP menggunakan alat Wireshark:

  1. Paket #30 dalam {i>tcpdump<i} (gambar di bawah) menunjukkan bahwa Aplikasi Klien (sumber) mengirim "Client Hello" ke Router (tujuan).
  2. Paket #34 menunjukkan bahwa Router menerima pesan Client Hello dari aplikasi klien.
  3. {i>Router<i} mengirimkan {i>“Server Hello<i}” dalam paket #35 dan kemudian mengirimkan sertifikatnya dan juga meminta aplikasi klien untuk mengirimkan sertifikatnya dalam paket #38.
  4. Dalam paket #38, tempat Router mengirimkan paket "Permintaan Sertifikat", periksa "Nama yang Dibedakan" bagian yang memberikan detail tentang sertifikat klien, rantainya dan otoritas sertifikat yang diterima oleh {i>Router<i} (server).
    5. Gambar 3

  5. Aplikasi klien mengirimkan sertifikatnya dalam Paket # 41. Periksa Sertifikat Verifikasi bagian dalam paket # 41 dan tentukan sertifikat yang dikirim oleh aplikasi klien.

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

Penyebab: Sertifikat salah yang dikirim oleh klien

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

Diagnosis

  1. Login ke UI Edge dan melihat konfigurasi Virtual Host tertentu (Admin > Host Virtual) yang menerima permintaan API dibuat, atau menggunakan Get virtual host API API untuk mendapatkan definisi Host Virtual tertentu.

    Biasanya host virtual untuk komunikasi TLS dua arah terlihat seperti 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. Menentukan referensi Truststore yang digunakan dalam Host Virtual.

    Dalam contoh di atas, nama referensi Truststore adalah myCompanyTruststoreRef.

  3. Menentukan Truststore yang ditunjukkan oleh referensi Truststore.
    1. Di UI Edge, buka Admin > Referensi Lingkungan dan cari nama referensi Truststore.

    2. Catat nama di kolom Reference untuk referensi Truststore tertentu. Nama ini akan menjadi nama Truststore Anda.

      UI tepi yang menampilkan referensi truststore.
      Gambar 5

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

  4. Dapatkan sertifikat yang disimpan di Truststore (ditentukan di langkah sebelumnya) menggunakan API berikut:

    1. Mencantumkan sertifikat untuk keystore atau truststore API.

      API ini mencantumkan semua sertifikat di Truststore tertentu.

    2. Dapatkan detail sertifikat dari keystore atau truststore API.

      API ini menampilkan informasi tentang sertifikat tertentu di Truststore tertentu.

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

Resolusi

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

Penyebab: Sertifikat Root Klien tidak ada di Truststore

Error ini ditampilkan jika root certificate klien yang ditandatangani CA tidak ada di bagian {i>truststore<i} dari {i>router<i} Edge.

Diagnosis

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

    Biasanya host virtual untuk komunikasi TLS dua arah terlihat seperti 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 dalam host virtual. Pada contoh sebelumnya, nama referensi truststore adalah myCompanyTruststoreRef.
  3. Menentukan truststore sebenarnya yang digunakan oleh referensi truststore.
  4. Pada UI Edge, arahkan ke Admin > Lingkungan > Referensi dan penelusuran untuk nama referensi truststore.

  5. Nama truststore untuk referensi truststore tertentu ada dalam kolom Reference.

    Gambar 6

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

  6. Dapatkan sertifikat yang disimpan di truststore (ditentukan pada langkah sebelumnya) menggunakan API berikut:
    1. Mencantumkan sertifikat untuk keystore atau truststore API. API ini mencantumkan semua sertifikat di truststore.
    2. Dapatkan detail sertifikat dari keystore atau truststore API. API ini menampilkan informasi tentang sertifikat tertentu di truststore.

  7. Periksa apakah sertifikat menyertakan rantai lengkap, termasuk root certificate dikirim oleh klien spesifik seperti yang terlihat dalam Paket TCP/IP (lihat Gambar 4). Truststore harus menyertakan sertifikat root atau sertifikat entitas akhir klien, dan perantara. Jika sertifikat {i>root<i} klien yang valid tidak ada di truststore, itulah penyebab error.

    Namun, jika rantai sertifikat klien yang lengkap, termasuk {i>root certificate<i}, ada di truststore, maka itu menunjukkan bahwa sertifikat yang diunggah ke truststore mungkin tidak dimuat di Router Edge. Jika begitu, lihat Penyebab: Sertifikat Klien tidak dimuat di Router Edge.

Resolusi

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

Penyebab: Sertifikat Klien tidak dimuat di Router Edge

  1. Jika Anda adalah pengguna Cloud Publik, hubungi Dukungan Apigee Edge.
  2. Jika Anda adalah pengguna Private Cloud, ikuti petunjuk di bawah di setiap Router:
    1. Periksa apakah file /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem ada untuk {i>host<i} virtual tertentu. Jika file tidak ada, pindahkan ke Penyelesaian di bawah.
    2. Jika file tersebut ada, gunakan perintah openssl di bawah untuk mendapatkan detail sertifikat yang tersedia di Router Edge: 
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. Periksa penerbit, subjek, dan tanggal habis masa berlaku sertifikat. Jika salah satunya tidak sesuai dengan apa yang diamati di Truststore di UI Edge atau menggunakan API manajemen, maka itulah penyebab error.
    4. Ada kemungkinan Router 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 Kumpulkan Informasi Diagnostik.

Kumpulkan 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 Cloud Publik, berikan informasi berikut:
    1. Nama Organisasi
    2. Nama Lingkungan
    3. Nama Proxy API
    4. Nama Host Virtual
    5. Nama Alias Host
    6. Menyelesaikan perintah curl untuk mereproduksi error
    7. Paket TCP/IP yang direkam pada Aplikasi Klien
  2. Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
    1. Nama Host Virtual dan definisinya menggunakan Dapatkan API host virtual
    2. Nama Alias Host
    3. Pesan Error Lengkap diamati
    4. Paket TCP/IP yang direkam di {i>Router<i} atau Aplikasi Klien.
    5. Output Mencantumkan sertifikat dari API keystore API dan detail setiap Sertifikat yang diperoleh menggunakan Get cert cert details API.
  3. Detail tentang bagian mana saja dalam Playbook ini yang telah Anda coba dan wawasan lain yang akan membantu kami menyelesaikan masalah dengan cepat.