Menggunakan sertifikat SSL yang dikelola Google.

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

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

Sertifikat SSL yang dikelola Google adalah sertifikat Validasi Domain (DV) yangGoogle Cloud diperoleh dan dikelola 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 yang dikelola sendiri Compute Engine atau mempertimbangkan untuk menggunakan Certificate Manager.

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 proses pembuatan. Untuk membuat sertifikat saat membuat load balancer, lihat halaman cara penggunaan load balancer.

Sebelum memulai

Izin

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

  • 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 mencakup izin compute.sslCertificates.* dan salah 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

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 sudah 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.

  1. Buka tab Classic Certificates di konsol Google Cloud .
    Buka Sertifikat Klasik
  2. Klik Buat sertifikat SSL.
  3. Masukkan nama dan deskripsi opsional untuk sertifikat.
  4. Pilih Buat sertifikat yang dikelola Google.
  5. Tambahkan domain.
  6. Klik Buat.

gcloud

Untuk membuat sertifikat SSL yang dikelola Google global 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 untuk digunakan pada 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 sslCertificates.insert resource sertifikat yang dikelola Google, dengan mengganti PROJECT_ID dengan project ID Anda.

POST https://compute.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/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 Certificate Manager.

  1. Buka tab Classic Certificates di konsol Google Cloud .
    Buka Sertifikat Klasik
  2. Opsional: Memfilter 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-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, dengan mengganti 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 Anda

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 dalam status PROVISIONING, Anda dapat menggunakannya selama pembuatan load balancer, seperti yang dijelaskan dalam panduan cara berikut:

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

Konsol

Saat Anda mengupdate Load Balancer Aplikasi eksternal global atau Load Balancer Jaringan proxy eksternal menggunakan Google Cloud konsol, Google Cloud sertifikat SSL Anda akan otomatis dikaitkan 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 front end yang benar (harus berupa HTTPS, HTTP/2, SSL).
  6. Klik Sertifikat tambahan, lalu pilih sertifikat yang dikelola Google dari daftar drop-down.
  7. Klik Buat.

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 daftar sertifikat yang dirujuk mencakup semua sertifikat SSL lama yang valid serta sertifikat SSL baru. Perintah gcloud compute target-ssl-proxies update menggantikan 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 setidaknya satu sertifikat SSL. Proxy target dapat mereferensikan lebih dari satu sertifikat SSL. Untuk mengetahui detailnya, lihat Kumpulan target dan proxy target di kuota dan batas resource load balancing.

Langkah 3: Verifikasi asosiasi 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 hubungan 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 sedang bekerja dengan Certificate Authority untuk menerbitkan 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 catatan Anda, perhatikan hal berikut:

  • Pastikan data A DNS (untuk IPv4) dan data AAAA DNS (untuk IPv6) untuk domain dan subdomain Anda 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 gagal jika domain dan subdomain dalam sertifikat yang dikelola Google mengarah ke IP lain selain alamat IP aturan penerusan load balancer.

  • Pastikan penyedia DNS Anda merespons semua permintaan validasi domain global secara konsisten.

Sertifikat terkelola berhasil disediakan jika hal berikut terpenuhi:

  • 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.

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. Server tersebut menyimpan set data resource Anda dalam cache sesuai dengan time to live (TTL), yang berarti perintah dig atau nslookup dapat menampilkan nilai yang di-cache. Jika Anda menggunakan Cloud DNS, lihat Propagasi perubahan.

Waktu penerapan data DNS

Data A dan AAAA DNS yang baru diupdate dapat memerlukan waktu yang cukup lama untuk diterapkan sepenuhnya. Terkadang, propagasi di seluruh internet memerlukan waktu hingga 72 jam di seluruh dunia, meskipun biasanya hanya 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, hal ini mungkin karena propagasi belum selesai.

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

Validasi domain multi-perspektif

Google Cloud memperpanjang sertifikat yang dikelola Google secara berkala dengan memintanya dari certificate authority (CA). CA yang Google Cloud bekerja sama untuk memperpanjang sertifikat Anda menggunakan metode validasi domain multi-perspektif yang dikenal sebagai Multi-Perspective Issuance Corroboration (MPIC). Sebagai bagian dari proses ini, otoritas sertifikat memverifikasi kontrol domain dengan memeriksa setelan DNS domain dan mencoba menghubungi server di balik alamat IP domain. Verifikasi ini dilakukan dari berbagai sudut pandang di internet. Jika proses validasi gagal, sertifikat yang dikelola Google akan gagal diperpanjang. Akibatnya, load balancer Anda menyajikan sertifikat yang sudah habis masa berlakunya kepada klien, sehingga pengguna browser mengalami error sertifikat dan klien API mengalami kegagalan koneksi.

