Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Opsi untuk mengonfigurasi TLS

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

Dokumen ini berisi ringkasan tentang cara mengonfigurasi TLS di Edge untuk dua area fungsional:

Akses ke proxy API Anda oleh klien API. Gunakan host virtual di Edge Router untuk mengonfigurasi TLS.
Akses ke layanan backend Anda oleh Edge. Gunakan endpoint target dan server target di Edge Message Processor untuk mengonfigurasi TLS.

Kedua jenis akses ini ditampilkan di bawah:

Tentang menetapkan opsi TLS di host virtual atau endpoint target/server target

Host virtual dapat direpresentasikan oleh objek XML, dalam bentuk:

<VirtualHost name="secure">
    ...
    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>true</ClientAuthEnabled> 
        <KeyStore>ref://myKeystoreRef</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
        <TrustStore>ref://myTruststoreRef</TrustStore> 
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
    </SSLInfo>
</VirtualHost>

Area host virtual yang Anda ubah untuk mengonfigurasi TLS ditentukan oleh tag <SSLInfo>. Anda menggunakan tag <SSLInfo> yang sama untuk mengonfigurasi endpoint target atau server target.

Tabel berikut menjelaskan elemen konfigurasi TLS yang digunakan oleh tag <SSLInfo>:

Elemen	Deskripsi
<Enabled>	Mengaktifkan TLS satu arah antara Edge dan klien API, atau antara Edge dan backend backend target. Untuk host virtual, Anda harus menentukan keystore yang berisi sertifikat dan kunci pribadi.
<ClientAuthEnabled>	Mengaktifkan TLS dua arah antara Edge dan klien API, atau antara Edge dan backend target Mengaktifkan TLS dua arah biasanya mengharuskan Anda menyiapkan truststore di Edge.
<KeyStore>	Keystore.
<KeyAlias>	Alias yang ditentukan saat Anda mengupload sertifikat dan kunci pribadi ke keystore.
<TrustStore>	Truststore.
<IgnoreValidationErrors>	Jika benar, Edge akan mengabaikan error sertifikat TLS. Valid saat mengonfigurasi TLS untuk server target dan endpoint target, serta saat mengonfigurasi host virtual yang menggunakan TLS 2 arah. Nilai defaultnya adalah false. Jika digunakan dengan endpoint target/server target, jika sistem backend menggunakan SNI dan menampilkan sertifikat dengan Nama Umum (DN) subjek yang tidak cocok dengan nama host, tidak ada cara untuk mengabaikan error dan koneksi akan gagal.
<CommonName>	Jika ditentukan, nilai yang digunakan untuk memvalidasi nama umum sertifikat target. Nilai ini hanya valid untuk konfigurasi TargetEndpoint dan TargetServer. Nilai ini tidak tidak valid untuk konfigurasi VirtualHost. Secara default, nilai yang ditentukan akan cocok persis dengan nama umum sertifikat target. Misalnya, menggunakan `.myhost.com` sebagai nilai untuk <CommonName> hanya akan cocok dan memvalidasi nama host target jika nilai persis `.myhost.com` ditentukan sebagai nama umum dalam sertifikat target. Secara opsional, Apigee dapat melakukan pencocokan dengan karakter pengganti menggunakan atribut `wildcardMatch`. Misalnya, nama umum yang ditentukan sebagai `abc.myhost.com` dalam sertifikat target akan cocok dan divalidasi jika elemen <CommonName> ditentukan sebagai berikut: <CommonName wildcardMatch="true">*.myhost.com</CommonName>

Tentang menetapkan <KeyStore> dan <TrustStore> elemen

Dalam contoh host virtual di atas, keystore dan truststore ditentukan menggunakan referensi, dalam bentuk:

<KeyStore>ref://myKeystoreRef</KeyStore>
<TrustStore>ref://myTruststoreRef</TrustStore>

Apigee sangat merekomendasikan agar Anda selalu menggunakan referensi ke keystore dan truststore. Referensi adalah variabel yang berisi nama keystore atau truststore, bukan menentukan nama keystore secara langsung. Dalam contoh ini:

myKeystoreRef adalah referensi yang berisi nama keystore. Dalam contoh ini, nama keystore adalah myKeystore.
myTruststoreRef adalah referensi yang berisi nama truststore. Dalam contoh ini, nama truststore adalah myTruststore.

Saat masa berlaku sertifikat berakhir, Anda harus memperbarui host virtual atau endpoint target/server target untuk menentukan keystore atau truststore yang berisi sertifikat baru. Keuntungan referensi adalah Anda dapat mengubah nilai referensi untuk mengubah keystore atau truststore tanpa harus mengubah host virtual atau endpoint target/server target itu sendiri:

Untuk pelanggan Cloud: Mengubah nilai referensi tidak mengharuskan Anda menghubungi Dukungan Apigee Edge.
Untuk pelanggan Private Cloud: Mengubah nilai referensi tidak mengharuskan Anda memulai ulang komponen Edge, seperti Router dan Message Processor.

Atau, Anda dapat menentukan nama keystore dan nama truststore secara langsung:

