Menggunakan sertifikat SSL yang dikelola Google.

Halaman ini membahas cara membuat dan menggunakan sertifikat SSL Compute Engine yang dikelola Google.

Untuk membuat sertifikat yang dikelola Google menggunakan Pengelola Sertifikat, lihat Ringkasan deployment.

Sertifikat SSL yang dikelola Google adalah sertifikat Validasi Domain (DV) yang diperoleh dan dikelola Google Cloud untuk domain Anda. Sertifikat ini mendukung beberapa nama host dalam setiap sertifikat, dan Google memperpanjang sertifikat secara otomatis.

Sertifikat yang dikelola Google didukung dengan load balancer berikut:

• Load Balancer Aplikasi eksternal global
• Load Balancer Aplikasi Klasik
• Load Balancer Jaringan proxy eksternal (dengan proxy SSL target)

Sertifikat SSL yang dikelola Google Compute Engine tidak didukung untuk Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, atau Load Balancer Aplikasi internal lintas region. Untuk load balancer ini, Anda dapat menggunakan sertifikat SSL Compute Engine yang dikelola sendiri atau sebaiknya gunakan Pengelola Sertifikat.

Anda juga dapat menggunakan sertifikat SSL terkelola dengan Google Kubernetes Engine. Untuk informasi selengkapnya, lihat Menggunakan sertifikat SSL yang dikelola Google.

Anda dapat membuat sertifikat yang dikelola Google sebelum, selama, atau setelah membuat load balancer. Halaman ini mengasumsikan bahwa Anda membuat sertifikat Compute Engine sebelum atau setelah membuat load balancer, bukan selama pembuatan. Untuk membuat sertifikat saat membuat load balancer, lihat halaman petunjuk load balancer.

Sebelum memulai

• Pastikan Anda memahami ringkasan sertifikat SSL.
• Pastikan Anda memiliki nama domain yang ingin digunakan untuk sertifikat SSL yang dikelola Google. Jika Anda menggunakan Cloud Domains, lihat Mendaftarkan domain.

• Pastikan Anda telah mengaktifkan Compute Engine API untuk project Anda.

  Mengaktifkan Compute Engine API

Izin

Untuk mengikuti panduan ini, Anda harus dapat membuat dan mengubah sertifikat SSL di project Anda. Anda dapat melakukannya jika salah satu hal berikut berlaku:

• Anda adalah Pemilik atau Editor project (roles/owner atau roles/editor).
• Anda memiliki peran Compute Security Admin (compute.securityAdmin) dan peran Compute Network Admin (compute.networkAdmin) dalam project.
• Anda memiliki peran khusus untuk project yang menyertakan izin compute.sslCertificates.* dan satu atau kedua izin compute.targetHttpsProxies.* dan compute.targetSslProxies.*, bergantung pada jenis load balancer yang Anda gunakan.

Langkah 1. Membuat sertifikat SSL yang dikelola Google

Catatan: Untuk sertifikat yang dikelola Google untuk Ingress GKE, lihat Menggunakan sertifikat SSL yang dikelola Google.

Anda dapat membuat sertifikat yang dikelola Google sebelum, selama, atau setelah membuat load balancer. Selama proses pembuatan load balancer di konsol Google Cloud, Anda dapat menggunakan konsol Google Cloud untuk membuat sertifikat. Atau, Anda dapat membuat sertifikat sebelum atau setelah membuat load balancer. Langkah ini menunjukkan cara membuat sertifikat yang nantinya dapat Anda tambahkan ke satu atau beberapa load balancer.

Jika telah membuat sertifikat SSL yang dikelola Google, Anda dapat melewati langkah ini.

Konsol

Anda dapat menggunakan sertifikat SSL global di tab Sertifikat Klasik di halaman Certificate Manager.

Catatan: Prosedur berikut akan mengarahkan Anda langsung ke tab Sertifikat Klasik. Anda dapat menemukan tab Sertifikat Klasik di halaman Pengelola Sertifikat yang ditautkan dari halaman Keamanan tingkat teratas.

