Ringkasan sertifikat SSL

SSL/TLS adalah protokol kriptografi yang paling banyak digunakan di internet. Secara teknis, TLS adalah penerus SSL, meskipun istilah ini terkadang digunakan secara bergantian, seperti dalam dokumen ini.

Transport Layer Security (TLS) digunakan untuk mengenkripsi informasi saat dikirim melalui jaringan, sehingga memberikan privasi antara klien dan server atau load balancer. Load Balancer Aplikasi atau Load Balancer Jaringan proxy yang menggunakan SSL memerlukan setidaknya satu kunci pribadi dan sertifikat SSL.

Metode konfigurasi sertifikat

Untuk Load Balancer Aplikasi yang menggunakan proxy HTTPS target, proxy target load balancer harus mereferensikan antara satu dan 15 sertifikat SSL Compute Engine. Setiap resource sertifikat SSL Compute Engine berisi kunci pribadi, sertifikat yang sesuai, dan —opsional—sertifikat CA.

Dukungan load balancer

Tabel berikut menunjukkan metode konfigurasi sertifikat yang didukung oleh setiap load balancer.

Load balancer Metode konfigurasi sertifikat: Proxy target merujuk...
Sertifikat SSL Compute Engine Peta sertifikat Certificate Manager Sertifikat Certificate Manager secara langsung
Load Balancer Aplikasi (proxy HTTPS target)
Load Balancer Aplikasi eksternal regional Mendukung sertifikat regional
Dikelola sendiri
Dikelola Google 		Dikelola sendiri
Dikelola Google
Load Balancer Aplikasi internal regional Mendukung sertifikat regional
Dikelola sendiri
Dikelola Google 		Dikelola sendiri
Dikelola Google

Jenis sertifikat

Anda dapat membuat sertifikat SSL yang dikelola sendiri untuk load balancer.

Sertifikat SSL yang dikelola sendiri

Sertifikat SSL yang dikelola sendiri adalah sertifikat yang Anda peroleh, sediakan, dan perpanjang sendiri. Sertifikat yang dikelola sendiri dapat berupa salah satu jenis Sertifikat kunci publik berikut:

  • Validasi Domain (DV)
  • Validasi Organisasi (OV)
  • Sertifikat Extended Validation (EV)

Anda dapat membuat sertifikat SSL yang dikelola sendiri menggunakan resource sertifikat SSL Compute Engine. Untuk mengetahui informasi selengkapnya, lihat Menggunakan sertifikat SSL yang dikelola sendiri.

Jenis kunci yang didukung

Jenis kunci berikut didukung untuk sertifikat SSL Compute Engine yang dikelola sendiri dan bersifat regional:

  • RSA-2048
  • RSA-3072
  • RSA-4096
  • ECDSA P-256
  • ECDSA P-384

Menggunakan sertifikat dengan kunci ECDSA

Bagian ini membahas alasan kami merekomendasikan ECDSA daripada RSA sebagai praktik terbaik untuk kunci penandatanganan sertifikat.

Jenis kunci yang akan digunakan

ECDSA P-256 adalah pilihan jenis kunci yang direkomendasikan untuk sebagian besar sertifikat TLS, yang menawarkan keamanan kriptografi yang kuat bersama dengan performa yang sangat baik untuk operasi penandatanganan dan penggunaan bandwidth jaringan yang efisien.

Beberapa kemungkinan alasan untuk menggunakan jenis kunci sertifikat lain adalah sebagai berikut:

  • Jika Anda perlu mendukung klien lama yang tidak mendukung sertifikat ECDSA, Anda dapat memberikan sertifikat RSA-2048 selain sertifikat ECDSA P-256.
  • Jika Anda memiliki persyaratan kepatuhan khusus yang mengharuskan Anda menggunakan ukuran kunci yang lebih besar atau jenis kunci tertentu, kunci ECDSA P-384, RSA-2048, RSA-3072, dan RSA-4096 dapat digunakan.

Alasan memilih ECDSA daripada RSA

Keunggulan utama ECDSA terletak pada kemampuannya untuk memberikan tingkat keamanan kriptografi yang setara dengan kunci yang jauh lebih kecil dibandingkan dengan RSA. Efisiensi ini menghasilkan manfaat performa dan resource yang nyata. Kunci yang lebih kecil tidak berarti keamanan yang lebih lemah—ECDSA didasarkan pada masalah logaritma diskrit kurva elips, yang memberikan keamanan yang lebih kuat per unit kunci, dan dalam beberapa kasus efisiensi komputasi yang lebih baik dibandingkan dengan RSA.