<KeyStore>myKeystore</KeyStore>
<TrustStore>myTruststore</TrustStore>

Jika Anda menentukan nama keystore atau truststore secara langsung, pelanggan Cloud harus menghubungi Dukungan Apigee Edge dan pelanggan Private Cloud harus memulai ulang komponen Edge tertentu untuk memperbarui sertifikat.

Opsi ketiga, hanya untuk endpoint target/server target, adalah menggunakan variabel alur:

<KeyStore>{ssl.keystore}</KeyStore>
<TrustStore>{ssl.truststore}</TrustStore>

Variabel alur berfungsi untuk endpoint target/server target dan memungkinkan Anda memperbarui keystore atau truststore seperti referensi. Namun, variabel alur tidak berfungsi dengan host virtual, dan mengharuskan Anda meneruskan informasi tentang keystore, alias, dan truststore pada setiap permintaan.

Batasan dalam menggunakan referensi ke keystore dan truststore

Pelanggan Cloud berbayar dan semua pelanggan Private Cloud yang mengonfigurasi TLS harus mempertimbangkan batasan berikut saat menggunakan referensi ke keystore dan truststore:

Anda hanya dapat menggunakan referensi keystore dan truststore di host virtual jika Anda menghentikan TLS di Apigee Router.

Jika Anda memiliki load balancer di depan Apigee Router, dan Anda menghentikan TLS di load balancer, Anda tidak dapat menggunakan referensi keystore dan truststore di host virtual.

Jika host virtual yang ada menggunakan nama keystore atau truststore literal

Host virtual yang ada di Edge mungkin tidak dikonfigurasi untuk menggunakan referensi untuk keystore dan truststore. Dalam hal ini, Anda dapat memperbarui host virtual untuk menggunakan referensi.

Edge untuk Cloud

Untuk mengubah host virtual agar menggunakan referensi ke keystore, Anda harus bekerja sama dengan Dukungan Apigee Edge.
Edge untuk Private Cloud

Untuk mengonversi host virtual agar menggunakan referensi:
1. Perbarui host virtual untuk menggunakan referensi.
2. Mulai ulang Router.
Lihat "Mengubah host virtual untuk menggunakan referensi ke keystore dan truststore" di Mengonfigurasi akses TLS ke API untuk Private Cloud untuk mengetahui informasi selengkapnya.

Tentang menggunakan sertifikat dan kunci uji coba gratis Apigee

Jika Anda memiliki akun Edge untuk Cloud berbayar dan belum memiliki sertifikat dan kunci TLS, Anda dapat membuat host virtual yang menggunakan sertifikat dan kunci uji coba gratis Apigee. Artinya, Anda dapat membuat host virtual tanpa membuat keystore terlebih dahulu.

Objek XML yang menentukan host virtual menggunakan sertifikat dan kunci uji coba gratis Apigee akan menghilangkan elemen <KeyStore> dan <KeyAlias>, serta menggantinya dengan elemen <UseBuiltInFreeTrialCert>, seperti ditunjukkan di bawah:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>myapi.apigee.net</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
    </SSLInfo>
    <UseBuiltInFreeTrialCert>true</UseBuiltInFreeTrialCert>
</VirtualHost>

Jika Anda melakukan TLS dua arah, Anda tetap harus menetapkan elemen <ClientAuthEnabled> ke true, dan menentukan truststore menggunakan referensi dengan elemen <TrustStore>.

Lihat Mengonfigurasi host virtual untuk Cloud untuk mengetahui informasi selengkapnya.

Tentang mengonfigurasi TLS

Dua faktor utama menentukan cara Anda melakukan konfigurasi TLS:

Apakah Anda pelanggan Edge Cloud atau Private Cloud?
Bagaimana Anda akan memperbarui sertifikat yang masa berlakunya berakhir atau akan berakhir?

Opsi konfigurasi Cloud dan Private Cloud opsi

Tabel berikut menunjukkan opsi konfigurasi yang berbeda untuk pelanggan Cloud dan Private Cloud:

	Private Cloud	Cloud
Host virtual	Kontrol yang menyeluruh	Kontrol yang menyeluruh hanya untuk akun berbayar
Endpoint target/server target	Kontrol yang menyeluruh	Kontrol yang menyeluruh

Pelanggan Private Cloud memiliki kontrol penuh atas konfigurasi host virtual dan endpoint target/server target. Kontrol tersebut mencakup kemampuan untuk membuat dan menghapus host virtual, serta menetapkan semua properti di host virtual.

Semua pelanggan Cloud, baik berbayar maupun evaluasi, memiliki kontrol penuh atas konfigurasi endpoint target/server target. Selain itu, pelanggan Cloud berbayar memiliki kontrol penuh atas host virtual, termasuk properti TLS.

Menangani sertifikat yang masa berlakunya berakhir

Jika masa berlaku sertifikat TLS berakhir, atau jika konfigurasi sistem Anda berubah sehingga sertifikat tidak lagi valid, Anda harus memperbarui sertifikat. Saat mengonfigurasi TLS untuk host virtual atau endpoint target/server target, Anda harus memutuskan cara melakukan pembaruan tersebut sebelum melakukan konfigurasi apa pun.

