Bagaimana Cara Kerja Validasi Sertifikat TLS, dan Bagaimana Cara Mendebug Kegagalannya?

Pertanyaan dan Konteks yang Berlaku

Setelah api.example.com merotasi sertifikat TLS-nya, browser dan permintaan curl https://api.example.com biasa berhasil. Worker Java 21 yang menggunakan truststore kustom gagal dengan SunCertPathBuilderException: unable to find valid certification path. Sementara itu, curl https://203.0.113.10 mencapai load balancer yang sama tetapi gagal dalam verifikasi identitas.

Jelaskan bagaimana klien TLS membangun dan memvalidasi jalur sertifikat, bagaimana klien mencocokkan identitas layanan yang dituju, mengapa klien-klien ini dapat memperoleh hasil yang berbeda, dan bagaimana Anda akan mendiagnosis serta memperbaiki insiden ini tanpa menonaktifkan sertifikat atau verifikasi hostname.

Gunakan asumsi eksplisit berikut: api.example.com dan 203.0.113.10 bersifat fiktif; endpoint menggunakan sertifikat server standar yang tepercaya secara publik; truststore kustom milik Java worker independen dari konfigurasi trust browser; dan load balancer dapat menghosting beberapa nama TLS pada satu alamat IP. Tugas ini berfokus pada autentikasi sertifikat dan diagnosis operasional. Negosiasi cipher-suite, TLS 1.3 key schedule, dan 0-RTT berada di luar cakupan utama.

Pertanyaan ini cocok untuk wawancara general software engineering, networking, SRE, platform, security, backend, dan client. Jawaban yang baik harus menghubungkan aturan PKI dengan perilaku klien yang dapat diamati alih-alih sekadar melafalkan “leaf, intermediate, root.”

Hal yang Dievaluasi oleh Pewawancara

Pertama, dapatkah kandidat memisahkan empat keputusan yang sering kali disatukan menjadi satu?

1. Konstruksi jalur (Path construction): menemukan satu urutan kandidat dari leaf melalui nol atau

lebih intermediate menuju trust anchor yang dikonfigurasi secara lokal.

1. Validasi jalur (Path validation): memverifikasi bahwa jalur kandidat memenuhi tanda tangan, waktu,

batasan CA, penggunaan kunci (key usage), batasan nama, ekstensi kritis, persyaratan algoritma dan kebijakan, serta tujuan TLS server yang diinginkan.

1. Pencocokan identitas layanan (Service-identity matching): mencocokkan hostname referensi atau alamat IP

yang dikonfigurasi terhadap pengenal subjectAltName yang sesuai.

1. Pembuktian handshake (Handshake proof): memverifikasi CertificateVerify sehingga peer membuktikan kepemilikan

kunci privat sertifikat leaf dan mengikatnya ke handshake ini.

Kedua, dapatkah kandidat menjelaskan ketidaksesuaian antar klien tanpa mengarang penyebab universal? Browser, perkakas sistem operasi, kontainer, JVM, aplikasi seluler, dan proksi perusahaan dapat menggunakan trust anchor, intermediate yang di-cache atau dapat ditemukan (discoverable), jam, algoritma, kebijakan pencabutan (revocation), dan identitas referensi yang berbeda.

Ketiga, dapatkah kandidat menjalankan investigasi yang terkontrol? Jawaban yang kuat menangkap rantai sertifikat persis yang dikirimkan dengan SNI yang benar, mereproduksi validasi dengan materi trust milik klien yang gagal, mempertahankan hostname sambil melakukan pinning IP, membandingkan jalur yang berhasil dan gagal, serta memeriksa setiap instans load-balancer.

Terakhir, dapatkah kandidat memperbaiki trust dengan aman? Mengimpor sembarang leaf, menerima semua sertifikat, melewati pemeriksaan hostname, atau menggunakan curl -k hanya menyembunyikan kontrol keamanan yang gagal. Perbaikan harus memulihkan rantai atau kebijakan trust yang diinginkan dan mencakup rencana rollback serta kedaluwarsa untuk setiap perubahan trust sementara.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• URL dan identitas referensi persis apa yang digunakan setiap klien? Menghubungkan ke IP

