Memecahkan masalah sertifikat SSL

Prosedur pemecahan masalah bergantung pada jenis sertifikat SSL yang digunakan.

Memecahkan masalah sertifikat yang dikelola Google

Untuk sertifikat yang dikelola Google, ada dua jenis status:

• Status terkelola
• Status domain

Status terkelola

Untuk memeriksa status sertifikat, jalankan perintah berikut:

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

Nilai untuk status terkelola adalah sebagai berikut:

Status terkelola	Penjelasan
PROVISIONING	Sertifikat yang dikelola Google telah dibuat dan Google Cloud bekerja sama dengan Certificate Authority untuk menandatanganinya. Penyediaan sertifikat yang dikelola Google mungkin memerlukan waktu hingga 60 menit sejak perubahan konfigurasi DNS dan load balancer Anda diterapkan di seluruh internet. Jika Anda baru-baru ini memperbarui konfigurasi DNS, mungkin perlu waktu yang cukup lama agar perubahan tersebut diterapkan sepenuhnya. Terkadang propagasi memerlukan waktu hingga 72 jam di seluruh dunia, meskipun biasanya memerlukan waktu beberapa jam. Untuk mengetahui informasi selengkapnya tentang penerapan DNS, lihat Penerapan perubahan. Jika sertifikat tetap dalam status PROVISIONING, pastikan sertifikat yang benar dikaitkan dengan proxy target. Anda dapat memeriksanya dengan menjalankan perintah gcloud compute target-https-proxies describe atau gcloud compute target-ssl-proxies describe.
ACTIVE	Sertifikat SSL yang dikelola Google diperoleh dari Certificate Authority. Mungkin perlu waktu tambahan 30 menit agar tersedia untuk digunakan oleh load balancer.
PROVISIONING_FAILED	Anda mungkin melihat PROVISIONING_FAILED sebentar meskipun sertifikat Anda sebenarnya ACTIVE. Periksa kembali statusnya. Jika statusnya tetap PROVISIONING_FAILED, sertifikat yang dikelola Google telah dibuat, tetapi Certificate Authority tidak dapat menandatanganinya. Pastikan Anda telah menyelesaikan semua langkah dalam Menggunakan sertifikat SSL yang dikelola Google. Google Cloud mencoba lagi penyediaan hingga berhasil atau status berubah menjadi PROVISIONING_FAILED_PERMANENTLY.
PROVISIONING_FAILED_PERMANENTLY	Sertifikat yang dikelola Google dibuat, tetapi Certificate Authority tidak dapat menandatanganinya karena masalah konfigurasi DNS atau load balancer. Dalam status ini, Google Cloud tidak mencoba lagi penyediaan. Buat penggantian sertifikat SSL yang dikelola Google, dan pastikan penggantian tersebut terkait dengan proxy target load balancer Anda. Verifikasi atau selesaikan semua langkah dalam Menggunakan sertifikat SSL yang dikelola Google. Setelah itu, Anda dapat menghapus sertifikat yang gagal penyediaannya secara permanen.
RENEWAL_FAILED	Perpanjangan sertifikat yang dikelola Google gagal karena masalah pada load balancer atau konfigurasi DNS. Jika salah satu domain atau subdomain dalam sertifikat terkelola tidak mengarah ke alamat IP load balancer menggunakan data A/AAAA, proses perpanjangan akan gagal. Sertifikat yang ada akan terus ditayangkan, tetapi masa berlakunya akan segera berakhir. Periksa konfigurasi Anda. Jika statusnya tetap RENEWAL_FAILED, sediakan sertifikat baru, beralihlah untuk menggunakan sertifikat baru, dan hapus sertifikat sebelumnya. Untuk informasi selengkapnya tentang perpanjangan sertifikat, lihat Perpanjangan sertifikat SSL yang dikelola Google.

Status domain

Untuk memeriksa status domain, jalankan perintah berikut:

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

Nilai untuk status domain dijelaskan dalam tabel ini.

