Permintaan 400 Buruk - Kesalahan Sertifikat SSL

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

Gejala

Aplikasi klien menerima respons HTTP 400 - Bad request dengan pesan "The SSL certificate error". Error ini biasanya dikirim oleh Router Edge dengan penyiapan TLS dua cara yang diaktifkan 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:

<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 Berlaku Untuk
Sertifikat klien sudah tidak berlaku Masa berlaku sertifikat yang dikirim oleh klien sudah berakhir. Pengguna Cloud Pribadi dan Publik Edge
Sertifikat yang Salah dikirim oleh Klien Error ini ditampilkan jika sertifikat yang dikirim oleh aplikasi klien tidak cocok dengan sertifikat yang disimpan di truststore Router Edge. Pengguna Cloud Pribadi dan Publik Edge
Tidak ada Client Root Cert di Truststore Error ini ditampilkan jika root certificate yang ditandatangani CA klien tidak ada di truststore router Edge. Pengguna Cloud Pribadi dan Publik Edge
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: Sertifikat Klien Habis Masa Berlaku

Masalah ini biasanya terjadi pada TLS 2 Arah, saat masa berlaku sertifikat yang dikirim oleh klien sudah berakhir. Pada 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 diterapkan pada host virtual, tempat sertifikat server ditambahkan ke Keystore dan sertifikat klien ditambahkan ke truststore.

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

Diagnosis

  1. Login ke UI Edge dan lihat konfigurasi Virtual Host tertentu (Admin > Virtual Hosts) tempat permintaan API dibuat, atau gunakan API pengelolaan Get virtual host API untuk mendapatkan definisi Virtual Host 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 di Host Virtual. Dalam contoh di atas, nama referensi Truststore adalah myTruststoreRef.

  3. Menentukan Truststore yang ditunjuk oleh referensi Truststore.
    1. Di UI Edge, buka Admin > Environments > References dan telusuri nama referensi Truststore.

    2. Perhatikan nama di kolom Reference untuk referensi Truststore tertentu. 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 > Environments > 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 ini:

    Gambar 2

    Sertifikat dengan alias client-cert-markw dalam contoh di atas, menunjukkan bahwa sertifikat tersebut sudah tidak berlaku.

  6. Periksa apakah masa berlaku sertifikat untuk alias sertifikat truststore Anda telah berakhir.
  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 trustore yang digunakan dalam Host Virtual tertentu agar mengarah ke truststore baru menggunakan langkah-langkah yang dijelaskan dalam Mengubah referensi.

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

Langkah Diagnosis Umum untuk Penyebab Lain

  1. Untuk menyelidiki masalah ini, Anda harus mengambil 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 Cloud Publik, rekam paket TCP/IP di aplikasi klien.

    3. Setelah menentukan 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 pada Router, gunakan alamat IP publik aplikasi klien dalam perintah tcpdump.

      Jika Anda mengambil paket TCP/IP pada aplikasi klien, gunakan alamat IP publik dari 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 ketahui.

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

  1. Paket #30 dalam tcpdump (gambar di bawah) menunjukkan bahwa Aplikasi Klien (sumber) mengirim pesan"Client Hello" ke Router (destination).
  2. Paket #34 menunjukkan bahwa {i>Router<i} mengakui pesan {i>Client Hello<i} dari aplikasi klien.
  3. Router mengirimkan "Server Hello" pada paket #35, kemudian mengirimkan sertifikatnya serta meminta aplikasi klien untuk mengirim sertifikatnya dalam paket #38.
  4. Di paket #38, tempat Router mengirim paket "Certificate Request", periksa bagian "Distinguished Names" yang memberikan detail tentang sertifikat klien, rantainya, dan certificate authority yang diterima oleh Router (server).
    5. Gambar 3

  5. Aplikasi klien mengirimkan sertifikatnya di Paket # 41. Periksa bagian Certificate Verify pada paket # 41 dan tentukan sertifikat yang dikirim oleh aplikasi klien.

    Gambar 4
  6. Verifikasi apakah subjek dan penerbit sertifikat serta rantainya yang dikirim oleh aplikasi klien (paket #41) cocok dengan sertifikat yang diterima dan rantainya dari Router (paket #38). Jika ada ketidakcocokan, maka itulah penyebab error ini. Oleh karena itu, Router (Server) mengirimkan Pemberitahuan Terenkripsi (paket #57) yang 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.

Penyebab: Sertifikat salah 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 Virtual Host tertentu (Admin > Virtual Hosts) tempat permintaan API dibuat, atau gunakan API pengelolaan Get virtual host API untuk mendapatkan definisi Virtual Host 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 di 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 > Environments References dan telusuri nama referensi Truststore.

    2. Perhatikan nama di kolom Reference untuk referensi Truststore tertentu. Ini akan menjadi nama Truststore Anda.

      UI Edge yang menunjukkan referensi truststore.
      Gambar 5

      Pada 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. Cantumkan 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 serta rantainya yang disimpan di myCompanyTruststore cocok dengan yang ada pada sertifikat dan rantainya seperti yang terlihat dalam 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 Router Edge.
  6. Jika tidak ditemukan ketidakcocokan di Langkah #5, berarti aplikasi klien tidak mengirimkan Sertifikat yang tepat dan rantainya.

Resolusi

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

Penyebab: Root Certificate Klien Tidak Ada di Truststore

Error ini ditampilkan jika root certificate 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 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 di host virtual. Dalam contoh sebelumnya, nama referensi truststore adalah myCompanyTruststoreRef.
  3. Menentukan 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 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 untuk memastikan apakah sertifikat menyertakan rantai lengkap, termasuk root certificate yang dikirim oleh klien tertentu, seperti yang terlihat dalam Paket TCP/IP (lihat Gambar 4). Truststore harus menyertakan root certificate serta leaf certificate atau leaf dan intermediate certificate klien. Jika root certificate klien yang valid tidak ada di truststore, itulah penyebab error.

    Namun, jika rantai sertifikat lengkap klien, termasuk root certificate, ada di truststore, hal ini menunjukkan bahwa sertifikat yang diupload ke truststore mungkin tidak dimuat di Router Edge. Jika demikian, 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 Edge Router

  1. Jika Anda adalah pengguna Public Cloud, hubungi Dukungan Apigee Edge.
  2. Jika Anda adalah pengguna Private Cloud, ikuti petunjuk di bawah untuk setiap Router:
    1. Periksa apakah file /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem ada untuk host virtual tertentu. Jika file tidak ada, pindahkan ke bagian Resolution di bawah.
    2. Jika file tersebut 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 dari hal tersebut tidak sesuai dengan apa yang diamati di Truststore di UI Edge atau menggunakan API pengelolaan, berarti itulah yang menyebabkan 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 Mengumpulkan Informasi Diagnostik.

Mengumpulkan Informasi Diagnostik

Jika masalah terus 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 ditangkap di Aplikasi Klien
  2. Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
    1. Virtual Host Name dan definisinya menggunakan Get virtual host API
    2. Nama Alias Host
    3. Pesan Error Lengkap yang diamati
    4. Paket TCP/IP yang ditangkap pada Aplikasi Klien atau {i>Router<i}.
    5. Output List the certificate from the keystore API API dan juga detail setiap Sertifikat yang diperoleh menggunakan Get cert details API.
  3. Detail tentang bagian mana saja dalam Playbook ini yang telah Anda coba dan insight lain yang akan membantu kami menyelesaikan masalah ini.