1. Buka tab Sertifikat Klasik di konsol Google Cloud.
   Buka Sertifikat Klasik
2. Klik Buat sertifikat SSL.
3. Masukkan nama dan deskripsi opsional untuk sertifikat.
4. Pilih Create Google-managed certificate.
5. Tambahkan domain.
6. Klik Create.

gcloud

Untuk membuat sertifikat SSL global yang dikelola Google untuk Load Balancer Aplikasi eksternal global atau Load Balancer Jaringan proxy eksternal, gunakan perintah gcloud compute ssl-certificates create:

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --description=DESCRIPTION \
    --domains=DOMAIN_LIST \
    --global

Ganti kode berikut:

• CERTIFICATE_NAME: nama untuk sertifikat SSL global
• DESCRIPTION: deskripsi untuk sertifikat SSL global
• DOMAIN_LIST: satu nama domain atau daftar nama domain yang dipisahkan koma yang akan digunakan untuk sertifikat ini

Terraform

Untuk membuat sertifikat SSL yang dikelola Google, gunakan resource google_compute_managed_ssl_certificate.

resource "google_compute_managed_ssl_certificate" "lb_default" {
  provider = google-beta
  name     = "myservice-ssl-cert"

  managed {
    domains = ["example.com"]
  }
}

api

Buat metode resource sertifikat yang dikelola Google sslCertificates.insert, ganti PROJECT_ID dengan project ID Anda.

POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/sslCertificates
{
  "name": "ssl-certificate-name",
  "managed": {
    "domains": [
      "www.example.com"
    ]
  },
  "type": "MANAGED"
}

Memeriksa status sertifikat SSL yang dikelola Google

Konsol

Anda dapat memeriksa status sertifikat SSL global di tab Sertifikat Klasik di halaman Pengelola Sertifikat.

1. Buka tab Sertifikat Klasik di konsol Google Cloud.
   Buka Sertifikat Klasik
2. Opsional: Filter daftar sertifikat SSL.
3. Periksa kolom Status.
4. Untuk melihat detail selengkapnya, klik nama sertifikat.

gcloud

Untuk menentukan status sertifikat yang dikelola Google, Anda dapat menggunakan perintah gcloud compute. Setelah menjalankan perintah yang sesuai, perhatikan hal berikut:

• Status terkelola.
• Status domain.

Untuk mencantumkan sertifikat SSL yang dikelola Google, gunakan perintah gcloud compute ssl-certificates list dengan flag --global .

gcloud compute ssl-certificates list \
   --global

Anda dapat menggunakan perintah gcloud compute ssl-certificates describe, yang menggantikan CERTIFICATE_NAME:

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
   --global \
   --format="get(name,managed.status, managed.domainStatus)"

Pada tahap ini, status sertifikat dan status domain adalah PROVISIONING. Setelah Anda menyelesaikan langkah-langkah di halaman ini, status akan berubah menjadi ACTIVE.

Untuk mengetahui informasi selengkapnya tentang status, lihat halaman pemecahan masalah.

Langkah 2: Buat atau perbarui load balancer

Agar menjadi ACTIVE, sertifikat SSL yang dikelola Google harus dikaitkan dengan load balancer, khususnya proxy target load balancer.

Setelah membuat sertifikat SSL dan sertifikat tersebut berada dalam status PROVISIONING, Anda dapat menggunakannya selama pembuatan load balancer, seperti yang dijelaskan dalam panduan cara berikut:

• Menyiapkan Load Balancer Aplikasi eksternal global dengan backend Compute Engine
• Menyiapkan Load Balancer Aplikasi klasik dengan backend Compute Engine
• Menyiapkan Load Balancer Jaringan proxy eksternal dengan proxy SSL

Atau, Anda dapat menggunakannya untuk memperbarui load balancer yang ada, seperti yang dijelaskan di sini:

Konsol

Saat Anda memperbarui Load Balancer Aplikasi eksternal global atau Load Balancer Jaringan proxy eksternal menggunakan Konsol Google Cloud, Google Cloud akan otomatis mengaitkan sertifikat SSL Anda dengan proxy target yang benar.

