Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan TLS bersama

TLS Timbal Balik, atau mTLS, adalah protokol standar industri untuk autentikasi timbal balik antara klien dan server. Hal ini memastikan bahwa klien dan server mengotentikasi satu sama lain dengan memverifikasi bahwa masing-masing memegang sertifikat valid yang dikeluarkan oleh certificate authority (CA) tepercaya. Tidak seperti TLS standar, yang hanya mengautentikasi server, mTLS mengharuskan klien dan server untuk memberikan sertifikat, yang mengonfirmasi identitas kedua pihak sebelum komunikasi dilakukan.

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 entitas yang berkomunikasi melalui jaringan. Infrastruktur mencakup tiga komponen: klien, server, dan Certificate Authority (CA). mTLS untuk load balancer mendukung fitur berikut:

Verifikasi bahwa klien yang menyajikan sertifikat memiliki kunci pribadinya.
Validasi sertifikat klien dalam salah satu dari dua mode:
- Tolak sertifikat yang tidak valid: Menerapkan autentikasi ketat dengan menolak permintaan jika rantai sertifikat klien tidak dapat divalidasi.
- Izinkan sertifikat yang tidak valid atau tidak ada: Memberikan fleksibilitas dengan meneruskan semua permintaan ke backend, meskipun sertifikat klien tidak ada atau tidak valid.
Memvalidasi sertifikat klien terhadap anchor PKI yang diupload (sertifikat root), dengan opsi untuk menambahkan beberapa anchor secara terpisah guna memungkinkan migrasi yang lancar dari PKI lama ke PKI baru tanpa waktu non-operasional.
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 memberikan rantai sertifikat lengkap.
Buat dan teruskan sidik jari sertifikat ke backend sebagai header permintaan kustom.
Teruskan kolom yang dipilih yang diekstrak dari sertifikat ke backend dengan menggunakan header kustom.
Teruskan hasil validasi dan error validasi apa pun ke backend dengan menggunakan header kustom.

Persyaratan sertifikat

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

Alat kriptografi modern membentuk dasar autentikasi mTLS. Sertifikat harus menggunakan algoritma RSA atau ECDSA untuk pertukaran kunci. Algoritma hashing harus menggunakan SHA-256 atau fungsi hash kriptografi yang lebih kuat. Algoritma hashing seperti MD4, MD5, dan SHA-1 tidak didukung.
Untuk sertifikat klien (leaf):
- Ekstensi Batasan Dasar 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 berakhir.
- Sertifikat klien tidak boleh berupa sertifikat yang ditandatangani sendiri.
Untuk root certificate dan intermediate certificate:
- Ekstensi Batasan Dasar harus berisi CA=true.
- Ekstensi Penggunaan Kunci harus ditetapkan ke keyCertSign.
- Ekstensi Penggunaan Kunci yang Diperpanjang harus berisi kolom clientAuth.
- Masa berlaku sertifikat tidak boleh berakhir.

Arsitektur deployment mTLS

Dengan mTLS, Anda dapat mengonfigurasi resource konfigurasi tepercaya, yang berisi penyimpanan tepercaya. Penyimpanan tepercaya merangkum trust anchor (sertifikat root) dan, secara opsional, satu atau beberapa sertifikat perantara. 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 penyimpanan tepercaya, yang pada gilirannya mencakup trust anchor (root certificate) dan, secara opsional, satu atau beberapa sertifikat perantara. Konfigurasi kepercayaan digunakan untuk membuat rantai kepercayaan antara sertifikat klien dan anchor kepercayaan. Untuk mengetahui informasi selengkapnya, lihat Konfigurasi kepercayaan.

