Membuat keystore dan truststore untuk Private Cloud versi 4.17.09 dan yang lebih lama

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

Dokumen ini menjelaskan cara membuat, mengubah, dan menghapus keystore dan truststore untuk Edge untuk Private Cloud versi 4.17.09 dan yang lebih lama.

Tentang keystore dan truststore

Keystore dan truststore menentukan repositori sertifikat keamanan yang digunakan untuk enkripsi TLS. Perbedaan utama antara keduanya adalah tempat keduanya digunakan dalam proses handsfree TLS:

  • Keystore berisi sertifikat TLS dan kunci pribadi yang digunakan untuk mengidentifikasi entitas selama handshake TLS.

    Di TLS satu arah, saat klien terhubung ke endpoint TLS di server, keystore server akan menampilkan sertifikat server (sertifikat publik) kepada klien. Klien kemudian memvalidasi sertifikat tersebut dengan Certificate Authority (CA), seperti Symantec atau VeriSign.

    Di TLS dua arah, klien dan server akan mengelola keystore dengan sertifikat dan kunci pribadinya sendiri yang digunakan untuk autentikasi bersama.
  • Truststore berisi sertifikat yang digunakan untuk memverifikasi sertifikat yang diterima sebagai bagian dari handshake TLS.

    Di TLS satu arah, truststore tidak diperlukan jika sertifikat ditandatangani oleh CA yang valid. Jika sertifikat yang diterima oleh klien TLS ditandatangani oleh CA yang valid, klien akan membuat permintaan ke CA untuk mengautentikasi sertifikat tersebut. Klien TLS biasanya menggunakan truststore untuk memvalidasi sertifikat yang ditandatangani sendiri yang diterima dari server TLS, atau sertifikat yang tidak ditandatangani oleh CA tepercaya. Dalam skenario ini, klien mengisi truststore-nya dengan sertifikat yang dipercaya. Kemudian, saat klien menerima sertifikat server, sertifikat yang masuk divalidasi dengan sertifikat di truststore-nya.

    Misalnya, klien TLS terhubung ke server TLS tempat server menggunakan sertifikat yang ditandatangani sendiri. Karena merupakan sertifikat yang ditandatangani sendiri, klien tidak dapat memvalidasinya dengan CA. Sebagai gantinya, klien melakukan pramuat sertifikat yang ditandatangani sendiri ke truststore. Kemudian, saat klien mencoba terhubung ke server, klien akan menggunakan truststore-nya untuk memvalidasi sertifikat yang diterima dari server.

    Untuk TLS dua arah, klien TLS dan server TLS dapat menggunakan truststore. Truststore diperlukan saat melakukan TLS dua arah jika Edge bertindak sebagai server TLS.

Sertifikat dapat diterbitkan oleh certificate authority (CA), atau ditandatangani sendiri oleh kunci pribadi yang Anda buat. Jika Anda memiliki akses ke CA, ikuti petunjuk yang diberikan oleh CA Anda untuk membuat kunci dan menerbitkan sertifikat. Jika tidak memiliki akses ke CA, Anda dapat membuat sertifikat yang ditandatangani sendiri menggunakan salah satu dari banyak alat gratis yang tersedia secara publik, seperti openssl.

Mengimplementasikan keystore dan truststore di Edge

Di Edge, keystore berisi satu atau beberapa file JAR, dengan file JAR berisi:

  • Sertifikat TLS sebagai file PEM - baik sertifikat yang ditandatangani oleh certificate authority (CA), rantai sertifikat tempat sertifikat terakhir ditandatangani oleh CA, atau sertifikat yang ditandatangani sendiri.
  • Kunci pribadi sebagai file PEM. Edge mendukung ukuran tombol hingga 2048 bit. Frasa sandi bersifat opsional.

Truststore mirip dengan keystore, tetapi hanya berisi sertifikat sebagai file PEM, tetapi tidak memiliki kunci pribadi.

Jika sertifikat adalah bagian dari rantai, keystore/truststore harus berisi semua sertifikat dalam rantai, baik sebagai file PEM individual atau sebagai file tunggal. Jika Anda menggunakan satu file, sertifikat harus diurutkan dengan sertifikat pertama dalam file tersebut adalah sertifikat yang digunakan untuk TLS, diikuti rantai sertifikat secara berurutan ke sertifikat CA. Anda harus menyisipkan baris kosong di antara setiap sertifikat dalam file.

Edge menyediakan API yang Anda gunakan untuk membuat keystore dan truststore. API sebenarnya sama. Perbedaannya adalah saat membuat keystore, Anda meneruskan file JAR yang berisi sertifikat dan kunci pribadi. Saat membuat truststore, Anda hanya meneruskan sertifikat sebagai file PEM.

Tentang format file sertifikat dan kunci