1. Buka halaman Load balancing di Konsol Google Cloud.
   Buka Load balancing
2. Klik nama load balancer Anda.
3. Klik Edit .
4. Klik Frontend configuration.
5. Klik frontend yang benar (harus HTTPS, HTTP/2, SSL).
6. Klik Sertifikat tambahan, lalu pilih sertifikat yang dikelola Google dari daftar drop-down.
7. Klik Create.

gcloud

Untuk mengaitkan sertifikat SSL dengan proxy HTTPS target untuk Load Balancer Aplikasi eksternal global, gunakan perintah gcloud compute target-https-proxies update dengan flag --global-ssl-certificates dan --global:

gcloud compute target-https-proxies update TARGET_PROXY_NAME \
    --ssl-certificates SSL_CERTIFICATE_LIST \
    --global-ssl-certificates \
    --global

Untuk mengaitkan sertifikat SSL dengan proxy SSL target untuk Load Balancer Jaringan proxy eksternal, gunakan perintah gcloud compute target-ssl-proxies update:

gcloud compute target-ssl-proxies update TARGET_PROXY_NAME \
    --ssl-certificates SSL_CERTIFICATE_LIST

Ganti kode berikut:

• TARGET_PROXY_NAME: nama proxy target load balancer

• SSL_CERTIFICATE_LIST: daftar resource sertifikat SSL yang dipisahkan koma

  Pastikan bahwa daftar sertifikat yang dirujuk menyertakan semua sertifikat SSL lama yang valid serta sertifikat SSL baru. Perintah gcloud compute target-ssl-proxies update akan mengganti nilai asli untuk --ssl-certificates dengan nilai baru.

Terraform

Untuk membuat proxy HTTPS target, gunakan resource google_compute_target_https_proxy.

Untuk membuat proxy SSL target, gunakan resource google_compute_target_ssl_proxy.

resource "google_compute_target_https_proxy" "lb_default" {
  provider = google-beta
  name     = "myservice-https-proxy"
  url_map  = google_compute_url_map.lb_default.id
  ssl_certificates = [
    google_compute_managed_ssl_certificate.lb_default.name
  ]
  depends_on = [
    google_compute_managed_ssl_certificate.lb_default
  ]
}

Setiap proxy HTTPS target atau proxy SSL target harus mereferensikan minimal satu sertifikat SSL. Proxy target dapat mereferensikan lebih dari satu sertifikat SSL. Untuk mengetahui detailnya, lihat Target pool dan target proxy di kuota dan batas resource load balancing.

Penting: Untuk Network Load Balancer proxy eksternal dengan sertifikat SSL yang dikelola Google, aturan penerusan load balancer harus menggunakan port TCP 443 agar sertifikat yang dikelola Google dapat disediakan pada awalnya dan diperpanjang secara otomatis.

Langkah 3: Verifikasi pengaitan proxy target

Setelah membuat atau memperbarui load balancer, Anda dapat memastikan bahwa sertifikat SSL dikaitkan dengan proxy target load balancer.

Jika Anda belum mengetahui nama proxy target, gunakan perintah gcloud compute target-https-proxies list dan gcloud compute target-ssl-proxies list untuk mencantumkan proxy target dalam project Anda.

Verifikasi pengaitan antara sertifikat SSL dan proxy target dengan menjalankan perintah berikut.

Untuk Load Balancer Aplikasi eksternal global:

gcloud compute target-https-proxies describe TARGET_HTTPS_PROXY_NAME \
    --global \
    --format="get(sslCertificates)"

Untuk Load Balancer Jaringan proxy eksternal:

gcloud compute target-ssl-proxies describe TARGET_SSL_PROXY_NAME \
    --format="get(sslCertificates)"

Pada tahap ini, status sertifikat yang dikelola Google mungkin masih PROVISIONING. Google Cloud bekerja sama dengan Certificate Authority untuk mengeluarkan sertifikat. Penyediaan sertifikat yang dikelola Google mungkin memerlukan waktu hingga 60 menit.