Secara opsional, jika Anda perlu menggunakan sertifikat yang telah ditandatangani sendiri, telah expired, atau tidak valid, atau jika Anda tidak memiliki akses ke root dan sertifikat perantara, Anda dapat menambahkan sertifikat tersebut ke konfigurasi kepercayaan di kolom allowlistedCertificates. Anda tidak memerlukan penyimpanan tepercaya 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 telah ditetapkan, dan batasan pada kolom SAN sertifikat terpenuhi.
Trust store. Berisi sertifikat 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 (sertifikat root) atau sertifikat CA perantara.

Anda dapat mengupload jenis sertifikat root dan perantara berikut ke penyimpanan tepercaya:
- Sertifikat yang dikeluarkan oleh CA pihak ketiga pilihan Anda.
- Sertifikat yang diterbitkan oleh CA pribadi di bawah kendali Anda, seperti yang dijelaskan dalam Menyiapkan TLS bersama dengan CA pribadi.
- Sertifikat yang disediakan pengguna, seperti yang dijelaskan dalam Menyiapkan TLS bersama dengan sertifikat yang disediakan pengguna.
Autentikasi Klien (juga dikenal sebagai ServerTLSPolicy). Menentukan mode validasi klien dan resource konfigurasi tepercaya yang akan digunakan saat memvalidasi sertifikat klien. Saat klien memberikan sertifikat yang tidak valid atau tidak ada sertifikat ke load balancer, mode validasi klien menentukan cara penanganan koneksi klien. 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.

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.

Mode validasi klien

Saat klien memberikan sertifikat yang tidak valid atau tidak ada sertifikat ke load balancer, atribut clientValidationMode pada resource Otentikasi Klien (ServerTLSPolicy) menentukan cara load balancer menangani koneksi klien.

Nilai mode validasi klien adalah sebagai berikut:

ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Mengizinkan koneksi dari klien meskipun validasi sertifikat klien gagal atau tidak ada sertifikat klien yang diberikan. 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, handshake TLS akan dihentikan meskipun mode validasi klien mengizinkan sertifikat klien yang tidak valid atau tidak ada.
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 anchor kepercayaan.

Mengonfigurasi mTLS di load balancer

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

Buat resource konfigurasi kepercayaan yang terdiri dari trust anchor (sertifikat root) dan sertifikat perantara yang berfungsi sebagai root kepercayaan.
Tautkan konfigurasi kepercayaan ke resource Autentikasi Klien (ServerTLSPolicy), yang menentukan mode validasi klien dari ALLOW_INVALID_OR_MISSING_CLIENT_CERT atau REJECT_INVALID.
Lampirkan resource Autentikasi Klien (ServerTLSPolicy) ke resource proxy HTTPS target load balancer.
Opsional: Anda dapat menggunakan header mTLS kustom untuk meneruskan informasi tentang koneksi mTLS ke layanan backend atau peta URL.

Untuk mempelajari penyiapan ini secara mendetail, lihat panduan berikut:

Langkah-langkah validasi sertifikat klien

Saat memvalidasi sertifikat klien, load balancer melakukan hal berikut:

Verifikasi 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, handshake TLS akan dihentikan meskipun konfigurasi Anda mengizinkan sertifikat klien yang tidak valid atau tidak ada. Tidak ada error yang dicatat untuk Load Balancer Aplikasi eksternal global, tetapi error TLS dicatat di kolom proxyStatus untuk Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal.
Verifikasi rantai kepercayaan.