Contoh dalam dokumen ini menunjukkan sertifikat dan kunci TLS yang ditetapkan sebagai file PEM, yang sesuai dengan format X.509. Jika sertifikat atau kunci pribadi tidak ditentukan oleh file PEM, Anda dapat mengonversinya menjadi file PEM menggunakan utilitas seperti openssl.

Namun, banyak file .crt dan .key sudah dalam format PEM. Jika file tersebut berupa file teks, dan diapit dalam:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

atau:

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

Maka, file tersebut akan kompatibel dengan format PEM dan Anda dapat menggunakannya di keystore atau truststore tanpa mengonversinya menjadi file PEM.

Jika Anda memiliki rantai sertifikat, dan ingin menggunakan rantai tersebut di keystore atau truststore, Anda dapat menggabungkan semua sertifikat ke dalam satu file PEM dengan baris baru di antara setiap sertifikat. Sertifikat harus berurutan dan sertifikat terakhir harus berupa root certificate atau sertifikat perantara yang ditandatangani oleh root certificate:

-----BEGIN CERTIFICATE-----
(Your Primary TLS certificate)
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
(Intermediate certificate)
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
(Root certificate or intermediate certificate signed by a root certificate)
-----END CERTIFICATE-----

Mendapatkan detail tentang keystore yang ada

Periksa lingkungan Anda untuk menemukan keystore yang ada dengan menggunakan List Keystores and Truststores API:

curl -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

Untuk pelanggan cloud, keystore default disediakan untuk organisasi uji coba gratis di lingkungan pengujian dan produksi. Anda akan melihat hasil berikut untuk panggilan ini bagi kedua lingkungan:

[ "freetrial" ]

Anda dapat menggunakan keystore default ini untuk menguji API, dan mengirim API ke produksi, tetapi biasanya Anda akan membuat keystore sendiri dengan sertifikat dan kunci Anda sendiri, sebelum men-deploy ke produksi.

Untuk pelanggan Private Cloud, array yang ditampilkan akan kosong sampai Anda membuat keystore pertama.

Periksa konten keystore dengan menggunakan Get a Keystore atau Truststore API. Untuk pelanggan cloud, Anda akan melihat sertifikat TLS server tunggal, sertifikat default yang disediakan Apigee Edge untuk akun uji coba gratis.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

Respons seharusnya akan muncul seperti:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

Anda juga dapat melihat informasi ini di UI pengelolaan Edge:

  1. Login ke UI pengelolaan Edge di https://enterprise.apigee.com (cloud) atau http://<ms-ip>:9000 (lokal), dengan <ms-ip> adalah alamat IP node Server Pengelolaan.
  2. Di menu UI pengelolaan Edge, pilih Admin > TLS Certificates.

Mendapatkan detail sertifikat TLS

Anda dapat menggunakan Mendapatkan Detail Sertifikat dari Keystore atau Truststore API untuk melihat detail tentang sertifikat TLS di keystore, seperti tanggal habis masa berlaku dan penerbit. Pertama, dapatkan nama sertifikat yang Anda minati. Contoh ini mengambil informasi untuk keystore yang disebut "freetrial".

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

Contoh respons:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

Kemudian, gunakan nilai properti sertifikat untuk mendapatkan detail sertifikat:

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial/certs/wildcard.apigee.net.crt \
-u email:password

Contoh respons:

{
 "certInfo" : [ {
   "expiryDate" : "Wed, 23 Apr 2014 20:50:02 UTC",
   "isValid" : "Yes",
   "issuer" : "CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O=&quot;GoDaddy.com, Inc.&quot;, L=Scottsdale, ST=Arizona, C=US",
   "subject" : CN=*.example.apigee.net, OU=Domain Control Validated",
   "subjectAlternativeNames" : ["*.example.apigee.net","*.example.apigee.net" ],
   "validFrom" : "Tue, 15 Apr 2014 09:17:03 UTC",
   "version" : 3
 } ],
 "name" : "example.apigee.net.crt"
}

Anda juga dapat melihat informasi ini di UI pengelolaan Edge:

  1. Login ke UI pengelolaan Edge di https://enterprise.apigee.com (cloud) atau http://<ms-ip>:9000 (lokal), dengan <ms-ip> adalah alamat IP node Server Pengelolaan.
  2. Di menu UI pengelolaan Edge, pilih Admin > TLS Certificates.

Di UI Edge, Anda dapat menentukan seberapa awal Edge menunjukkan bahwa masa berlaku sertifikat akan berakhir. Secara default, UI akan menandai semua sertifikat yang dijadwalkan berakhir dalam 10 hari ke depan.

Membuat keystore

Keystore bersifat khusus untuk lingkungan di organisasi Anda, misalnya lingkungan pengujian atau produksi. Oleh karena itu, jika ingin menguji keystore di lingkungan pengujian sebelum men-deploy-nya ke lingkungan produksi, Anda harus membuatnya di kedua lingkungan.