literal meminta identitas IP. Menghubungkan ke IP yang sama sambil mempertahankan URL https://api.example.com meminta identitas DNS api.example.com.

• Trust store mana yang aktif saat runtime? Konfirmasikan opsi JVM, image

kontainer, pengguna, lingkungan proses, dan truststore terpasang yang sebenarnya daripada memeriksa store default pada laptop developer.

• Rantai apa yang diterima oleh permintaan yang gagal? SNI, listener load-balancer, region,

proksi, IPv4 versus IPv6, dan perbedaan deployment (deployment skew) dapat mengubah sertifikat yang disajikan.

• Apakah setiap klien gagal pada waktu yang sama? Periksa waktu lokal, masa berlaku sertifikat,

versi CA-bundle, kebijakan algoritma, dan apakah hanya satu instans backend atau edge yang menyajikan rantai baru.

• Apakah TLS diintersepsi? Proksi perusahaan dapat menggantikan leaf publik dengan

sertifikat yang diterbitkan oleh enterprise root yang dipercayai oleh browser tetapi tidak dipercayai oleh truststore kustom JVM.

• Apa yang diidentifikasi oleh pesan kesalahan? Kesalahan pembuatan jalur, sertifikat kedaluwarsa,

ketidakcocokan hostname, algoritma yang tidak didukung, kegagalan pencabutan, dan kegagalan negosiasi TLS adalah cabang yang berbeda. Pertahankan exception dan jejak validasi yang lengkap.

Kerangka Jawaban 30 Detik

“Saya membagi pemeriksaan menjadi konstruksi jalur, validasi jalur, pencocokan identitas layanan, dan pembuktian kunci privat. Server biasanya mengirimkan leaf dan intermediate yang diperlukan; klien membangun jalur ke trust anchor yang sudah dipercayai secara lokal. Kemudian klien memvalidasi tanda tangan, waktu, batasan CA dan kunci, ekstensi kritis, algoritma, dan tujuan server. Secara terpisah, klien mencocokkan nama DNS atau alamat IP yang dikonfigurasi ke entri SAN dengan tipe yang sama. SNI membantu server memilih sertifikat, tetapi tidak membangun trust atau membuktikan hostname.

Keberhasilan browser tidak membuktikan bahwa jalur Java valid karena truststore kustom JVM, penemuan intermediate, root proksi, jam, dan kebijakan bisa berbeda. Saya akan menangkap rantai sertifikat dengan SNI yang benar, memutarnya kembali terhadap truststore persis dari worker, membandingkan jalur yang dibangun, dan menggunakan curl --resolve untuk menjaga identitas DNS tetap konstan saat menargetkan IP. Saya akan memperbaiki intermediate yang disajikan atau trust anchor yang dikelola secara sengaja, tidak pernah menonaktifkan verifikasi, dan menguji ulang setiap edge serta worker yang sebenarnya.”

Pembahasan Mendalam Langkah demi Langkah

1. Tetapkan tiga input independen. Pemverifikasi membutuhkan sertifikat leaf target, sekumpulan sertifikat intermediate tidak tepercaya yang dapat membantu membangun jalur, dan satu atau lebih trust anchor lokal. "Tidak tepercaya" di sini bukan berarti berbahaya; ini berarti bahwa intermediate adalah materi pembuat jalur dan tidak otomatis menjadi trust anchor hanya karena server mengirimkannya.

Server HTTPS biasanya mengirimkan sertifikat leaf yang diikuti oleh intermediate yang dibutuhkan klien. Server umumnya tidak perlu mengirimkan root. Keputusan trust pemverifikasi berakhir pada root atau anchor lain yang dikonfigurasi oleh kebijakan lokal. Mengirimkan root tidak dapat membuat root yang tidak dikenal menjadi tepercaya.

