Ringkasan TLS bersama

Mutual TLS, atau mTLS, adalah protokol standar industri untuk autentikasi bersama antara klien dan server. mTLS memastikan bahwa klien dan server saling mengautentikasi dengan memverifikasi bahwa masing-masing memiliki sertifikat valid yang dikeluarkan oleh certificate authority (CA) tepercaya. Tidak seperti TLS standar, yang hanya mengautentikasi server, mTLS mengharuskan klien dan server untuk menunjukkan sertifikat, yang mengonfirmasi identitas kedua belah pihak sebelum komunikasi terjalin.

mTLS dikonfigurasi pada resource proxy HTTPS target dari semua Load Balancer Aplikasi:

  • Load Balancer Aplikasi eksternal global
  • Load Balancer Aplikasi klasik
  • Load Balancer Aplikasi eksternal regional
  • Load Balancer Aplikasi internal regional
  • Load Balancer Aplikasi internal lintas region

mTLS menggunakan Infrastruktur Kunci Publik (PKI) untuk mengautentikasi identitas entity yang berkomunikasi melalui jaringan. Infrastruktur ini mencakup tiga komponen: klien, server, dan Certificate Authority (CA). mTLS untuk load balancer mendukung fitur berikut:

  • Memverifikasi bahwa klien yang menampilkan sertifikat memiliki kunci pribadinya.

  • Validasi sertifikat klien menggunakan salah satu mode validasi klien.

  • Memvalidasi sertifikat klien terhadap anchor PKI (root certificate) yang diupload, dengan opsi untuk menambahkan beberapa anchor secara terpisah guna memungkinkan migrasi yang lancar dari PKI lama ke PKI baru tanpa periode nonaktif.

  • Berikan intermediate certificate tambahan untuk membantu membuat jalur validasi sertifikat klien terhadap anchor PKI (root certificate) yang ditentukan. Sertifikat perantara ini memungkinkan mTLS berfungsi dengan klien yang tidak menyediakan rantai sertifikat lengkap.

  • Membuat dan meneruskan sidik jari sertifikat ke backend sebagai header permintaan kustom.

  • Teruskan kolom yang dipilih yang diekstrak dari sertifikat ke backend menggunakan header kustom.

  • Teruskan hasil validasi dan error validasi apa pun ke backend menggunakan header kustom.

Persyaratan sertifikat

Saat mengonfigurasi sertifikat untuk mTLS, pastikan sertifikat tersebut mematuhi persyaratan berikut:

  • Alat kriptografi modern menjadi dasar autentikasi mTLS. Sertifikat harus menggunakan algoritma RSA atau ECDSA untuk pertukaran kunci.

  • Untuk sertifikat klien (entitas akhir):

    • Ekstensi Basic Constraints tidak boleh berisi CA=true.

    • Ekstensi Penggunaan Kunci yang Diperpanjang harus berisi clientAuth.

    • Ekstensi Penggunaan Kunci yang Diperpanjang tidak boleh berisi kolom codeSigning, timeStamping, atau OCSPSigning.

    • Masa berlaku sertifikat tidak boleh habis.

    • Sertifikat klien tidak boleh berupa sertifikat yang ditandatangani sendiri.

  • Untuk root certificate dan intermediate certificate:

Arsitektur deployment mTLS

Dengan mTLS, Anda dapat mengonfigurasi resource konfigurasi kepercayaan, yang berisi trust store. Trust store mengenkapsulasi trust anchor (root certificate) dan, secara opsional, satu atau beberapa intermediate certificate. Saat menerima sertifikat klien, load balancer akan memvalidasinya dengan membuat rantai kepercayaan dari sertifikat klien kembali ke trust anchor yang dikonfigurasi.

