Sebuah service dapat mewajibkan mutual TLS pada public edge tetapi tetap tidak memiliki TLS client certificate di application server. Client membuktikan kepemilikan private key kepada reverse proxy yang melakukan terminasi TLS; proxy kemudian membuka koneksi terpisah ke origin. Kecuali informasi sertifikat dibawa melewati hop kedua tersebut, origin tidak dapat secara langsung memeriksa credential yang diautentikasi pada koneksi pertama.
Meneruskan sertifikat melalui HTTP field menyelesaikan masalah transport, tetapi mengubah security boundary. Origin tidak lagi mengonsumsi identity evidence langsung dari TLS handshake miliknya sendiri. Origin mengonsumsi pernyataan yang dibuat intermediary tentang handshake yang berbeda.
RFC 9440 membakukan pola ini melalui Client-Cert dan Client-Cert-Chain. Mekanisme ini berguna justru karena terminasi TLS umum digunakan, tetapi security property-nya bergantung pada pembedaan yang ketat antara request field yang dikendalikan client dan metadata sertifikat yang dibuat proxy.
Autentikasi TLS berakhir di terminating proxy
Pada mutual TLS langsung, server meminta client certificate selama TLS handshake. Client menyajikan sertifikat dan membuktikan kepemilikan private key yang sesuai melalui certificate-authentication message milik protocol. Certificate validation policy kemudian menentukan apakah key dan sertifikat yang sudah diautentikasi tersebut dapat diterima.
Reverse proxy mengubah topologinya:
client === mutual TLS ===> edge proxy === backend connection ===> originTLS session pertama berakhir di proxy. Backend connection adalah transport session berbeda dengan cryptographic state tersendiri. Bahkan ketika HTTPS atau mutual TLS melindungi backend hop, session tersebut mengautentikasi pihak yang berpartisipasi dalam backend connection; ia tidak membuat ulang TLS handshake milik client asli.
Origin yang membutuhkan external client certificate untuk authorization, audit record, atau token binding karena itu memerlukan representasi eksplisit dari sertifikat tersebut. RFC 9440 mendefinisikan Client-Cert untuk end-entity certificate dan optional field Client-Cert-Chain untuk validation chain yang diteruskan oleh terminating proxy.
Representasi tersebut adalah application-layer metadata. Integritasnya berasal dari deployment architecture di sekitar header, bukan dari TLS transcript milik external client.
Forwarded certificate adalah assertion dari proxy
Perbedaan ini penting karena X.509 certificate saja bukan bukti bahwa pengirim HTTP request memiliki private key-nya.
Jika origin menerima DER-encoded certificate di Client-Cert, origin dapat mem-parse sertifikat, memeriksa name atau extension, menghitung thumbprint, dan menerapkan application policy. Tidak satu pun operasi tersebut secara mandiri membuktikan bahwa HTTP peer saat ini menyelesaikan mutual TLS menggunakan sertifikat tersebut.
Bukti itu terjadi sebelumnya, antara external client dan terminating proxy. Security decision di origin karena itu memiliki dua bagian: proxy harus mengautentikasi client dengan benar, dan origin harus menerima certificate metadata hanya ketika metadata itu dapat diatribusikan kepada proxy yang berwenang.
Ini menjadikan proxy sebagai security principal, bukan sekadar kemudahan transport yang transparan. Terminating proxy yang dikompromikan atau salah konfigurasi dapat menyatakan informasi sertifikat yang mungkin diperlakukan origin sebagai authenticated identity. Backend authorization tidak dapat lebih kuat daripada integritas assertion channel tersebut.
Salinan yang dikendalikan client tidak boleh lolos dari edge
HTTP field adalah input client kecuali arsitektur membuatnya sebaliknya. External client dapat mengirim field bernama Client-Cert di request sebelum TLS proxy menambahkan metadata apa pun.
RFC 9440 mengharuskan terminating reverse proxy menghapus semua field Client-Cert dan Client-Cert-Chain yang masuk sebelum menambahkan nilainya sendiri. Ini mencegah value dari client tertukar dengan certificate state yang dibuat proxy.
Ketentuan ini juga mengungkap constraint implementasi yang lebih luas. Hanya mengonfigurasi proxy untuk menambahkan trusted field tidak cukup jika salinan yang tidak dipercaya masih dapat hidup berdampingan, digabungkan, dipilih pertama oleh framework, atau mencapai origin melalui route alternatif. Field tersebut harus memiliki satu authoritative producer pada trust boundary.
RFC 9440 mendefinisikan Client-Cert sebagai singleton field. Multiple occurrence atau list of values bukan representasi field yang valid. Penanganan ketat mengurangi ambiguity antara komponen HTTP yang mungkin menyelesaikan duplicate field dengan cara berbeda.
Prinsip yang sama berlaku pada certificate header lama yang spesifik deployment. Nama header private tidak membuat field menjadi terpercaya. Integritas membutuhkan edge sanitization ditambah backend path tempat hanya intermediary yang berwenang dapat menghasilkan assertion tersebut.
Backend reachability menentukan apakah header dapat dipercaya
Edge yang dikonfigurasi dengan benar tidak dapat melindungi origin yang juga dapat dijangkau client secara langsung.
Pertimbangkan origin yang menerima Client-Cert setiap kali field itu ada. Jika public network dapat terhubung ke origin tanpa melewati TLS terminator yang ditetapkan, attacker dapat melewati mutual-TLS edge dan mengirim identity field secara langsung. Application kemudian tidak memiliki dasar yang andal untuk membedakan proxy assertion dari input client.
Network placement karena itu merupakan bagian dari desain autentikasi. Origin membutuhkan mekanisme yang membatasi request yang diterima hanya dari intermediary yang berwenang. Bergantung pada environment, hal ini dapat melibatkan private routing, firewall policy, authenticated service-mesh identity, mutual TLS pada backend connection, atau channel-authentication control lain.
Encryption saja tidak cukup. Backend HTTPS listener yang menerima koneksi dari client arbitrary melindungi confidentiality traffic, tetapi tidak menetapkan bahwa request yang membawa certificate metadata berasal dari terminating proxy yang disetujui.
Properti yang relevan adalah authenticated provenance: origin harus dapat mengaitkan request dengan trusted proxy sebelum memperlakukan certificate field sebagai identitas external client.
Banyak proxy memperluas assertion chain
Deployment nyata sering memiliki lebih dari satu intermediary. Request dapat melewati ingress tier, regional proxy, service mesh, dan application gateway sebelum mencapai process yang melakukan authorization.
RFC 9440 secara sengaja mendeskripsikan sertifikat yang diberikan originating client kepada TLS-terminating reverse proxy. Hop tambahan tidak mengubah semantic target tersebut, tetapi menciptakan lebih banyak tempat tempat field dapat dihapus, diganti, diduplikasi, atau terekspos ke peer yang tidak dipercaya.
Chain yang robust memerlukan ownership model yang eksplisit. Komponen downstream dari TLS terminator dapat mempertahankan authenticated assertion melalui trusted link atau menerjemahkannya menjadi representasi identitas terautentikasi lain. Setiap hop yang dapat menghasilkan atau mengubah field ikut masuk ke trusted computing base untuk keputusan yang diturunkan darinya.
Ini berbeda secara material dari asumsi bahwa seluruh internal traffic dapat dipercaya. Internal network lazimnya berisi workload dengan privilege berbeda. Jika workload semacam itu dapat terhubung ke origin dan mengatur header yang sama, certificate assertion kehilangan security meaning walaupun edge asli bekerja dengan benar.
Certificate chain membawa data, bukan jaminan validasi yang didelegasikan
Client-Cert-Chain dapat membawa certificate chain yang digunakan saat memvalidasi end-entity certificate. Ini berguna ketika origin membutuhkan informasi chain untuk application logic, tetapi meneruskan chain tidak otomatis memindahkan setiap detail validation policy milik proxy.
Penerimaan sertifikat dapat bergantung pada trust anchor, name constraint, extended key usage, revocation policy, validation time, local policy, dan implementation behavior. Origin yang mem-parse ulang forwarded chain dengan policy berbeda dapat mencapai hasil berbeda dari edge.
Arsitektur karena itu perlu menetapkan komponen mana yang memiliki tanggung jawab certificate validation dan fakta mana yang boleh disimpulkan application. Jika proxy bersifat authoritative untuk client-certificate authentication, origin sebaiknya tidak memperlakukan keberadaan forwarded chain saja sebagai validation event independen.
Sebaliknya, jika application policy membutuhkan property yang tidak divalidasi proxy, meneruskan certificate material dapat memungkinkan origin memeriksa property tersebut, tetapi desainnya membutuhkan aturan yang jelas untuk malformed data, unsupported extension, certificate rotation, dan perbedaan antara edge policy dan application policy.
Mengangkut byte sertifikat dan menetapkan certificate trust adalah operasi yang berbeda.
Certificate-bound token membuat provenance lebih ketat
OAuth mutual-TLS certificate-bound access token menambahkan penggunaan lain untuk client-certificate state. RFC 8705 mengikat access token ke sertifikat yang digunakan client dan mengharuskan protected resource memverifikasi bahwa sertifikat yang terkait dengan token cocok dengan sertifikat yang dipakai untuk mutual TLS.
Ketika TLS berakhir sebelum protected-resource application, application dapat bergantung pada trusted proxy metadata untuk memperoleh external client certificate. Token check kemudian hanya seandal metadata path tersebut.
Token yang berisi certificate thumbprint mencegah ordinary bearer replay hanya ketika resource dapat secara andal menetapkan sertifikat yang diberikan caller. Jika attacker dapat memalsukan forwarded certificate assertion, proof-of-possession property pada application boundary runtuh menjadi kepercayaan terhadap metadata yang dikendalikan attacker.
Hal ini tidak membuat terminasi TLS tidak kompatibel dengan certificate-bound token. Artinya, terminating proxy dan authenticated connection-nya ke resource server menjadi bagian dari proof path. RFC 8705 dan RFC 9440 menangani layer berbeda dari susunan tersebut: yang satu mendefinisikan certificate binding untuk OAuth token, sedangkan yang lain mendefinisikan standardized representation untuk membawa client-certificate information dari TLS terminator ke origin.
Logging perlu mempertahankan provenance assertion
Client certificate sering digunakan untuk audit identity sekaligus authorization. Terminasi proxy dapat membuat log menyesatkan jika record menyimpan certificate subject atau thumbprint tanpa mencatat dari mana value tersebut berasal.
Origin log entry yang menyatakan request menggunakan certificate thumbprint X dapat berarti local TLS stack mengautentikasi X, atau trusted edge menyatakan X, atau application menerima header tanpa provenance yang andal. State tersebut memiliki evidentiary value yang sangat berbeda.
Operational telemetry sebaiknya membedakan external client certificate dari identity backend peer. Ketika backend mutual TLS digunakan, kedua identity dapat relevan: proxy certificate mengautentikasi immediate channel, sedangkan forwarded client certificate mendeskripsikan external handshake yang diakhiri sebelumnya.
Memisahkan identity tersebut juga membantu incident analysis. Kegagalan certificate authentication di edge, kegagalan proxy-to-origin authentication, dan penolakan certificate policy oleh application adalah event berbeda pada boundary berbeda.
Terminasi TLS mengubah cryptographic state menjadi delegated identity
Mutual TLS memberi endpoint yang berpartisipasi dalam handshake cryptographic evidence langsung atas kepemilikan client key. TLS-terminating proxy mencegah origin menerima evidence tersebut secara langsung karena origin tidak berpartisipasi dalam session yang sama.
Certificate forwarding menjembatani gap arsitektur dengan mengubah handshake state menjadi HTTP assertion. Konversi ini aman hanya ketika assertion memiliki controlled provenance: salinan eksternal dihapus, proxy authoritative atas field tersebut, backend mengautentikasi immediate peer, dan route alternatif tidak dapat melewati intermediary.
Boundary akhirnya menjadi eksplisit. Origin mempercayai proxy untuk melaporkan sertifikat yang telah diautentikasi proxy, dan setiap authorization atau token-binding decision berdasarkan laporan tersebut mewarisi keamanan proxy-to-origin assertion channel.