Langkah 4: Perbarui data A dan AAAA DNS agar mengarah ke alamat IP load balancer

Data DNS Anda mungkin dikelola di situs registrar, host DNS, atau ISP Anda.

Saat mengelola data, perhatikan hal berikut:

• Pastikan data A DNS (untuk IPv4) dan data AAAA DNS (untuk IPv6) untuk domain Anda dan subdomain apa pun mengarah ke alamat IP yang terkait dengan aturan penerusan load balancer.

  Untuk menyediakan sertifikat SSL, pastikan data A dan AAAA mengarah ke alamat IP load balancer di DNS publik.

• Jika Anda menggunakan Cloud DNS, siapkan domain Anda dan perbarui server nama Anda.

• Jika Anda memiliki beberapa domain dalam sertifikat yang dikelola Google, tambahkan atau perbarui data DNS untuk semua domain dan subdomain agar mengarah ke alamat IP load balancer Anda. Validasi sertifikat akan gagal jika domain dan subdomain dalam sertifikat yang dikelola Google mengarah ke IP lain selain alamat IP aturan penerusan load balancer.

Penyediaan sertifikat terkelola berhasil jika hal berikut benar:

• Data DNS domain Anda menggunakan data CNAME yang mengarah ke domain lain.
• Domain lain berisi data A atau AAAA yang mengarah ke alamat IP load balancer Anda.

Penting: Sebaiknya pastikan domain Anda diarahkan langsung ke alamat IP load balancer. Untuk load balancer yang telah mengaktifkan Cloud CDN, beberapa penyedia CDN pihak ketiga mungkin mencegah permintaan validasi berhasil. Hal ini dapat terjadi jika penyedia CDN secara aktif membuat proxy traffic HTTP(S).

Anda dapat memverifikasi penyiapan dengan menjalankan perintah dig. Misalnya, anggap domain Anda adalah www.example.com. Jalankan perintah dig berikut:

dig www.example.com

; <<>> DiG 9.10.6 <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31748
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.example.com.           IN  A

;; ANSWER SECTION:
www.example.com. 1742    IN      CNAME   example.net.
example.net.      12     IN      A       34.95.64.10

;; Query time: 43 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jun 03 16:54:44 PDT 2020
;; MSG SIZE  rcvd: 193

Dalam contoh ini, 34.95.64.10 adalah alamat IP load balancer Anda.

Resolver DNS di internet berada di luar kontrol Google Cloud. Perintah ini menyimpan kumpulan data resource Anda dalam cache sesuai dengan time to live (TTL), yang berarti bahwa perintah dig atau nslookup dapat menampilkan nilai yang di-cache. Jika Anda menggunakan Cloud DNS, lihat Propagasi perubahan.

Catatan: Validasi domain DNS adalah proses otomatis yang secara berkala memeriksa data A dan AAAA domain untuk alamat IP yang cocok dari load balancer Google Cloud. Proses ini memiliki backoff eksponensial otomatis untuk waktu tunggu di antara pemeriksaan validasi. Jika deployment disiapkan sebelumnya dan waktu peralihan layanan direncanakan selama periode pemeliharaan tertentu satu hari atau lebih setelah deployment awal, Google merekomendasikan agar Anda membuat atau membuat ulang sertifikat sesaat sebelum atau selama periode pemeliharaan, bukan mengandalkan validasi domain yang berjalan selama waktu tertentu (karena backoff timer).

Waktu penerapan data DNS

Data DNS A dan AAAA yang baru diperbarui dapat memerlukan waktu yang cukup lama untuk di-propagasi sepenuhnya. Terkadang, propagasi di seluruh internet memerlukan waktu hingga 72 jam di seluruh dunia, meskipun biasanya memerlukan waktu beberapa jam.

Jalankan kembali perintah berikut:

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
    --format="get(managed.domainStatus)"

Jika status domain Anda adalah FAILED_NOT_VISIBLE, mungkin karena propagasi belum selesai.