Load balancer memverifikasi rantai kepercayaan antara sertifikat klien dan konfigurasi kepercayaan yang dikonfigurasi. Pemeriksaan verifikasi 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) dalam sertifikat turunan. Kecocokan ini mengonfirmasi bahwa sertifikat turunan dikeluarkan oleh otoritas root yang benar dan dapat dipercaya karena kunci publik root direferensikan di AKID untuk memverifikasi validitas sertifikat.
- Nama alternatif subjek (SAN) sertifikat turunan tidak melanggar kolom NameConstraints dalam sertifikat induk.
Catatan: Sertifikat klien yang ditandatangani sendiri gagal membentuk rantai kepercayaan yang valid dan selalu ditolak.
Teruskan 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 kolom opsional mTLS untuk memeriksa alasan kegagalan.
- REJECT_INVALID: 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 validasi sertifikat klien gagal, permintaan 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 sertifikat perantara 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>`
Klien atau sertifikat perantara 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>`
Klien atau sertifikat perantara menggunakan kurva elips yang tidak didukung. Tidak ada validasi yang dilakukan. Elliptic curve 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>`
Klien atau sertifikat perantara menggunakan algoritma non-RSA, 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>`
PKI yang akan digunakan untuk validasi memiliki lebih dari sepuluh sertifikat perantara yang memiliki Subject dan Subject Public Key Info 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 verifier 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 base64 command line, yang merupakan utilitas inti yang disertakan dalam kedua sistem operasi. Untuk mendekode string yang dienkode 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 dan logging error

Application Load Balancer 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 mencatatnya.

Error yang dicatat dalam mode `REJECT_INVALID`

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

Status sertifikat klien	Error yang dicatat
Rantai sertifikat klien terlalu panjang (lebih dari 10 intermediate certificate disertakan dengan sertifikat klien).	`client_cert_chain_exceeded_limit`
Klien atau sertifikat perantara 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`
Klien atau sertifikat perantara 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`
Klien atau sertifikat perantara menggunakan algoritma non-RSA atau non-ECDSA. Tidak ada validasi yang dilakukan.	`client_cert_unsupported_key_algorithm`
PKI yang akan digunakan untuk validasi memiliki lebih dari sepuluh sertifikat perantara yang memiliki Subject dan Subject Public Key Info 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 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`
Validasi sertifikat klien gagal dengan resource `TrustConfig`.	`client_cert_validation_failed`

Error yang dicatat untuk koneksi yang ditutup

Jika mode validasi klien disetel ke ALLOW_INVALID_OR_MISSING_CLIENT_CERT atau REJECT_INVALID, error tertentu akan menyebabkan koneksi ditutup dan dicatat ke Cloud Logging. Error ini dijelaskan dalam tabel berikut.

Status sertifikat klien	Permintaan	Error yang dicatat
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 sertifikat perantara) terlalu besar (lebih dari 16 KB).	Menghentikan koneksi	`client_cert_exceeded_size_limit`

Jika logging diaktifkan di layanan backend, Anda dapat melihat error yang dicatat untuk koneksi yang ditutup selama validasi sertifikat klien mTLS.

Batasan

Load balancer tidak melakukan pemeriksaan pencabutan pada sertifikat klien.
Load Balancer Aplikasi memungkinkan Anda mengupload konfigurasi tepercaya dengan satu penyimpanan tepercaya, yang berisi paling banyak: 200 gabungan jumlah anchor tepercaya dan sertifikat perantara (jumlah sertifikat perantara dibatasi hingga 100) dan 500 sertifikat yang ditambahkan ke daftar yang diizinkan. Semua sertifikat perantara tidak boleh memiliki lebih dari tiga sertifikat yang berbagi info Subjek dan 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 evaluasi sertifikat perantara saat mencoba membangun rantai kepercayaan adalah 100. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
Kunci sertifikat yang diupload dan diteruskan dari klien dibatasi untuk berikut ini:
- 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 yang diterima dari klien dibatasi hingga 16 KB dan 10 sertifikat. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
Sertifikat root yang digunakan untuk validasi tidak boleh berisi lebih dari 10 batasan nama. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
Google Front End (GFE) Layer 1 menerapkan waktu tunggu yang tidak dapat dikonfigurasi selama 10 detik bagi klien untuk menyajikan sertifikatnya selama handshake TLS. Saat beban puncak, waktu tunggu ini mungkin lebih singkat. Klien harus menyelesaikan presentasi sertifikat dalam jangka waktu ini agar berhasil membuat koneksi mTLS.