2. Bangun jalur kandidat sebelum memvalidasi salah satunya. Leaf mencantumkan nama penerbit (issuer); intermediate dapat mencantumkan penerbit lain; CA yang di-cross-sign dapat membuat lebih dari satu rute yang memungkinkan. Klien dapat mengambil intermediate dari handshake, cache, atau mekanisme penemuan spesifik implementasi. RFC 5280 mendefinisikan validasi jalur tetapi sengaja membiarkan prosedur untuk memperoleh urutan kandidat di luar cakupannya. Oleh karena itu, dua klien yang sesuai standar dapat memiliki input konstruksi yang berbeda dan memilih jalur yang berbeda.

SunCertPathBuilderException berarti pembangun jalur Java tidak menemukan jalur yang dapat diterimanya dengan sertifikat dan kebijakan yang tersedia. Penyebab yang masuk akal mencakup intermediate yang hilang, tidak adanya trust anchor di store kustom, jalur alternatif yang tidak dapat digunakan, atau batasan kebijakan. Exception itu sendiri tidak membuktikan penyebab mana yang terjadi.

3. Validasi jalur yang dipilih. Untuk setiap tautan yang relevan, klien memverifikasi tanda tangan sertifikat dengan kunci publik penerbit dan memproses batasan-batasan. Pemeriksaan penting mencakup:

• waktu saat ini berada dalam interval validitas sertifikat;
• setiap sertifikat penerbit diizinkan bertindak sebagai CA di bawah basicConstraints, dan

batas panjang jalur (path-length limit) apa pun dipatuhi;

• CA key usage mengizinkan penandatanganan sertifikat, sementara leaf cocok untuk tujuan

TLS server yang dimaksudkan di bawah kebijakan key-usage dan extended-key-usage yang berlaku;

• batasan nama, kebijakan sertifikat, dan ekstensi kritis yang dikenali

diproses dengan benar;

• algoritma dan kekuatan kunci memenuhi kebijakan keamanan klien saat ini; dan
• jalur berakhir pada trust anchor yang dipilih oleh kebijakan lokal.

Pencabutan (revocation) adalah dimensi kebijakan lainnya. Klien berbeda dalam cara mereka memperoleh dan menangani CRL, respons OCSP, status yang di-staple, kesalahan jaringan, dan kondisi soft-fail versus hard-fail. Jangan berasumsi bahwa "validasi jalur RFC 5280 berhasil" membuktikan bahwa setiap klien melakukan pemeriksaan pencabutan daring yang sama.

4. Cocokkan identitas layanan secara terpisah. Identitas referensi berasal dari input tepercaya seperti URL HTTPS yang dikonfigurasi, bukan dari reverse DNS, sertifikat itu sendiri, atau nama apa pun yang diberikan penyerang. Di bawah RFC 9525, identitas layanan modern direpresentasikan dalam subjectAltName; klien tidak boleh beralih ke Subject Common Name untuk tujuan ini.

Nama DNS dan alamat IP menggunakan tipe SAN yang berbeda. https://api.example.com memerlukan DNS-ID yang cocok. https://203.0.113.10 memerlukan alamat IP yang tepat dalam iPAddress SAN; DNS SAN yang berisi api.example.com tidak memenuhinya. Jika didukung, wildcard harus berupa keseluruhan label paling kiri dan hanya cocok dengan tepat satu label: *.example.com dapat cocok dengan api.example.com, tetapi tidak dengan v2.api.example.com atau example.com.

SNI dan verifikasi memiliki fungsi yang berbeda. SNI memberi tahu server multi-tenant sertifikat mana yang harus disajikan. Identitas referensi memberi tahu klien nama mana yang harus dicakup oleh sertifikat tersebut. Permintaan dapat mengirimkan SNI yang benar dan tetap gagal dalam pemeriksaan hostname, atau menghilangkan SNI, menerima sertifikat default, dan kemudian gagal karena alasan yang berbeda.