Untuk mengetahui informasi mendetail, lihat bagian status domain sertifikat SSL yang dikelola Google di halaman Pemecahan masalah.

Langkah 5: Uji dengan OpenSSL

Setelah status sertifikat dan domain aktif, diperlukan waktu hingga 30 menit agar load balancer mulai menggunakan sertifikat SSL yang dikelola Google.

Untuk menguji, jalankan perintah OpenSSL berikut, dengan mengganti DOMAIN dengan nama DNS Anda dan IP_ADDRESS dengan alamat IP load balancer Anda.

echo | openssl s_client -showcerts -servername DOMAIN -connect IP_ADDRESS:443 -verify 99 -verify_return_error

Perintah ini menampilkan sertifikat yang ditampilkan load balancer ke klien. Bersama dengan informasi mendetail lainnya, output harus menyertakan rantai sertifikat dan Verify return code: 0 (ok).

Prosedur tambahan

Bagian ini berisi prosedur tambahan untuk mengelola sertifikat Anda.

Mendukung beberapa domain dengan sertifikat SSL yang dikelola Google

Beberapa nama alternatif subjek didukung. Setiap sertifikat SSL yang dikelola Google mendukung hingga jumlah maksimum domain per sertifikat SSL yang dikelola Google.

Jika memiliki lebih dari jumlah maksimum domain, Anda harus meminta beberapa sertifikat yang dikelola Google. Misalnya, jika Anda mencoba membuat sertifikat yang dikelola Google dengan (maksimum + 1) domain, Google tidak akan menerbitkan sertifikat apa pun. Sebagai gantinya, Anda harus membuat dua sertifikat yang dikelola Google atau lebih dan secara eksplisit menyatakan domain mana yang terkait dengan setiap sertifikat.

Google Cloud menerapkan Server Name Indication (SNI), seperti yang ditentukan dalam RFC 6066.

Jika ada domain atau subdomain dalam sertifikat terkelola yang tidak mengarah ke alamat IP load balancer, atau mengarah ke IP bersama dengan IP load balancer, proses perpanjangan akan gagal. Untuk menghindari kegagalan perpanjangan, pastikan semua domain dan subdomain Anda mengarah ke alamat IP load balancer.

Memperpanjang sertifikat SSL yang dikelola Google

Google Cloud menyediakan sertifikat terkelola yang berlaku selama 90 hari. Sekitar satu bulan sebelum masa berlaku berakhir, proses perpanjangan sertifikat Anda akan otomatis dimulai. Untuk ini, Certificate Authority (CA) dipilih yang ada dalam data DNS Certification Authority Authorization (CAA) domain Anda dan dalam daftar CA.

CA yang digunakan untuk perpanjangan mungkin berbeda dengan CA yang digunakan untuk menerbitkan versi sebelumnya dari sertifikat yang dikelola Google. Anda dapat mengontrol CA yang digunakan Google Cloud untuk perpanjangan dengan memastikan bahwa data DNS CAA domain Anda menentukan satu CA dari daftar CA yang digunakan sertifikat yang dikelola Google.

Jika ada domain atau subdomain dalam sertifikat terkelola yang tidak mengarah ke alamat IP load balancer, atau mengarah ke IP bersama dengan IP load balancer, proses perpanjangan akan gagal. Untuk menghindari kegagalan perpanjangan, pastikan semua domain dan subdomain Anda mengarah ke alamat IP load balancer.

Menentukan CA yang dapat menerbitkan sertifikat yang dikelola Google

Di software DNS, sebaiknya Anda secara eksplisit memberikan otorisasi kepada CA yang ingin Anda izinkan untuk menerbitkan sertifikat yang dikelola Google. Meskipun tidak diperlukan dalam setiap skenario, hal ini diperlukan dalam situasi tertentu.

Misalnya, jika Anda menggunakan layanan DNS eksternal dan sertifikat yang dikelola Google dicabut, layanan tersebut mungkin hanya memvalidasi sertifikat baru yang diterbitkan oleh satu atau beberapa CA tertentu.