Berikut adalah ringkasan singkat tentang berbagai resource yang perlu Anda konfigurasi untuk menyiapkan mTLS bagi load balancer:

  • Konfigurasi kepercayaan. Berisi satu resource trust store, yang kemudian merangkum trust anchor (root certificate) dan, secara opsional, satu atau beberapa intermediate certificate. Konfigurasi kepercayaan digunakan untuk membuat rantai kepercayaan antara sertifikat klien dan trust anchor. Untuk mengetahui informasi selengkapnya, lihat Konfigurasi kepercayaan.

    Secara opsional, jika Anda perlu menggunakan sertifikat yang ditandatangani sendiri, telah berakhir masa berlakunya, atau tidak valid, atau jika Anda tidak memiliki akses ke root certificate dan intermediate certificate, Anda dapat menambahkan sertifikat tersebut ke konfigurasi kepercayaan di kolom allowlistedCertificates. Anda tidak memerlukan trust store untuk menambahkan sertifikat ke daftar yang diizinkan.

    Menambahkan sertifikat ke daftar yang diizinkan berarti sertifikat tersebut selalu dianggap valid selama sertifikat dapat diuraikan, bukti kepemilikan kunci pribadi ditetapkan, dan batasan pada kolom SAN sertifikat terpenuhi.

  • Trust store. Berisi trust anchor dan sertifikat certificate authority (CA) perantara yang digunakan untuk membuat rantai kepercayaan dan memvalidasi sertifikat klien. CA digunakan untuk menerbitkan sertifikat tepercaya bagi klien. CA diidentifikasi oleh trust anchor load balancer (root certificate) atau sertifikat CA perantara.

    Anda dapat mengupload jenis root certificate dan intermediate certificate berikut ke trust store:

  • Autentikasi Klien (juga dikenal sebagai ServerTLSPolicy). Menentukan mode validasi klien dan resource konfigurasi kepercayaan yang akan digunakan saat memvalidasi sertifikat klien. Jika klien memberikan sertifikat yang tidak valid atau tidak memberikan sertifikat ke load balancer, mode validasi klien akan menentukan cara koneksi klien ditangani. Anda dapat menentukan semua parameter terkait autentikasi mTLS dalam kebijakan TLS server. Resource Autentikasi Klien (ServerTLSPolicy) dilampirkan ke resource proxy HTTPS target.

Diagram berikut menunjukkan berbagai komponen mTLS yang dilampirkan ke resource proxy HTTPS target dari Load Balancer Aplikasi global dan regional.

global

Diagram berikut menunjukkan komponen deployment Load Balancer Aplikasi eksternal. Arsitektur ini juga berlaku untuk Load Balancer Aplikasi internal lintas region, yang merupakan Load Balancer Aplikasi internal yang menggunakan komponen global.

Mutual TLS dengan komponen Load Balancer Aplikasi eksternal global.
Mutual TLS dengan komponen Load Balancer Aplikasi eksternal global (klik untuk memperbesar).

regional

Diagram berikut menunjukkan komponen deployment Load Balancer Aplikasi internal regional. Arsitektur ini juga berlaku untuk Load Balancer Aplikasi eksternal regional, yang merupakan Load Balancer Aplikasi eksternal yang menggunakan komponen regional.

Mutual TLS dengan komponen Load Balancer Aplikasi internal regional.
Mutual TLS dengan komponen Load Balancer Aplikasi internal regional (klik untuk memperbesar).

Mode validasi klien