Status domain	Penjelasan
PROVISIONING	Sertifikat yang dikelola Google dibuat untuk domain. Google Cloud bekerja sama dengan Certificate Authority untuk menandatangani sertifikat.
ACTIVE	Domain telah berhasil divalidasi untuk menyediakan sertifikat. Jika sertifikat SSL ditujukan untuk beberapa domain, sertifikat hanya dapat disediakan setelah semua domain memiliki status ACTIVE dan status dikelola sertifikat juga ACTIVE.
FAILED_NOT_VISIBLE	Penyediaan sertifikat belum selesai untuk domain. Salah satu dari hal berikut mungkin menjadi masalahnya: Data DNS domain tidak me-resolve ke alamat IP load balancer Google Cloud . Untuk mengatasi masalah ini, perbarui data DNS A dan AAAA agar mengarah ke alamat IP load balancer Anda. DNS tidak boleh me-resolve ke alamat IP selain alamat IP load balancer. Misalnya, jika data A me-resolve ke load balancer yang benar, tetapi AAAA me-resolve ke sesuatu yang lain, status domain adalah FAILED_NOT_VISIBLE. Data DNS A dan AAAA yang baru diperbarui dapat memerlukan waktu yang cukup lama untuk diterapkan sepenuhnya. Terkadang, penyebaran di seluruh internet memerlukan waktu hingga 72 jam di seluruh dunia, meskipun biasanya memerlukan waktu beberapa jam. Status domain akan terus menjadi FAILED_NOT_VISIBLE hingga propagasi selesai. Sertifikat SSL tidak dilampirkan ke proxy target load balancer. Untuk mengatasi masalah ini, update konfigurasi load balancer Anda. Port frontend untuk aturan penerusan global tidak menyertakan port 443 untuk Load Balancer Jaringan proxy eksternal dengan proxy SSL. Hal ini dapat diatasi dengan menambahkan aturan penerusan baru dengan port 443. Peta sertifikat Pengelola Sertifikat dilampirkan ke proxy target. Peta sertifikat yang dilampirkan akan diprioritaskan dan sertifikat yang dilampirkan secara langsung akan diabaikan. Masalah ini dapat diatasi dengan melepas peta sertifikat dari proxy. Jika status terkelola adalah PROVISIONING, Google Cloud akan terus mencoba lagi penyediaan, meskipun status domain adalah FAILED_NOT_VISIBLE.
FAILED_CAA_CHECKING	Penyediaan sertifikat gagal karena masalah konfigurasi pada data CAA domain Anda. Pastikan Anda telah mengikuti prosedur yang benar.
FAILED_CAA_FORBIDDEN	Penyediaan sertifikat gagal karena data CAA domain Anda tidak menentukan CA yang Google Cloud perlu digunakan. Pastikan Anda telah mengikuti prosedur yang benar.
FAILED_RATE_LIMITED	Penyediaan sertifikat gagal karena Otoritas Sertifikasi memiliki permintaan penandatanganan sertifikat dengan pembatasan kapasitas. Anda dapat menyediakan sertifikat baru, beralih untuk menggunakan sertifikat baru, dan menghapus sertifikat sebelumnya, atau menghubungi Google Cloud Dukungan.

Penting: Untuk sertifikat yang dikelola Google, proses penyediaan mungkin akan tertunda jika beberapa sertifikat dengan domain yang tumpang-tindih diminta dalam jangka waktu yang singkat. Permintaan sertifikat dengan kumpulan domain yang tumpang-tindih tidak diproses secara paralel.
Google Cloud hanya menerbitkan satu sertifikat terkelola per domain dalam satu waktu. Waktu tunggu upaya untuk sertifikat dengan domain yang tidak dikonfigurasi dengan benar akan habis setelah 30 menit, sedangkan sertifikat dengan domain yang ditetapkan dengan benar biasanya diterbitkan dalam waktu yang jauh lebih singkat.

Perpanjangan sertifikat terkelola

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

Validasi domain multiperspektif

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

Untuk mencegah kegagalan validasi domain multi-perspektif untuk data DNS yang salah dikonfigurasi, perhatikan hal-hal berikut:

• Data A DNS (IPv4) dan data AAAA DNS (IPv6) untuk domain dan subdomain apa pun hanya mengarah ke alamat IP (atau alamat) yang terkait dengan aturan penerusan (atau aturan) load balancer. Adanya alamat lain dalam data dapat menyebabkan validasi gagal.
• CA, yang melakukan validasi data DNS, mengkueri data DNS dari beberapa lokasi. Pastikan penyedia DNS Anda merespons secara konsisten semua permintaan validasi domain global.
• 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, atau pastikan semua region menampilkan alamat IP load balancer yang sama.
• Anda harus menentukan alamat IP load balancer secara eksplisit dalam konfigurasi DNS. 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 balik CDN dalam dokumen ini.
• Sebaiknya gunakan pemeriksa propagasi global DNS pilihan Anda untuk memverifikasi bahwa semua data DNS yang relevan di-resolve 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 memaksa pemeriksaan penyediaan sertifikat segera dengan CA, sehingga Anda dapat memverifikasi perubahan konfigurasi dalam hitungan menit. Tanpa ini, perpanjangan otomatis sertifikat yang ada dapat memerlukan waktu berhari-hari atau berminggu-minggu, sehingga menimbulkan ketidakpastian tentang penyiapan Anda.

Jika status sertifikat menjadi ACTIVE, hal ini menunjukkan bahwa sertifikat telah diterbitkan, sehingga mengonfirmasi bahwa konfigurasi DNS Anda sudah benar. Pada tahap ini, sebaiknya hapus sertifikat sebelumnya agar tidak memiliki 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 permintaan validasi berhasil. Hal ini dapat terjadi jika penyedia CDN secara aktif melakukan proxy pada 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 kedua tidak memerlukan CA untuk menghubungi load balancer Anda.

Memecahkan masalah sertifikat SSL yang dikelola sendiri

Panduan ini menjelaskan cara memecahkan masalah konfigurasi untuk sertifikat SSL yang dikelola sendiri.

Sertifikat tidak dapat diuraikan