Membuat keystore adalah proses dua langkah:

  1. Buat file JAR yang berisi sertifikat dan kunci pribadi Anda.
  2. Buat keystore dan upload File JAR.

Buat file JAR yang berisi sertifikat dan kunci pribadi Anda

Buat file JAR dengan kunci pribadi, sertifikat, dan manifes. File JAR harus berisi file dan direktori berikut:

/META-INF/descriptor.properties
myCert.pem
myKey.pem

Dalam direktori yang berisi pasangan kunci dan sertifikat Anda, buat direktori dengan nama /META-INF. Lalu, buat file bernama descriptor.properties di /META-INF dengan konten berikut:

certFile={myCertificate}.pem
keyFile={myKey}.pem

Buat file JAR yang berisi pasangan kunci dan sertifikat Anda:

jar -cf myKeystore.jar myCert.pem myKey.pem

Tambahkan deskriptor.properties ke file JAR:

jar -uf myKeystore.jar META-INF/descriptor.properties

Buat keystore dan upload file JAR

Untuk membuat keystore di lingkungan, Anda hanya perlu menetapkan nama keystore ke Create a Keystore atau Truststore API. Nama hanya boleh berisi karakter alfanumerik:

curl -X POST -H "Content-Type: text/xml" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-d '<KeyStore name="myKeystore"/>' -u email:password

Contoh respons:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystore"
}

Setelah membuat keystore bernama di sebuah lingkungan, Anda dapat mengupload file JAR yang berisi sertifikat dan kunci pribadi menggunakan Upload file JAR ke Keystore API:

curl -X POST -H "Content-Type: multipart/form-data" \
-F file="@myKeystore.jar" -F password={key_pass} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/{myKeystore}/keys?alias={key_alias}" \
-u email:password

dengan opsi -F menentukan jalur ke file JAR.

Dalam panggilan ini, Anda menentukan dua parameter kueri:

  • alias - Mengidentifikasi sertifikat dan kunci di key store. Saat membuat host virtual, Anda mereferensikan sertifikat dan kunci dengan nama aliasnya.
  • password - Sandi untuk kunci pribadi. Hapus parameter ini jika kunci pribadi tidak memiliki sandi.

Pastikan keystore Anda diupload dengan benar:

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystore \
-u email:password

Contoh respons:

{  
 "certs" : [ "myCertificate" ],
 "keys" : [ "myKey" ],
 "name" : "myKeystore"
}

Membuat truststore

API yang Anda gunakan untuk membuat truststore sama dengan yang digunakan untuk membuat keystore. Satu-satunya perbedaan adalah Anda meneruskan file sertifikat sebagai file PEM, bukan file JAR.

Jika sertifikat adalah bagian dari rantai, Anda harus mengupload semua sertifikat dalam rantai secara terpisah ke truststore, atau membuat satu file yang berisi semua sertifikat. Sertakan baris baru di antara setiap sertifikat dalam file. Sertifikat akhir biasanya ditandatangani oleh penerbit sertifikat. Misalnya, di truststore, Anda mengupload sertifikat klien, client_cert_1, dan sertifikat penerbit sertifikat klien, ca_cert.

Selama autentikasi TLS dua arah, autentikasi klien akan berhasil saat server mengirim client_cert_1 ke klien sebagai bagian dari proses handshake TLS.

Atau, Anda memiliki sertifikat kedua, client_cert_2, yang ditandatangani oleh sertifikat yang sama, ca_cert. Namun, Anda tidak mengupload client_cert_2 ke truststore. Truststore masih berisi client_cert_1 dan ca_cert.

Saat server meneruskan client_cert_2 sebagai bagian dari handshake TLS, permintaan akan berhasil. Hal ini karena Edge memungkinkan verifikasi TLS berhasil saat client_cert_2 tidak ada di truststore, tetapi ditandatangani oleh sertifikat yang ada di truststore. Jika Anda menghapus sertifikat CA, ca_cert, dari truststore, maka verifikasi TLS akan gagal.

Buat truststore kosong di lingkungan menggunakan Create a Keystore atau Truststore, API yang sama yang Anda gunakan untuk membuat keystore:

curl -X POST -H "Content-Type: text/xml" -d \
'<KeyStore name="myTruststore"/>' \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

Upload sertifikat sebagai file PEM ke truststore dengan menggunakan Upload a Certificate to a Truststore API:

curl -X POST -H "Content-Type: multipart/form-data" -F file="@trust.pem" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myTruststore/certs?alias=myTruststore \
-u email:password

dengan opsi -F menentukan jalur ke file PEM.

Menghapus keystore atau truststore

Anda dapat menghapus keystore atau truststore dengan menggunakan Delete a Keystore atau Truststore API:

curl -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystoreName \
-u email:password

Contoh respons:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystoreName"
}

Jika Anda menghapus keystore atau truststore yang digunakan oleh host virtual atau endpoint/target/server target, semua panggilan API melalui host virtual atau server endpoint/target target akan gagal.