Untuk mencegah kegagalan validasi domain multi-perspektif karena kesalahan konfigurasi data DNS, perhatikan hal-hal berikut:

  • Data A DNS (IPv4) dan data AAAA DNS (IPv6) untuk domain dan subdomain Anda hanya mengarah ke alamat IP (atau alamat) yang terkait dengan aturan penerusan load balancer (atau aturan). Keberadaan alamat lain dalam catatan dapat menyebabkan validasi gagal.
  • CA, yang melakukan validasi data DNS, membuat kueri data DNS dari beberapa lokasi. Pastikan penyedia DNS Anda merespons semua permintaan validasi domain global secara konsisten.
  • Menggunakan GeoDNS (menampilkan alamat IP yang berbeda berdasarkan lokasi permintaan) atau kebijakan DNS berbasis lokasi dapat menyebabkan respons yang tidak konsisten dan menyebabkan validasi gagal. Jika penyedia DNS Anda menggunakan GeoDNS, nonaktifkan GeoDNS, atau pastikan semua region menampilkan alamat IP load balancer yang sama.
  • Anda harus secara eksplisit menentukan alamat IP load balancer dalam konfigurasi DNS Anda. Lapisan perantara, seperti CDN, dapat menyebabkan perilaku yang tidak dapat diprediksi. Alamat IP harus dapat diakses secara langsung tanpa pengalihan, firewall, atau CDN di jalur permintaan. Untuk mempelajari lebih lanjut, lihat bagian Load balancer di belakang CDN dalam dokumen ini.
  • Sebaiknya gunakan pemeriksa propagasi global DNS pilihan Anda untuk memverifikasi bahwa semua data DNS yang relevan diselesaikan dengan benar dan konsisten di seluruh dunia.

Memverifikasi perubahan konfigurasi

Setelah mengonfigurasi data DNS, Anda dapat memverifikasi bahwa data tersebut sudah benar dengan membuat sertifikat baru dan menghubungkannya ke load balancer bersama dengan sertifikat yang ada. Langkah ini akan memaksakan pemeriksaan penyediaan sertifikat langsung dengan CA, sehingga Anda dapat memverifikasi perubahan konfigurasi dalam beberapa menit. Tanpa hal ini, perpanjangan otomatis sertifikat yang ada dapat memakan waktu berhari-hari atau berminggu-minggu, sehingga menimbulkan ketidakpastian tentang penyiapan Anda.

Jika status sertifikat berubah menjadi ACTIVE, hal ini menunjukkan bahwa sertifikat telah diterbitkan, sehingga mengonfirmasi bahwa konfigurasi DNS Anda sudah benar. Pada tahap ini, sebaiknya hapus sertifikat sebelumnya untuk menghindari kepemilikan dua sertifikat terpisah untuk domain yang sama. Proses ini tidak mengganggu traffic ke load balancer Anda.

Sertifikat baru berfungsi sebagai alat validasi—pembuatannya mengonfirmasi bahwa validasi domain multi-perspektif menggunakan MPIC berfungsi dengan benar untuk penyiapan Anda.

Load balancer di belakang CDN

Untuk load balancer yang mengaktifkan CDN, beberapa penyedia CDN pihak ketiga di jalur permintaan mungkin mencegah keberhasilan permintaan validasi. Hal ini dapat terjadi jika penyedia CDN secara aktif mem-proxy traffic HTTP(S).

Dalam kasus tersebut, sebaiknya migrasikan sertifikat Anda ke Certificate Manager dan gunakan metode otorisasi DNS untuk menyediakan sertifikat yang dikelola Google. Pendekatan terakhir tidak memerlukan CA untuk menghubungi load balancer Anda.

Langkah 5: Uji dengan OpenSSL

Setelah status sertifikat dan domain menjadi aktif, diperlukan waktu hingga 30 menit agar load balancer Anda 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 diberikan load balancer kepada klien. Selain informasi mendetail lainnya, output harus mencakup 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 Anda memiliki lebih dari jumlah maksimum domain, Anda harus meminta beberapa sertifikat yang dikelola Google. Misalnya, jika Anda mencoba membuat sertifikat yang dikelola Google dengan (jumlah maksimum + 1) domain, Google tidak akan menerbitkan sertifikat apa pun. Sebagai gantinya, Anda harus membuat dua sertifikat yang dikelola Google atau lebih dan menyatakan secara eksplisit domain mana yang terkait dengan setiap sertifikat.

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

Untuk membantu memastikan bahwa sertifikat Anda tidak gagal dalam langkah validasi domain pada proses perpanjangan, tinjau persyaratan untuk data A dan AAAA DNS Anda.

Memperpanjang sertifikat SSL yang dikelola Google

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

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

Untuk membantu memastikan bahwa sertifikat Anda tidak gagal dalam langkah validasi domain pada proses perpanjangan, tinjau persyaratan untuk data A dan AAAA DNS Anda.

Menentukan CA yang dapat menerbitkan sertifikat yang dikelola Google

Di software DNS Anda, sebaiknya Anda secara eksplisit mengizinkan CA yang ingin Anda izinkan 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 catatan 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 diberikan berdasarkan upaya terbaik. Untuk keandalan terbaik, izinkan pki.goog dan letsencrypt.org. Jika Anda hanya menentukan salah satu CA, hanya CA tersebut yang digunakan untuk membuat dan memperpanjang sertifikat Anda. Pendekatan ini tidak disarankan.

Saat Anda pertama kali membuat sertifikat, Google Cloud 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 masalah Nama Domain Internasional (IDN). pki.goog saat ini tidak mendukung IDN.

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

Mengganti sertifikat SSL yang ada

Untuk mengganti sertifikat SSL yang ada:

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

  2. Perbarui proxy target sehingga daftar sertifikat yang dirujuk mencakup sertifikat SSL pengganti bersama dengan sertifikat SSL saat ini. Langkah-langkah untuk mengupdate proxy target bervariasi, sebagai berikut:

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

  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:

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

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

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

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 target proxy yang benar sambil mempertahankan pengaitan target proxy dengan sertifikat yang dikelola sendiri 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 melayani
  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 mana pun.

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:

Untuk menghapus satu atau beberapa sertifikat SSL:

Konsol

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

  1. Buka tab Classic Certificates 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 berikutnya

  • 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.