Google Cloud memerlukan sertifikat dalam format PEM. Jika sertifikat berformat PEM, periksa hal berikut:

Anda dapat memvalidasi sertifikat menggunakan perintah OpenSSL berikut, dengan mengganti CERTIFICATE_FILE dengan jalur ke file sertifikat Anda:

openssl x509 -in CERTIFICATE_FILE -text -noout

Jika OpenSSL tidak dapat mengurai sertifikat Anda:

• Hubungi CA Anda untuk mendapatkan bantuan.
• Buat kunci pribadi dan sertifikat baru.

Nama umum atau nama alternatif subjek tidak ada

Google Cloud mewajibkan sertifikat Anda memiliki salah satu atribut nama umum (CN) atau nama alternatif subjek (SAN). Lihat Membuat CSR untuk mengetahui informasi tambahan.

Jika kedua atribut tidak ada, Google Cloud akan menampilkan pesan error seperti berikut saat Anda mencoba membuat sertifikat yang dikelola sendiri:

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource:
 -   The SSL certificate is missing a Common Name(CN) or Subject Alternative
   Name(SAN).

Kunci pribadi tidak dapat diuraikan

Google Cloud memerlukan kunci pribadi berformat PEM yang memenuhi kriteria kunci pribadi.

Anda dapat memvalidasi kunci pribadi menggunakan perintah OpenSSL berikut, dengan mengganti PRIVATE_KEY_FILE dengan jalur ke kunci pribadi Anda:

    openssl rsa -in PRIVATE_KEY_FILE -check

Respons berikut menunjukkan masalah pada kunci pribadi Anda:

• unable to load Private Key
• Expecting: ANY PRIVATE KEY
• RSA key error: n does not equal p q
• RSA key error: d e not congruent to 1
• RSA key error: dmp1 not congruent to d
• RSA key error: dmq1 not congruent to d
• RSA key error: iqmp not inverse of q

Untuk memperbaiki masalah ini, Anda harus membuat kunci pribadi dan sertifikat baru.

Kunci pribadi dengan frasa sandi

Jika OpenSSL meminta frasa sandi, Anda harus menghapus frasa sandi dari kunci pribadi sebelum dapat menggunakannya dengan Google Cloud. Anda dapat menggunakan perintah OpenSSL berikut:

openssl rsa -in PRIVATE_KEY_FILE \
    -out REPLACEMENT_PRIVATE_KEY_FILE

Ganti placeholder dengan nilai yang valid:

• PRIVATE_KEY_FILE: Jalur ke kunci pribadi Anda yang dilindungi dengan frasa sandi
• REPLACEMENT_PRIVATE_KEY_FILE: Jalur tempat Anda ingin menyimpan salinan kunci pribadi teks biasa

Masa berlaku intermediate certificate akan segera berakhir

Jika masa berlaku sertifikat intermediate berakhir sebelum sertifikat server (leaf), hal ini mungkin menunjukkan bahwa CA Anda tidak mengikuti praktik terbaik.

Saat masa berlaku sertifikat intermediate berakhir, sertifikat leaf yang digunakan di Google Cloud mungkin menjadi tidak valid. Hal ini bergantung pada klien SSL, sebagai berikut:

• Beberapa klien SSL hanya melihat waktu habis masa berlaku sertifikat leaf dan mengabaikan sertifikat intermediate yang telah habis masa berlakunya.
• Beberapa klien SSL memperlakukan rantai dengan sertifikat perantara yang masa berlakunya telah habis sebagai tidak valid dan menampilkan peringatan.

Untuk menyelesaikan masalah ini:

1. Tunggu hingga CA beralih ke sertifikat perantara baru.
2. Minta sertifikat baru dari mereka.
3. Upload ulang sertifikat baru dengan kunci baru.

CA Anda mungkin juga mengizinkan penandatanganan silang untuk sertifikat intermediate. Hubungi CA Anda untuk mengonfirmasi.

Eksponen publik RSA terlalu besar

Pesan error berikut muncul saat eksponen publik RSA lebih besar dari 65537. Pastikan untuk menggunakan 65537, seperti yang ditentukan dalam RFC 4871.

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource:
 -   The RSA public exponent is too large.

Menghapus sertifikat SSL dari target-proxy

Langkah-langkah berikut menunjukkan cara menghapus satu sertifikat SSL yang dilampirkan ke proxy https target:

1. Ekspor target-https-proxy ke file sementara.

   gcloud compute target-https-proxies export TARGET_PROXY_NAME > /tmp/proxy
   

2. Edit file /tmp/proxy dan hapus baris berikut:

   sslCertificates:
   -   https://www.googleapis.com/compute/v1/projects/...
   

3. Impor file /tmp/proxy.

   gcloud compute target-https-proxies import TARGET_PROXY_NAME \
      --source=/tmp/proxy
   

4. Opsional: Hapus sertifikat SSL.

   gcloud compute ssl-certificates delete SSL_CERT_NAME
   

Ganti kode berikut:

• TARGET_PROXY_NAME: nama resource proxy https target.
• SSL_CERT_NAME: nama sertifikat SSL.