Contoh:

  • Kunci ECDSA 256-bit memberikan tingkat keamanan yang serupa dengan kunci RSA-3072.
  • Kunci ECDSA 384-bit memberikan tingkat keamanan yang lebih tinggi daripada ukuran kunci RSA yang didukung secara luas.

Manfaat utama ECDSA:

  • Performa: Operasi penandatanganan ECDSA jauh lebih intensif secara komputasi daripada operasi RSA yang memberikan tingkat keamanan yang setara. Hal ini mengurangi beban dan latensi CPU, yang sangat penting untuk sistem ber-throughput tinggi atau yang sensitif terhadap latensi.

  • Efisiensi: kunci dan tanda tangan yang lebih kecil memerlukan lebih sedikit bandwidth dan penyimpanan, yang sangat bermanfaat untuk lingkungan dengan keterbatasan resource seperti perangkat seluler dan IoT.

Beberapa sertifikat SSL

Proxy target Application Load Balancer dapat mereferensikan hingga 15 sertifikat SSL Compute Engine. Resource sertifikat SSL Compute Engine yang dirujuk pertama adalah sertifikat default (primer) untuk proxy target.

Untuk mengetahui informasi selengkapnya, lihat Proxy target dan Sertifikat SSL dalam dokumentasi load balancing.

Proses pemilihan sertifikat

Proses pemilihan sertifikat berikut berlaku untuk load balancer yang proxy targetnya mereferensikan beberapa sertifikat SSL Compute Engine.

Setelah klien terhubung ke load balancer, klien dan load balancer melakukan negosiasi sesi TLS. Selama negosiasi sesi TLS, klien mengirimkan daftar sandi TLS yang didukungnya (dalam ClientHello) ke load balancer. Load balancer memilih sertifikat yang algoritma kunci publiknya kompatibel dengan klien. Klien juga dapat mengirim nama host indikasi nama server (SNI) ke load balancer sebagai bagian dari negosiasi ini. Data nama host SNI terkadang digunakan untuk membantu load balancer memilih sertifikat yang harus dikirim ke klien.

  • Jika proxy target load balancer hanya mereferensikan satu sertifikat, sertifikat tersebut akan digunakan, dan nilai nama host SNI yang dikirim oleh klien tidak relevan.

  • Jika proxy target load balancer mereferensikan dua sertifikat atau lebih, load balancer menggunakan proses berikut untuk memilih satu sertifikat:

    • Jika klien tidak mengirim nama host SNI apa pun dalam ClientHello, load balancer akan menggunakan sertifikat pertama dalam daftar sertifikatnya.

    • Jika klien mengirim nama host SNI yang tidak cocok dengan nama umum (CN) sertifikat dan tidak cocok dengan nama alternatif subjek (SAN) sertifikat, load balancer akan menggunakan sertifikat pertama dalam daftar sertifikatnya.

    • Dalam semua situasi lainnya: Load balancer memilih sertifikat menggunakan proses pencocokan berikut:

      • Pencocokan dilakukan berdasarkan akhiran terpanjang terhadap atribut sertifikat nama umum (CN) dan nama alternatif subjek (SAN), dengan preferensi untuk sertifikat ECDSA daripada sertifikat RSA.

      • Untuk mengilustrasikan metode pencocokan, pertimbangkan proxy target yang mereferensikan dua sertifikat berikut:

        • Sertifikat A

          • CN: cats.pets.example.com
          • SAN: cats.pets.example.com, *.pets.example.com, *.example.com

        • Sertifikat B

          • CN: dogs.pets.example.com
          • SAN: dogs.pets.example.com, *.pets.example.com, *.example.com

      • Sekarang pertimbangkan skenario berikut:

        • Jika nama host SNI yang dikirim oleh klien adalah cats.pets.example.com, load balancer akan menggunakan Sertifikat A.
        • Jika nama host SNI yang dikirim oleh klien adalah ferrets.pets.example.com, tidak ada kecocokan persis, sehingga load balancer memilih salah satu Sertifikat A atau Sertifikat B karena keduanya menyertakan *.pets.example.com dalam daftar SAN mereka. Anda tidak dapat mengontrol sertifikat mana yang dipilih dalam situasi ini.

  • Setelah sertifikat dipilih, load balancer akan mengirimkan sertifikat tersebut kepada klien hanya jika sertifikat yang dipilih menggunakan algoritma kunci publik yang kompatibel dengan cipher yang dikirim oleh klien dalam ClientHello. Negosiasi TLS gagal jika klien tidak mendukung cipher suite yang mencakup algoritma kunci publik (ECDSA atau RSA) dari sertifikat yang dipilih load balancer.

Langkah berikutnya