5. Verifikasi kepemilikan kunci privat leaf. Jalur yang valid dan SAN yang cocok mengikat identitas ke kunci publik. Selama handshake TLS 1.3 yang diautentikasi sertifikat, CertificateVerify menandatangani transkrip handshake dengan kunci privat yang sesuai. Memverifikasinya membuktikan bahwa peer mengendalikan kunci privat tersebut dalam negosiasi ini. Hal ini berbeda dari membangun jalur dan mencocokkan hostname.

6. Jelaskan mengapa ketiga pengamatan tersebut kompatibel. Pengamatan-pengamatan tersebut tidak saling bertentangan:

7. Reproduksi endpoint dan jalur secara independen. Mulailah dengan nama DNS dan SNI yang tepat. Flag berikut menargetkan OpenSSL 3.6; periksa openssl version terlebih dahulu karena LibreSSL bawaan macOS dan paket yang lebih lama menyediakan opsi yang berbeda. -showcerts menampilkan apa yang dikirim server; -verify_return_error berhenti jika ada kesalahan verifikasi; -verify_hostname memeriksa identitas DNS yang dituju.

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -showcerts \
  -verify_return_error \
  -verify_hostname api.example.com \
  </dev/null

Simpan sertifikat leaf dan intermediate sebagai file PEM terpisah, dapatkan root tepercaya yang tepat dari lingkungan yang gagal melalui ekspor yang disetujui, dan putar ulang validasi jalur secara eksplisit:

openssl verify \
  -CAfile worker-roots.pem \
  -untrusted served-intermediates.pem \
  -purpose sslserver \
  -verify_hostname api.example.com \
  leaf.pem

Eksperimen ini membedakan trust anchor dari intermediate. Ini tidak sepenuhnya mengemulasikan setiap algoritma JVM, pencabutan, atau aturan penyedia (provider rules), sehingga reproduksi yang menentukan tetap berjalan di dalam image Java yang sama dengan output debug trust-manager dan truststore yang sama. Samarkan (redact) nama internal dan materi sertifikat sebelum membagikan log.

Untuk menargetkan alamat load-balancer tertentu tanpa mengubah nama referensi HTTPS, pertahankan URL dan timpa resolusi:

curl --resolve api.example.com:443:203.0.113.10 \
  https://api.example.com/health

Ulangi untuk setiap alamat IPv4 dan IPv6, region, dan instans edge yang diiklankan. Meminta https://203.0.113.10 secara langsung adalah uji identitas yang berbeda dan tidak boleh digunakan sebagai bukti bahwa sertifikat untuk api.example.com salah.

8. Perbaiki lapisan yang gagal dan buktikan jalur rollback. Jika server menghilangkan intermediate yang diperlukan, terapkan bundel leaf-plus-intermediate yang benar pada setiap terminator TLS dan konfirmasikan rantai yang disajikan. Jika organisasi sengaja menggunakan CA privat atau proksi, distribusikan root yang disetujui melalui proses truststore yang terkelola dengan kepemilikan, cakupan, fingerprint, kedaluwarsa, dan rollback yang dicatat. Jika SAN yang salah diterbitkan, ganti sertifikat tersebut. Jika jam, instans yang tertinggal (stale), atau kebijakan algoritma berbeda, perbaiki kondisi-kondisi tersebut secara langsung.

Jangan mengimpor leaf endpoint sebagai root permanen, menyalin sertifikat yang tidak dapat dijelaskan dari cache browser, mematikan identifikasi endpoint, memasang trust manager yang permisif, atau merilis curl -k ke produksi. Setelah perbaikan, verifikasi worker asli, browser, curl, setiap alamat edge, penghapusan sertifikat sebelumnya, pemantauan sebelum kedaluwarsa, dan perilaku kegagalan untuk hostname yang sengaja disalahkan serta rantai uji yang tidak tepercaya.