Untuk melakukannya, buat atau ubah data CAA untuk menyertakan pki.goog atau letsencrypt.org atau keduanya. Jika Anda tidak memiliki data CAA, perilaku defaultnya adalah mengizinkan pki.goog dan letsencrypt.org.

DOMAIN. CAA 0 issue "pki.goog"
DOMAIN. CAA 0 issue "letsencrypt.org"

Dukungan untuk sertifikat letsencrypt.org disediakan berdasarkan upaya terbaik. Untuk keandalan terbaik, izinkan pki.goog dan letsencrypt.org. Jika Anda menentukan hanya satu CA, hanya CA tersebut yang akan digunakan untuk membuat dan memperpanjang sertifikat Anda. Pendekatan ini tidak direkomendasikan.

Saat Anda pertama kali membuat sertifikat, Google Cloud akan memilih pki.goog atau letsencrypt.org dan menggunakannya untuk menerbitkan sertifikat Anda. Saat Google memperpanjang sertifikat Anda, sertifikat Anda mungkin dikeluarkan oleh CA lain, bergantung pada CA yang telah Anda tentukan dalam data CAA (jika Anda membuatnya). Sertifikat Anda mungkin diperpanjang oleh CA yang berbeda dalam salah satu kasus berikut:

• Anda tidak memiliki data CAA DNS untuk domain Anda.
• Anda telah menyertakan kedua CA dalam data CAA DNS.

Untuk mengetahui informasi selengkapnya, lihat RFC, Data DNS CAA.

letsencrypt.org mengeluarkan Nama Domain Internasional (IDN). pki.goog saat ini tidak mendukung IDN.

Jika Anda menggunakan Cloud DNS, pelajari cara menambahkan data, dan pastikan untuk menetapkan flag --type ke CAA.

Catatan: Saat Anda menambahkan CA dalam data CAA, mungkin perlu waktu yang cukup lama agar DNS menyebarkan perubahan tersebut dan membuatnya terlihat oleh CA. Akibatnya, proses perpanjangan sertifikat mungkin awalnya gagal, tetapi pada akhirnya berhasil. Untuk informasi selengkapnya, lihat Memecahkan masalah sertifikat SSL.

Mengganti sertifikat SSL yang ada

Untuk mengganti sertifikat SSL yang ada:

1. Mulai proses pembuatan sertifikat SSL yang dikelola Google pengganti. Sertifikat ini tidak AKTIF pada tahap ini.

2. Update proxy target sehingga daftar sertifikat yang dirujuk menyertakan sertifikat SSL pengganti beserta sertifikat SSL saat ini. Langkah-langkah untuk mengupdate proxy target bervariasi, sebagai berikut:

   • Memperbarui proxy HTTPS target
   • Memperbarui proxy SSL target
   Catatan: Agar dapat terus menayangkan traffic, proxy target harus terus mereferensikan sertifikat SSL saat ini. Agar sertifikat pengganti dapat menyelesaikan proses penyediaannya, proxy target juga harus mereferensikan sertifikat pengganti.

3. Tunggu hingga sertifikat SSL pengganti menyelesaikan penyediaan. Penyediaan mungkin memerlukan waktu hingga 60 menit. Setelah penyediaan selesai, status sertifikat menjadi ACTIVE.

   Catatan: Penyediaan sertifikat yang dikelola Google mungkin memerlukan waktu hingga 60 menit sejak perubahan konfigurasi DNS dan load balancer Anda telah diterapkan di seluruh internet. Jika Anda baru-baru ini memperbarui konfigurasi DNS, mungkin diperlukan waktu yang cukup lama agar perubahan diterapkan sepenuhnya. Terkadang propagasi memerlukan waktu hingga 72 jam di seluruh dunia, meskipun biasanya memerlukan waktu beberapa jam. Untuk mengetahui informasi selengkapnya tentang propagasi DNS, lihat Penerapan perubahan.