Atribut clientValidationMode pada resource Client Authentication (ServerTLSPolicy) menentukan cara load balancer menangani koneksi klien. Mode ini menentukan apakah sertifikat klien yang tidak valid atau tidak ada akan ditolak secara ketat (REJECT_INVALID), ditolak kecuali untuk pemeriksaan X.509 tertentu yang dilonggarkan (ALLOW_VALIDATION_RELAXATIONS), atau diteruskan ke backend (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

Berbagai mode validasi klien adalah sebagai berikut:

  • Mengizinkan sertifikat klien yang tidak valid atau tidak ada (ALLOW_INVALID_OR_MISSING_CLIENT_CERT)
  • Tolak sertifikat klien yang tidak valid (REJECT_INVALID)
  • Mengizinkan pelonggaran validasi (ALLOW_VALIDATION_RELAXATIONS)

Mengizinkan sertifikat klien yang tidak valid atau tidak ada

Mode ALLOW_INVALID_OR_MISSING_CLIENT_CERT mengizinkan koneksi dari klien meskipun sertifikat klien gagal divalidasi atau klien tidak memberikan sertifikat. Dalam mode ini, load balancer mengizinkan koneksi dari klien dan meneruskan semua permintaan ke backend, terlepas dari apakah rantai kepercayaan dapat dibuat atau tidak.

Bukti kepemilikan kunci pribadi selalu diperiksa saat sertifikat klien ditampilkan. Jika klien tidak dapat membuktikan kepemilikan kunci pribadi, TLS handshake akan dihentikan meskipun mode validasi klien mengizinkan sertifikat klien yang tidak valid atau tidak ada.

Menolak sertifikat klien yang tidak valid

Mode REJECT_INVALID menolak koneksi jika klien tidak memberikan sertifikat atau jika validasi sertifikat gagal. Dalam mode ini, load balancer menghentikan koneksi dari klien jika tidak dapat membuat rantai kepercayaan dari sertifikat klien kembali ke trust anchor.

Mengizinkan pelonggaran validasi

Mode ALLOW_VALIDATION_RELAXATIONS menerapkan validasi sertifikat klien, tetapi memungkinkan pelonggaran pada pemeriksaan validasi tertentu—misalnya, selama migrasi saat sertifikat klien lama tidak memenuhi semua persyaratan sertifikat yang ketat. Jika sudah memiliki resource ServerTLSPolicy dalam mode REJECT_INVALID, Anda dapat mengupdatenya untuk menggunakan mode ALLOW_VALIDATION_RELAXATIONS dan menentukan daftar pelonggaran validasi yang ingin Anda izinkan.

Anda dapat menentukan satu atau beberapa nilai berikut di kolom clientValidationRelaxations:

  • ALLOW_MISSING_EKU: Memungkinkan sertifikat klien menghilangkan ekstensi Penggunaan Kunci yang Diperpanjang (EKU).

    ALLOW_MISSING_EKU hanya mengizinkan sertifikat yang tidak memiliki ekstensi EKU sama sekali; ekstensi EKU yang ada dengan tujuan yang salah tidak akan diabaikan. Misalnya, jika ekstensi EKU ada di sertifikat klien, ekstensi tersebut harus tetap menyertakan tujuan kunci clientAuth (OID 1.3.6.1.5.5.7.3.2) seperti yang ditentukan dalam persyaratan sertifikat. Jika sertifikat memiliki ekstensi EKU yang mencantumkan tujuan lain (seperti serverAuth), tetapi bukan clientAuth, koneksi akan ditolak.

  • ALLOW_SHA1_HASHING: Memungkinkan validasi rantai sertifikat klien yang ditandatangani menggunakan ringkasan pesan SHA-1 lama.

  • ALLOW_EXPIRED_LEAF_CERTIFICATE: Memungkinkan validasi sertifikat entitas akhir klien yang sudah tidak berlaku. Load balancer memvalidasi sertifikat entitas akhir klien yang sudah tidak berlaku seolah-olah waktu saat ini adalah satu detik sebelum akhir masa berlakunya (notAfter dikurangi satu detik). Hal ini memungkinkan sertifikat entitas akhir klien lulus pemeriksaan masa berlaku. Pelonggaran ini hanya berlaku untuk sertifikat entitas akhir klien dan tidak untuk sertifikat perantara atau root certificate dalam rantai. Sertifikat entitas akhir klien yang belum valid (saat waktu saat ini sebelum stempel waktu notBefore) masih ditolak.

Mode ALLOW_VALIDATION_RELAXATIONS memerlukan sertifikat klien dan memvalidasi rantai sertifikat terhadap resource konfigurasi kepercayaan yang dikonfigurasi, sekaligus menerapkan relaksasi validasi tertentu yang Anda tentukan di kolom clientValidationRelaxations.

Saat memilih ALLOW_VALIDATION_RELAXATIONS, Anda harus menentukan setidaknya satu relaksasi validasi. Jika Anda memilih beberapa relaksasi, semua relaksasi yang dipilih akan diterapkan secara bersamaan. Selama klien memberikan sertifikat yang valid setelah menerapkan relaksasi yang dipilih, load balancer akan menerima koneksi. Misalnya, jika Anda mengonfigurasi ALLOW_MISSING_EKU dan ALLOW_SHA1_HASHING, load balancer akan menerima koneksi dari klien yang menyajikan sertifikat yang valid, tetapi menghilangkan ekstensi Extended Key Usage (EKU) dan menggunakan hashing SHA-1.

Jika klien tidak memberikan sertifikat, atau jika validasi sertifikat gagal karena alasan apa pun yang tidak tercakup dalam relaksasi yang dikonfigurasi, load balancer akan menghentikan koneksi dan mencatat error ke Cloud Logging.

Google Cloud merekomendasikan penggunaan pelonggaran validasi hanya sebagai solusi sementara selama migrasi sertifikat. Menggunakan ALLOW_VALIDATION_RELAXATIONS lebih aman daripada menggunakan ALLOW_INVALID_OR_MISSING_CLIENT_CERT karena load balancer masih menerapkan semua pemeriksaan validasi lainnya dan tidak memerlukan logika validasi kustom di backend Anda.

Mengonfigurasi mTLS di load balancer

Berikut adalah ringkasan umum tentang langkah-langkah utama yang perlu Anda ikuti untuk mengonfigurasi mTLS di load balancer:

  1. Buat resource konfigurasi kepercayaan yang terdiri dari trust anchor (root certificate) dan intermediate certificate yang berfungsi sebagai root of trust.

  2. Tautkan konfigurasi kepercayaan ke resource Autentikasi Klien (ServerTLSPolicy), yang menentukan mode validasi klien.

  3. Lampirkan resource Autentikasi Klien (ServerTLSPolicy) ke resource proxy HTTPS target load balancer.

  4. Opsional: Anda dapat menggunakan header mTLS kustom untuk meneruskan informasi tentang koneksi mTLS ke layanan backend atau peta URL.

Untuk mempelajari penyiapan ini lebih lanjut secara mendetail, lihat panduan berikut:

Langkah-langkah validasi sertifikat klien

Saat memvalidasi sertifikat klien, load balancer melakukan hal berikut:

  1. Memverifikasi bahwa klien memiliki kunci pribadi.

    Klien membuktikan kepemilikan kunci pribadi yang terkait dengan kunci publik dalam sertifikat dengan membuat tanda tangan selama proses handshake. Load balancer memverifikasi tanda tangan ini menggunakan kunci publik klien. Jika verifikasi tanda tangan gagal, berarti klien bukan pemilik sertifikat. Dalam hal ini, TLS handshake akan dihentikan meskipun konfigurasi Anda mengizinkan sertifikat klien yang tidak valid atau tidak ada. Tidak ada error yang dicatat ke dalam log untuk Load Balancer Aplikasi eksternal global, tetapi error TLS dicatat ke dalam log di kolom proxyStatus untuk Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal.

  2. Verifikasi rantai kepercayaan.

    Load balancer memverifikasi rantai kepercayaan dengan memvalidasi sertifikat klien terhadap sertifikat yang dikonfigurasi dalam konfigurasi kepercayaan. Mode validasi klien menentukan apakah sertifikat klien yang tidak valid atau tidak ada ditolak secara ketat (REJECT_INVALID), ditolak kecuali untuk pemeriksaan X.509 tertentu yang dilonggarkan (ALLOW_VALIDATION_RELAXATIONS), atau diteruskan ke backend (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

    Pemeriksaan verifikasi juga mencakup hal berikut:

    • Sertifikat klien, perantara, dan root mematuhi persyaratan sertifikat.
    • Kolom subjek dalam sertifikat induk cocok dengan kolom penerbit dalam sertifikat turunan. Verifikasi ini memastikan bahwa identitas (subjek) sertifikat induk sama dengan identitas yang tercantum sebagai penerbit dalam sertifikat turunan.
    • ID Kunci Subjek (SKID) sertifikat induk cocok dengan ID Kunci Otoritas (AKID) di sertifikat turunan. Kecocokan ini mengonfirmasi bahwa sertifikat turunan diterbitkan oleh root authority yang benar dan dapat dipercaya karena kunci publik root dirujuk dalam AKID untuk memverifikasi validitas sertifikat.
    • Nama alternatif subjek (SAN) sertifikat turunan tidak melanggar kolom NameConstraints dalam sertifikat induk.

  3. Meneruskan permintaan ke backend.

    Jika validasi sertifikat klien berhasil, permintaan akan diteruskan ke backend menggunakan header mTLS kustom.

    Namun, jika validasi gagal, tindakan yang diambil bergantung pada nilai mode validasi klien:

    • ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Permintaan diteruskan dengan header mTLS kustom yang menunjukkan alasan kegagalan validasi. Untuk Load Balancer Aplikasi internal lintas region, Load Balancer Aplikasi eksternal regional, dan Load Balancer Aplikasi internal regional, selain header mTLS kustom, Anda dapat mengonfigurasi bidang opsional mTLS untuk memeriksa alasan kegagalan.

    • REJECT_INVALID dan ALLOW_VALIDATION_RELAXATIONS: Koneksi dihentikan dan error dicatat ke Cloud Logging.

Header mTLS kustom yang diteruskan ke backend

Tabel berikut menunjukkan variabel header mTLS kustom yang tersedia untuk diteruskan ke backend, baik saat sertifikat klien lulus validasi maupun saat gagal. Jika sertifikat klien gagal divalidasi, permintaan akan diteruskan ke backend hanya jika mode validasi klien ditetapkan ke ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

Variabel ini juga dapat ditetapkan di peta URL.

Status sertifikat klien Mode validasi klien Header khusus

Rantai sertifikat klien terlalu panjang (lebih dari 10 intermediate certificate disertakan dengan sertifikat klien).

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_chain_exceeded_limit

client_cert_sha256_fingerprint: <cert hash>

Sertifikat klien atau intermediate certificate memiliki ukuran kunci RSA yang tidak valid.

Tidak ada validasi yang dilakukan.

Kunci RSA dapat berkisar dari 2048 hingga 4096 bit.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_invalid_rsa_key_size

client_cert_sha256_fingerprint: <cert hash>

Sertifikat klien atau intermediate certificate menggunakan kurva elips yang tidak didukung.

Tidak ada validasi yang dilakukan.

Kurva elips yang valid adalah P-256 dan P-384.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_unsupported_elliptic_curve_key

client_cert_sha256_fingerprint: <cert hash>

Sertifikat klien atau intermediate certificate menggunakan algoritma non-RSA atau non-ECDSA.

Tidak ada validasi yang dilakukan.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_unsupported_key_algorithm

client_cert_sha256_fingerprint: <cert hash>

IKP yang akan digunakan untuk validasi memiliki lebih dari sepuluh intermediate certificate dengan Subjek dan Info Kunci Publik Subjek yang sama.

Tidak ada validasi yang dilakukan.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_pki_too_large

client_cert_sha256_fingerprint: <cert hash>

Intermediate certificate yang diberikan untuk validasi memiliki lebih dari 10 batasan nama.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_chain_max_name_constraints_exceeded

client_cert_sha256_fingerprint: <cert hash>

Sertifikat klien tidak memiliki ekstensi Extended Key Usage (EKU) yang menyertakan clientAuth.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_chain_invalid_eku

client_cert_sha256_fingerprint: <cert hash>
Batas waktu terlampaui saat mencoba memvalidasi rantai sertifikat. ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_timed_out

client_cert_sha256_fingerprint: <cert hash>

Batas kedalaman atau iterasi tercapai saat mencoba memvalidasi rantai sertifikat.

Kedalaman maksimum untuk rantai sertifikat adalah sepuluh, termasuk sertifikat root dan klien. Iterasi maksimum adalah 100 (sertifikat yang diperiksa untuk memvalidasi rantai sertifikat klien).

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_search_limit_exceeded

client_cert_sha256_fingerprint: <cert hash>

Anda mengonfigurasi mTLS tanpa menyiapkan resource TrustConfig.

Tidak ada validasi yang dapat dilakukan, tetapi hash sertifikat diteruskan ke backend.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_not_performed

client_cert_sha256_fingerprint: <cert hash>
Tidak ada sertifikat klien. ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: false

client_cert_chain_verified: false

client_cert_error: client_cert_not_provided

client_cert_sha256_fingerprint: <empty>
Sertifikat klien gagal divalidasi terhadap resource TrustConfig. ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_failed

client_cert_sha256_fingerprint: <cert hash>
Sertifikat klien lulus validasi pemverifikasi sertifikat. Tidak berlaku

client_cert_present: true

client_cert_chain_verified: true

client_cert_error: <empty>

client_cert_sha256_fingerprint: <cert hash>

client_cert_serial_number: <serial_number>

client_cert_valid_not_before: <date>

client_cert_valid_not_after: <date>

client_cert_uri_sans: <list>

client_cert_dnsname_sans: <list>

client_cert_issuer_dn: <issuer>

client_cert_subject_dn: <subject>

client_cert_leaf: <certificate>

client_cert_chain: <list>

Mengurai nilai variabel header kustom yang diteruskan ke backend

Beberapa nilai variabel header mTLS kustom adalah representasi string berenkode Base64 dari data sertifikat Distinguished Encoding Rules (DER) biner. Anda dapat mendekode string berenkode Base64 menggunakan alat atau library software pilihan Anda. Berikut ini adalah beberapa contohnya:

  • Sistem macOS dan Linux dapat menggunakan alat command line base64, yang merupakan utilitas inti yang disertakan dalam kedua sistem operasi. Untuk mendekode string berenkode Base64 menggunakan utilitas base64, teruskan string yang dienkode sebagai input standar ke perintah base64 dan gunakan flag -d untuk mendekode string sebagai berikut:

    echo BASE_64_ENCODED_STRING | base64 -d

  • Python menyertakan modul base64, yang dapat digunakan untuk mendekode string berenkode Base64 sebagai berikut:

    import base64
encoded_string=BASE_64_ENCODED_STRING
decoded_string=base64.b64decode(encoded_string).decode()
print(decoded_string) # Note that a newline character (\n) is added to the end of the string.

Penanganan error dan logging

Load Balancer Aplikasi menyediakan kemampuan logging mendetail yang memungkinkan Anda memantau validasi sertifikat klien, mengidentifikasi potensi masalah, dan memecahkan masalah koneksi. Bagian ini menguraikan berbagai jenis error yang dapat terjadi selama validasi mTLS dan cara pencatatannya ke dalam log.

Error yang dicatat dalam mode REJECT_INVALID dan ALLOW_VALIDATION_RELAXATIONS

Jika validasi sertifikat klien gagal, dan mode validasi klien ditetapkan ke REJECT_INVALID atau ALLOW_VALIDATION_RELAXATIONS, koneksi akan dihentikan dan error akan dicatat ke Cloud Logging. Error ini dijelaskan dalam tabel berikut.

Status sertifikat klien Error yang dicatat ke dalam log
Rantai sertifikat klien terlalu panjang (lebih dari 10 intermediate certificate disertakan dengan sertifikat klien). client_cert_chain_exceeded_limit

Sertifikat klien atau intermediate certificate memiliki ukuran kunci RSA yang tidak valid.

Tidak ada validasi yang dilakukan.

Kunci RSA dapat berkisar dari 2048 hingga 4096 bit.

 client_cert_invalid_rsa_key_size

Sertifikat klien atau intermediate certificate menggunakan kurva elips yang tidak didukung.

Tidak ada validasi yang dilakukan.

Kurva yang valid adalah P-256 dan P-384.

 client_cert_unsupported_elliptic_curve_key

Sertifikat klien atau intermediate certificate menggunakan algoritma non-RSA atau non-ECDSA.

Tidak ada validasi yang dilakukan.

 client_cert_unsupported_key_algorithm

IKP yang akan digunakan untuk validasi memiliki lebih dari sepuluh intermediate certificate dengan Subjek dan Info Kunci Publik Subjek yang sama.

Tidak ada validasi yang dilakukan.

 client_cert_pki_too_large

Intermediate certificate yang diberikan untuk validasi memiliki lebih dari 10 batasan nama.

client_cert_chain_max_name_constraints_exceeded

Sertifikat klien tidak memiliki ekstensi Extended Key Usage (EKU) yang menyertakan clientAuth.

client_cert_chain_invalid_eku
Batas waktu terlampaui saat mencoba memvalidasi rantai sertifikat. client_cert_validation_timed_out

Batas kedalaman atau iterasi tercapai saat mencoba memvalidasi rantai sertifikat.

Kedalaman maksimum untuk rantai sertifikat adalah sepuluh, termasuk sertifikat root dan sertifikat klien. Jumlah maksimum iterasi adalah 100 (sertifikat yang diperiksa untuk memvalidasi rantai sertifikat klien).

 client_cert_validation_search_limit_exceeded
Anda mengonfigurasi mTLS tanpa menyiapkan resource TrustConfig. client_cert_validation_not_performed
Klien tidak memberikan sertifikat yang diminta selama handshake. client_cert_not_provided
Sertifikat klien gagal divalidasi dengan resource TrustConfig. client_cert_validation_failed

Error yang di-log untuk koneksi tertutup

Saat mode validasi klien dikonfigurasi, error tertentu akan menyebabkan koneksi ditutup dan dicatat ke Cloud Logging. Error ini dijelaskan dalam tabel berikut.

Status sertifikat klien Permintaan Error yang dicatat ke dalam log
Sertifikat klien gagal mencocokkan tanda tangan selama handshake. Menghentikan handshake SSL Tidak ada
Layanan tidak dapat melakukan validasi rantai sertifikat. Menghentikan koneksi client_cert_validation_unavailable
Error internal saat memvalidasi rantai sertifikat. Menghentikan koneksi client_cert_validation_internal_error
TrustConfig yang cocok tidak ditemukan. Menghentikan koneksi client_cert_trust_config_not_found
Payload sertifikat klien (termasuk intermediate certificate) terlalu besar (lebih dari 16 KB). Menghentikan koneksi client_cert_exceeded_size_limit

Jika logging diaktifkan di layanan backend, Anda dapat menjalankan kueri untuk melihat log validasi sertifikat klien mTLS.

Batasan

  • Load balancer tidak melakukan pemeriksaan pencabutan pada sertifikat klien.

  • Load Balancer Aplikasi memungkinkan Anda mengupload konfigurasi kepercayaan dengan satu trust store, yang berisi maksimal: 200 jumlah gabungan trust anchor dan intermediate certificate (jumlah intermediate certificate dibatasi hingga 100) dan 500 sertifikat yang ditambahkan ke daftar yang diizinkan. Semua intermediate certificate tidak boleh memiliki lebih dari tiga sertifikat dengan Subjek dan info Kunci Publik Subjek yang sama. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.

  • Kedalaman maksimum untuk rantai sertifikat adalah sepuluh, termasuk sertifikat root dan klien. Jumlah maksimum intermediate certificate yang dapat dievaluasi saat mencoba membangun rantai kepercayaan adalah 100. Untuk informasi selengkapnya, lihat Kuota dan batas.

  • Kunci sertifikat yang diupload dan diteruskan dari klien dibatasi untuk hal berikut:

    • Kunci RSA dapat berkisar dari 2048 hingga 4096 bit. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
    • Kunci ECDSA dapat menggunakan kurva P-256 atau P-384.

  • Rantai sertifikat yang diterima dari klien dibatasi hingga 16 KB dan 10 sertifikat. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.

  • Root certificate yang digunakan untuk validasi tidak boleh berisi lebih dari 10 batasan nama. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.

  • Google Front End (GFE) Lapisan 1 menerapkan waktu tunggu yang tidak dapat dikonfigurasi selama 10 detik bagi klien untuk menampilkan sertifikatnya selama TLS handshake. Pada beban puncak, waktu tunggu ini mungkin lebih singkat. Klien harus menyelesaikan presentasi sertifikat dalam jangka waktu ini agar berhasil membuat koneksi mTLS.

Langkah berikutnya