Saat masa berlaku sertifikat berakhir

Di Edge, Anda menyimpan sertifikat di salah satu dari dua tempat berikut:

Keystore - Berisi sertifikat TLS dan kunci pribadi yang digunakan untuk mengidentifikasi entitas selama TLS handshake.
Truststore - Berisi sertifikat tepercaya di klien TLS yang digunakan untuk memvalidasi sertifikat server TLS yang ditampilkan kepada klien. Sertifikat ini biasanya merupakan sertifikat yang ditandatangani sendiri, sertifikat yang ditandatangani oleh CA tepercaya, atau sertifikat yang digunakan sebagai bagian dari TLS dua arah.

Saat masa berlaku sertifikat di keystore berakhir, dan Anda menggunakan referensi ke keystore, Anda tidak dapat mengupload sertifikat baru ke keystore. Sebagai gantinya, Anda:

Buat keystore baru.
Upload sertifikat baru ke keystore baru menggunakan nama alias yang sama seperti di the old keystore.
Perbarui referensi di host virtual atau server target/endpoint target untuk menggunakan keystore baru.

Saat masa berlaku sertifikat di truststore berakhir, dan Anda menggunakan referensi ke truststore, Anda:

Buat truststore baru.
Upload sertifikat baru ke truststore baru. Nama alias tidak menjadi masalah untuk truststore. Catatan: Jika sertifikat adalah bagian dari rantai, Anda harus membuat satu file yang berisi semua sertifikat dan mengupload file tersebut ke satu alias, atau mengupload semua sertifikat dalam rantai secara terpisah ke truststore menggunakan alias yang berbeda untuk setiap sertifikat.
Perbarui referensi di host virtual atau server target/endpoint target untuk menggunakan truststore baru.

Ringkasan metode memperbarui sertifikat yang masa berlakunya berakhir

Metode yang Anda gunakan untuk menentukan nama keystore dan truststore di host virtual atau endpoint target/server target menentukan cara Anda melakukan pembaruan sertifikat. Anda dapat menggunakan:

Referensi
Nama langsung
Variabel alur

Setiap metode ini memiliki konsekuensi yang berbeda pada proses pembaruan, seperti yang dijelaskan dalam tabel berikut. Seperti yang dapat Anda lihat, referensi memberikan fleksibilitas terbesar bagi pelanggan Cloud dan Private Cloud:

Jenis konfigurasi	Cara memperbarui/mengganti sertifikat	Private Cloud	Cloud
Referensi (Direkomendasikan)	Untuk keystore, buat keystore baru dengan nama baru dan alias dengan nama yang sama seperti alias lama. Untuk truststore, buat truststore dengan nama baru.	Perbarui referensi ke keystore atau truststore. Tidak perlu memulai ulang Router atau Message Processor.	Perbarui referensi ke keystore atau truststore. Tidak perlu menghubungi Dukungan Apigee.
Variabel alur (hanya endpoint target)	Untuk keystore, buat keystore baru dengan nama baru dan alias dengan nama yang sama atau dengan nama baru. Untuk truststore, buat truststore dengan nama baru.	Teruskan variabel alur yang diperbarui pada setiap permintaan dengan nama keystore, alias, atau truststore baru. Tidak perlu memulai ulang Router atau Message Processor.	Teruskan variabel alur yang diperbarui pada setiap permintaan dengan nama keystore, alias, atau truststore baru. Tidak perlu menghubungi Dukungan Apigee.
Langsung	Buat keystore, alias, truststore baru.	Perbarui host virtual dan mulai ulang Router. Jika truststore digunakan oleh endpoint target/server target, deploy ulang proxy.	Untuk host virtual, hubungi Dukungan Apigee Edge untuk memulai ulang Router. Jika truststore digunakan oleh endpoint target/server target, deploy ulang proxy.
Langsung	Hapus keystore atau truststore dan buat ulang dengan nama yang sama.	Tidak perlu memperbarui host virtual, tidak perlu memulai ulang Router. Namun, permintaan API akan gagal hingga keystore dan alias baru ditetapkan. Jika keystore digunakan untuk TLS dua arah antara Edge dan layanan backend, mulai ulang Message Processor.	Tidak perlu memperbarui host virtual. Namun, permintaan API akan gagal hingga keystore dan alias baru ditetapkan. Jika keystore digunakan untuk TLS dua arah antara Edge dan layanan backend, hubungi Dukungan Apigee Edge untuk memulai ulang Message Processor.
Langsung	Hanya untuk truststore, upload sertifikat baru ke truststore.	Jika truststore digunakan oleh host virtual, mulai ulang Router. Jika truststore digunakan oleh endpoint target/server target, mulai ulang Message Processors.	Untuk host virtual, hubungi Dukungan Apigee Edge untuk memulai ulang Edge Router. Jika truststore digunakan oleh endpoint target/server target, hubungi Dukungan Apigee Edge untuk memulai ulang Message Processor.