4. Tunggu 30 menit lagi untuk memastikan sertifikat pengganti tersedia untuk semua Google Front End (GFE).

5. Perbarui proxy target untuk menghapus sertifikat SSL yang Anda ganti dari daftar sertifikat yang dirujuk. Langkah-langkah untuk memperbarui proxy target bervariasi, sebagai berikut:

   • Memperbarui proxy HTTPS target
   • Memperbarui proxy SSL target

6. Tunggu 10 menit, dan pastikan load balancer menggunakan sertifikat SSL pengganti, bukan yang lama.

7. Update proxy target lagi, dengan menghapus resource sertifikat SSL lama. Anda dapat menghapus resource sertifikat SSL jika tidak lagi direferensikan oleh proxy target apa pun.

Jika Anda tidak menghapus sertifikat SSL lama, sertifikat tersebut akan tetap AKTIF hingga masa berlakunya habis.

Bermigrasi dari sertifikat SSL yang dikelola sendiri ke sertifikat SSL yang dikelola Google

Saat memigrasikan load balancer dari penggunaan sertifikat SSL yang dikelola sendiri ke sertifikat SSL yang dikelola Google, Anda harus melakukan langkah-langkah berikut dalam urutan ini:

1. Buat sertifikat baru yang dikelola Google.
2. Kaitkan sertifikat baru yang dikelola Google dengan proxy target yang benar sekaligus mempertahankan pengaitan proxy target dengan sertifikat mandiri yang ada.
3. Tunggu hingga status sertifikat yang dikelola Google adalah ACTIVE.
4. Tunggu 30 menit agar sertifikat baru diterapkan ke Google Front End (GFE) yang menayangkan
5. Perbarui proxy target lagi, dengan menghapus resource sertifikat yang dikelola sendiri. Anda dapat menghapus resource sertifikat SSL yang dikelola sendiri jika tidak lagi direferensikan oleh proxy target apa pun.

Penting: Hanya hapus sertifikat yang dikelola sendiri dari proxy target setelah sertifikat baru Anda disediakan, ACTIVE, dan dikaitkan dengan proxy target. Jika Anda menghapus sertifikat yang dikelola sendiri terlalu cepat, load balancer Anda tidak akan memiliki sertifikat SSL yang valid, dan klien tidak dapat menggunakannya.

Menghapus sertifikat SSL

Sebelum menghapus sertifikat SSL, pastikan tidak ada proxy target HTTPS atau SSL yang mereferensikan sertifikat ini. Anda dapat melakukannya dengan dua cara:

• Hapus proxy target yang mereferensikan sertifikat ini.

• Perbarui proxy target yang mereferensikan sertifikat ini untuk mengecualikannya. Langkah-langkahnya bervariasi, sebagai berikut:

  • Memperbarui proxy target HTTPS.
  • Mengupdate proxy target SSL.

Untuk menghapus satu atau beberapa sertifikat SSL:

Konsol

Anda dapat menghapus sertifikat SSL global di tab Sertifikat Klasik di halaman Pengelola Sertifikat.

1. Buka tab Sertifikat Klasik di konsol Google Cloud.
   Buka Sertifikat Klasik
2. Pilih sertifikat SSL yang ingin Anda hapus.
3. Klik Delete.
4. Untuk mengonfirmasi, klik Hapus lagi.

gcloud

Untuk menghapus sertifikat SSL global (untuk Load Balancer Aplikasi eksternal global atau Load Balancer Jaringan proxy eksternal), gunakan perintah gcloud compute ssl-certificates delete dengan perintah --global:

gcloud compute ssl-certificates delete CERTIFICATE_NAME \
    --global

Ganti kode berikut:

• CERTIFICATE_NAME: nama sertifikat SSL

Langkah selanjutnya

• Untuk memecahkan masalah sertifikat SSL, lihat Memecahkan masalah sertifikat SSL.
• Untuk menggunakan skrip Terraform yang membuat sertifikat yang dikelola Google, lihat contoh Cloud Run di halaman Contoh modul Terraform untuk Load Balancer Aplikasi eksternal.