Contoh Jawaban Berkualitas Tinggi

“Saya tidak akan menyimpulkan bahwa Java salah hanya karena browser berfungsi. Setiap pemverifikasi membuat keputusan berdasarkan sertifikat target, kumpulan intermediate, trust anchor, identitas referensi, waktu, dan kebijakannya sendiri.

Saya memisahkan empat pemeriksaan. Pertama, konstruksi jalur menemukan urutan dari leaf melalui intermediate ke anchor yang dipercayai secara lokal. Sertifikat yang dikirim oleh server hanyalah input konstruksi; sertifikat tersebut tidak menciptakan trust. Kedua, validasi jalur memverifikasi tanda tangan, validitas, batasan CA dan kunci, ekstensi kritis, algoritma, kebijakan, dan tujuan server-auth. Ketiga, identifikasi endpoint membandingkan nama yang dikonfigurasi dengan SAN. URL DNS membutuhkan DNS-ID, sedangkan URL IP-literal membutuhkan IP-ID. SNI hanya memilih sertifikat virtual host. Keempat, TLS memverifikasi CertificateVerify untuk membuktikan bahwa peer memegang kunci privat leaf untuk handshake ini.

Browser mungkin memiliki root store yang berbeda, intermediate yang di-cache atau ditemukan, atau root proksi perusahaan. Truststore kustom milik worker Java 21 mungkin kekurangan anchor yang diperlukan atau input konstruksi, dan exception-nya hanya menyatakan bahwa tidak ada jalur yang dapat diterima yang berhasil dibangun. Kegagalan curl berbasis IP sudah diperkirakan jika sertifikat mencakup nama DNS tetapi tidak memiliki IP SAN.

Saya pertama-tama akan menangkap rantai persis dengan openssl s_client, SNI yang benar, -verify_return_error, dan -verify_hostname. Saya akan menginventarisasi SAN, penerbit, masa berlaku, basic constraints, key usage, EKU, algoritma, dan fingerprint. Saya kemudian akan memvalidasi leaf yang disimpan dan intermediate yang disajikan terhadap ekspor root worker yang disetujui, dan mereproduksi di dalam kontainer Java dengan flag runtime yang sebenarnya. curl --resolve memungkinkan saya menguji setiap IP load-balancer sambil mempertahankan api.example.com sebagai identitas URL sekaligus SNI.

Jika intermediate hilang, saya memperbaiki bundel rantai pada semua terminator TLS. Jika root privat atau proksi yang disetujui tidak ada, saya mendistribusikan root tersebut melalui alur kerja truststore terkelola daripada mempercayai leaf. Jika SAN, jam, atau kebijakan salah, saya memperbaiki lapisan yang tepat tersebut. Saya tidak pernah menggunakan trust-all, menonaktifkan verifikasi hostname, atau menerima -k sebagai perbaikan. Saya menutup insiden hanya ketika worker asli berhasil di setiap edge dan pengujian negatif tetap menolak hostname yang salah serta rantai yang tidak tepercaya.”

Kesalahan Umum

• Menganggap pembuatan dan validasi rantai sebagai satu operasi → klien dapat menemukan

jalur kandidat yang berbeda sebelum validasi → **sebutkan target, kumpulan intermediate, trust anchor, dan kebijakan secara terpisah.**

• Mempercayai root hanya karena server mengirimkannya → trust anchor berasal dari kebijakan lokal

→ perlakukan sertifikat yang disediakan server sebagai input konstruksi yang tidak tepercaya.

• Memeriksa tanda tangan tetapi mengabaikan batasan CA → tanda tangan yang valid saja tidak

memberi wewenang kepada penerbit untuk menandatangani sertifikat → **periksa basic constraints, panjang jalur, key usage, ekstensi kritis, dan tujuan.**

• Menggunakan nama sertifikat sebagai identitas yang diharapkan → hal itu membiarkan data yang disajikan

memilih apa yang harus dibuktikannya → turunkan identitas referensi dari URL yang dikonfigurasi.

• Mengasumsikan SNI melakukan verifikasi hostname → SNI memilih virtual host →

lakukan pencocokan SAN sebagai pemeriksaan klien yang terpisah.

• Mengharapkan DNS SAN untuk memvalidasi URL IP → DNS-ID dan IP-ID adalah tipe yang berbeda

→ gunakan --resolve ketika tujuannya adalah melakukan pin routing sambil mempertahankan identitas DNS.

• Menyalahkan intermediate yang hilang hanya dari satu exception → truststore, kebijakan, waktu,

proksi, dan deployment skew dapat menghasilkan gejala yang serupa → **tangkap rantai yang sebenarnya dan reproduksi dengan input runtime yang tepat.**

• Memperbaiki dengan -k atau trust-all → ini mengubah saluran yang terautentikasi menjadi

saluran yang tidak terautentikasi → perbaiki rantai, identitas, managed root, jam, atau kebijakan.

Pertanyaan Lanjutan dan Tanggapan

Lanjutan 1: Haruskah server mengirimkan sertifikat root?

Biasanya tidak. Server harus mengirimkan leaf dan intermediate yang diperlukan untuk mencapai root yang sudah dipercayai klien. Root yang dikirim oleh server bersifat redundan bagi klien yang mempercayainya dan tidak berguna bagi klien yang tidak mempercayainya. Hal ini juga membuang-buang byte handshake.

Lanjutan 2: Mengapa browser dapat pulih dari intermediate yang hilang sementara klien lain gagal?

Implementasi dapat memiliki cache intermediate atau perilaku penemuan yang berbeda. Satu browser mungkin sudah memiliki intermediate tersebut atau memperolehnya melalui mekanisme khusus implementasi, sementara worker yang terisolasi hanya memiliki handshake dan store kustomnya. Inilah mengapa server harus mengirimkan intermediate yang diperlukan alih-alih mengandalkan pemulihan klien. Konfirmasikan jalur yang sebenarnya daripada berasumsi bahwa setiap browser berperilaku sama.

Lanjutan 3: Apakah hostname yang cocok membuat sertifikat self-signed aman?

Tidak. Pencocokan identitas dan trust jalur bersifat independen. Sertifikat dapat berisi DNS SAN yang tepat namun tidak memiliki jalur ke anchor yang dipercayai secara lokal. Deployment privat dapat mempercayai root self-signed melalui provisioning yang terkontrol, tetapi sekadar mencocokkan nama tidak membangun trust tersebut.

Lanjutan 4: Bagaimana pencabutan (revocation) harus dibahas dalam jawaban wawancara?

Nyatakan batasan kebijakannya. CRL, OCSP, stapling, status yang di-cache, akses jaringan, dan aturan soft-fail atau hard-fail berbeda di setiap klien. Tentukan apa yang diperiksa oleh pemverifikasi sebenarnya dan bagaimana perilakunya saat status tidak tersedia. Jangan mengklaim bahwa semua klien melakukan pemeriksaan daring yang identik, dan jangan secara diam-diam melemahkan kebijakan hard-fail yang diperlukan hanya untuk menghilangkan gangguan (outage).

Lanjutan 5: Bukti apa yang menutup insiden ini?

Catat fingerprint leaf dan intermediate yang disajikan per edge, jalur yang dibangun di bawah root persis worker, pembuktian nama DNS dan kunci privat yang berhasil, serta permintaan worker asli yang berhasil. Tambahkan tes negatif untuk nama DNS yang salah, IP literal tanpa IP-ID, dan rantai yang tidak tepercaya. Konfirmasikan bahwa tidak ada bypass yang tersisa, semua instans load-balancer menyajikan bundel yang dimaksudkan, pemantauan mencakup kedaluwarsa dan rotasi, serta setiap root sementara atau artefak diagnostik memiliki pemilik dan tanggal penghapusan.