Bagaimanakah Pengesahan Sijil TLS Berfungsi, dan Bagaimana Anda Menyahpepijat Kegagalan?

Soalan dan Konteks yang Berkenaan

Selepas api.example.com memutar sijil TLS-nya, penyemak imbas dan permintaan curl https://api.example.com biasa berjaya. Pekerja Java 21 yang menggunakan truststore tersuai gagal dengan SunCertPathBuilderException: unable to find valid certification path. Sementara itu, curl https://203.0.113.10 sampai ke pengimbang beban yang sama tetapi gagal dalam pengesahan identiti.

Terangkan cara klien TLS membina dan mengesahkan laluan sijil, cara ia memadankan identiti perkhidmatan yang dimaksudkan, sebab klien ini boleh mencapai keputusan yang berbeza, dan cara anda mendiagnosis serta membaiki insiden tersebut tanpa melumpuhkan pengesahan sijil atau nama hos.

Gunakan andaian eksplisit ini: api.example.com dan 203.0.113.10 adalah rekaan; titik akhir menggunakan sijil pelayan dipercayai awam yang biasa; truststore tersuai pekerja Java adalah bebas daripada konfigurasi kepercayaan penyemak imbas; dan pengimbang beban boleh mengehoskan berbilang nama TLS pada satu alamat IP. Tugas ini ialah pengesahan sijil dan diagnosis operasi. Rundingan cipher-suite, jadual kunci TLS 1.3, dan 0-RTT adalah di luar skop utama.

Soalan ini sesuai untuk temu duga kejuruteraan perisian am, rangkaian, SRE, platform, keselamatan, backend, dan klien. Jawapan yang berguna mesti menghubungkan peraturan PKI kepada tingkah laku klien yang boleh diperhatikan dan bukannya sekadar membaca "daun, perantara, punca."

Perkara yang Dinilai oleh Penemuduga

Pertama, bolehkah calon memisahkan empat keputusan yang sering digabungkan menjadi satu?

1. Pembinaan laluan: cari satu jujukan calon daripada daun melalui sifar atau lebih perantara ke punca kepercayaan (trust anchor) yang dikonfigurasikan secara tempatan.
2. Pengesahan laluan: sahkan bahawa laluan calon memenuhi tandatangan, masa, kekangan CA, penggunaan kunci, kekangan nama, sambungan kritikal, keperluan algoritma dan dasar, serta tujuan pelayan TLS yang dimaksudkan.
3. Pemadanan identiti perkhidmatan: padankan nama hos rujukan atau alamat IP yang dikonfigurasikan dengan pengecam subjectAltName yang sepadan.
4. Bukti jabat tangan (handshake): sahkan CertificateVerify supaya rakan setara membuktikan pemilikan kunci persendirian bagi sijil daun dan mengikatnya pada jabat tangan ini.

Kedua, bolehkah calon menjelaskan ketidaksepakatan klien tanpa mereka-reka punca universal? Penyemak imbas, alat sistem pengendalian, kontena, JVM, aplikasi mudah alih, dan proksi korporat boleh menggunakan punca kepercayaan, perantara yang dicache atau boleh ditemui, jam, algoritma, dasar pembatalan, dan identiti rujukan yang berbeza.

Ketiga, bolehkah calon menjalankan penyiasatan terkawal? Jawapan yang kukuh menangkap rantaian sijil tepat yang dihantar dengan SNI yang betul, menghasilkan semula pengesahan dengan bahan kepercayaan klien yang gagal, mengekalkan nama hos sambil menetapkan (pinning) IP, membandingkan laluan yang berjaya dan gagal, serta memeriksa setiap tika pengimbang beban.

Akhir sekali, bolehkah calon membaiki kepercayaan dengan selamat? Mengimport daun sebarangan, menerima semua sijil, melangkau pemeriksaan nama hos, atau menggunakan curl -k hanya menyembunyikan kawalan keselamatan yang gagal. Pembaikan mesti memulihkan rantaian atau dasar kepercayaan yang dimaksudkan dan menyertakan pelan undur balik (rollback) dan tamat tempoh untuk sebarang perubahan kepercayaan sementara.

Soalan untuk Dijelaskan Sebelum Menjawab

• Apakah URL dan identiti rujukan tepat yang digunakan oleh setiap klien? Menyambung ke literal IP meminta identiti IP. Menyambung ke IP yang sama sambil mengekalkan URL https://api.example.com meminta identiti DNS api.example.com.
• Apakah stor kepercayaan yang aktif semasa masa jalanan? Sahkan pilihan JVM sebenar, imej kontena, pengguna, persekitaran proses, dan truststore yang dilekapkan dan bukannya memeriksa stor lalai komputer riba pembangun.
• Apakah rantaian yang diterima oleh permintaan yang gagal? SNI, pendengar pengimbang beban, rantau, proksi, IPv4 berbanding IPv6, dan herotan penggunaan (deployment skew) boleh mengubah sijil yang dipersembahkan.
• Adakah setiap klien gagal pada masa yang sama? Periksa masa tempatan, kesahan sijil, versi berkas CA, dasar algoritma, dan sama ada hanya satu tika bahagian belakang atau pinggir yang menyediakan rantaian baharu.
• Adakah TLS dipintas? Proksi korporat boleh menggantikan daun awam dengan sijil yang dikeluarkan oleh punca perusahaan yang dipercayai oleh penyemak imbas tetapi tidak dipercayai oleh truststore JVM tersuai.
• Apakah yang dikenal pasti oleh ralat tersebut? Ralat pembinaan laluan, sijil tamat tempoh, ketidakpadanan nama hos, algoritma tidak disokong, kegagalan pembatalan, dan kegagalan rundingan TLS adalah cabang yang berbeza. Simpan pengecualian penuh dan surihan pengesahan.

Rangka Kerja Jawapan 30 Saat

“Saya membahagikan pemeriksaan kepada pembinaan laluan, pengesahan laluan, pemadanan identiti perkhidmatan, dan bukti kunci persendirian. Pelayan biasanya menghantar sijil daunnya dan perantara yang diperlukan; klien membina laluan ke punca kepercayaan yang telah dipercayai secara tempatan. Ia kemudian mengesahkan tandatangan, masa, kekangan CA dan kunci, sambungan kritikal, algoritma, dan tujuan pelayan. Secara berasingan, ia memadankan nama DNS atau alamat IP yang dikonfigurasikan kepada jenis entri SAN yang sama. SNI membantu pelayan memilih sijil, tetapi ia tidak mewujudkan kepercayaan atau membuktikan nama hos.

Kejayaan penyemak imbas tidak membuktikan laluan Java adalah sah kerana truststore JVM tersuai, penemuan perantara, punca proksi, jam, dan dasar boleh berbeza. Saya akan menangkap rantaian dengan SNI yang betul, memainkannya semula terhadap truststore tepat milik pekerja, membandingkan laluan yang dibina, dan menggunakan curl --resolve untuk mengekalkan identiti DNS sambil menyasarkan IP. Saya akan membetulkan perantara yang disediakan atau punca kepercayaan yang diuruskan dengan sengaja, tidak sekali-kali melumpuhkan pengesahan, dan menguji semula setiap pinggir serta pekerja sebenar.”

Penerokaan Mendalam Langkah demi Langkah

1. Tetapkan tiga input bebas. Pengesah memerlukan sijil daun sasaran, satu set sijil perantara yang tidak dipercayai yang boleh membantu membina laluan, dan satu atau lebih punca kepercayaan tempatan. "Tidak dipercayai" di sini tidak bermakna berniat jahat; ini bermakna perantara ialah bahan pembinaan laluan dan tidak menjadi punca kepercayaan semata-mata kerana pelayan menghantarnya.

Pelayan HTTPS biasanya menghantar sijil daun diikuti oleh perantara yang diperlukan oleh klien. Ia secara amnya tidak perlu menghantar punca. Keputusan kepercayaan pengesah berakhir pada punca atau punca lain yang dikonfigurasikan oleh dasar tempatan. Menghantar punca tidak boleh menjadikan punca yang tidak diketahui dipercayai.

2. Bina laluan calon sebelum mengesahkan satu. Daun menamakan pengeluar; perantara boleh menamakan pengeluar lain; CA yang ditandatangani silang (cross-signed) boleh mencipta lebih daripada satu laluan yang mungkin. Klien boleh mendapatkan perantara daripada jabat tangan, cache, atau mekanisme penemuan khusus pelaksanaan. RFC 5280 mentakrifkan pengesahan laluan tetapi sengaja membiarkan prosedur untuk mendapatkan jujukan calon di luar skopnya. Oleh itu, dua klien yang mematuhi piawaian boleh mempunyai input pembinaan yang berbeza dan memilih laluan yang berbeza.

SunCertPathBuilderException bermaksud pembina laluan Java tidak menemui laluan yang boleh diterimanya dengan sijil dan dasar yang tersedia. Punca yang munasabah termasuk perantara yang hilang, ketiadaan punca kepercayaan dalam stor tersuai, laluan alternatif yang tidak boleh digunakan, atau kekangan dasar. Pengecualian itu sendiri tidak membuktikan punca yang mana satu berlaku.

3. Sahkan laluan yang dipilih. Untuk setiap pautan yang berkaitan, klien mengesahkan tandatangan sijil dengan kunci awam pengeluar dan memproses kekangan. Pemeriksaan penting termasuk:

• masa semasa berada dalam selang kesahan sijil;
• setiap sijil pengeluar dibenarkan bertindak sebagai CA di bawah basicConstraints, dan sebarang had panjang laluan dipatuhi;
• penggunaan kunci CA membenarkan penandatanganan sijil, manakala daun sesuai untuk tujuan pelayan TLS yang dimaksudkan di bawah dasar penggunaan kunci dan penggunaan kunci lanjutan yang berkenaan;
• kekangan nama, dasar sijil, dan sambungan kritikal yang diiktiraf diproses dengan betul;
• algoritma dan kekuatan kunci memenuhi dasar keselamatan semasa klien; dan
• laluan berakhir pada punca kepercayaan yang dipilih oleh dasar tempatan.

Pembatalan ialah satu lagi dimensi dasar. Klien berbeza dalam cara mereka memperoleh dan mengendalikan CRL, respons OCSP, status stapled, ralat rangkaian, dan syarat soft-fail berbanding hard-fail. Jangan anggap bahawa "pengesahan laluan RFC 5280 lulus" membuktikan setiap klien melakukan pemeriksaan pembatalan dalam talian yang sama.

4. Padankan identiti perkhidmatan secara berasingan. Identiti rujukan datang daripada input yang dipercayai seperti URL HTTPS yang dikonfigurasikan, bukan daripada DNS songsang, sijil itu sendiri, atau apa jua nama yang dibekalkan oleh penyerang. Di bawah RFC 9525, identiti perkhidmatan moden diwakili dalam subjectAltName; klien tidak boleh berbalik menggunakan Common Name subjek untuk tujuan ini.

Nama DNS dan alamat IP menggunakan jenis SAN yang berbeza. https://api.example.com memerlukan DNS-ID yang sepadan. https://203.0.113.10 memerlukan alamat IP yang tepat dalam SAN iPAddress; SAN DNS yang mengandungi api.example.com tidak memenuhinya. Jika disokong, kad bebas (wildcard) mestilah keseluruhan label paling kiri dan sepadan dengan tepat satu label: *.example.com boleh sepadan dengan api.example.com, tetapi bukan v2.api.example.com atau example.com.

SNI dan pengesahan mempunyai tugas yang berbeza. SNI memberitahu pelayan berbilang penyewa (multi-tenant) sijil mana yang perlu dipersembahkan. Identiti rujukan memberitahu klien nama mana yang mesti diliputi oleh sijil tersebut. Permintaan boleh menghantar SNI yang betul dan masih gagal dalam pemeriksaan nama hos, atau meniadakan SNI, menerima sijil lalai, dan kemudian gagal atas sebab yang berbeza.

5. Sahkan pemilikan kunci persendirian daun. Laluan yang sah dan SAN yang sepadan mengikat identiti pada kunci awam. Semasa jabat tangan TLS 1.3 yang disahkan sijil, CertificateVerify menandatangani transkrip jabat tangan dengan kunci persendirian yang sepadan. Mengesahkannya membuktikan bahawa rakan setara mengawal kunci persendirian tersebut dalam rundingan ini. Ini berbeza daripada membina laluan dan memadankan nama hos.

6. Jelaskan sebab ketiga-tiga pemerhatian adalah serasi. Pemerhatian tersebut tidak bercanggah antara satu sama lain:

7. Hasilkan semula titik akhir dan laluan secara bebas. Mulakan dengan nama DNS dan SNI yang tepat. Bendera berikut menyasarkan OpenSSL 3.6; semak openssl version dahulu kerana LibreSSL sistem macOS dan pakej yang lebih lama mendedahkan pilihan yang berbeza. -showcerts memaparkan perkara yang dihantar oleh pelayan; -verify_return_error berhenti pada ralat pengesahan; -verify_hostname menyemak identiti DNS yang dimaksudkan.

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

Simpan sijil daun dan perantara sebagai fail PEM yang berasingan, dapatkan punca tepat yang dipercayai daripada persekitaran yang gagal melalui eksport yang diluluskan, dan mainkan semula pengesahan laluan secara eksplisit:

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

Eksperimen ini membezakan punca kepercayaan daripada perantara. Ia tidak meniru dengan sempurna setiap algoritma, pembatalan, atau peraturan penyedia JVM, jadi penghasilan semula yang muktamad masih berjalan di dalam imej Java yang sama dengan output nyahpepijat pengurus kepercayaan dan truststore yang sama. Redaksikan nama dalaman dan bahan sijil sebelum berkongsi log.

Untuk menyasarkan alamat pengimbang beban tertentu tanpa mengubah nama rujukan HTTPS, kekalkan URL dan lalui resolusi (override resolution):

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

Ulangi untuk setiap alamat IPv4 dan IPv6, rantau, dan tika pinggir yang diiklankan. Meminta https://203.0.113.10 secara langsung ialah ujian identiti yang berbeza dan tidak boleh digunakan sebagai bukti bahawa sijil untuk api.example.com adalah salah.

8. Baiki lapisan yang gagal dan buktikan laluan undur balik. Jika pelayan meniadakan perantara yang diperlukan, gunakan berkas daun-tambah-perantara yang betul pada setiap penamat TLS dan sahkan rantaian yang disediakan. Jika organisasi sengaja menggunakan CA persendirian atau proksi, edarkan puncanya yang diluluskan melalui proses truststore terurus dengan pemilikan, skop, cap jari, tamat tempoh, dan undur balik direkodkan. Jika SAN yang salah dikeluarkan, gantikan sijil tersebut. Jika jam, tika lapuk, atau dasar algoritma berbeza, betulkan keadaan tersebut secara langsung.

Jangan import daun titik akhir sebagai punca kekal, salin sijil yang tidak dapat dijelaskan daripada cache penyemak imbas, matikan pengecaman titik akhir, pasang pengurus kepercayaan permisif, atau hantar curl -k. Selepas pembaikan, sahkan pekerja sebenar, penyemak imbas, curl, setiap alamat pinggir, penyingkiran sijil sebelumnya, pemantauan sebelum tamat tempoh, dan tingkah laku kegagalan untuk nama hos yang sengaja disalahkan serta rantaian ujian yang tidak dipercayai.

Contoh Jawapan Berkualiti Tinggi

“Saya tidak akan menyimpulkan bahawa Java salah semata-mata kerana penyemak imbas berfungsi. Setiap pengesah membuat keputusan daripada sijil sasaran, set perantara, punca kepercayaan, identiti rujukan, masa, dan dasarnya sendiri.

Saya memisahkan empat pemeriksaan. Pertama, pembinaan laluan mencari jujukan daripada daun melalui perantara ke punca yang dipercayai secara tempatan. Sijil yang dihantar oleh pelayan hanyalah input pembinaan; ia tidak mewujudkan kepercayaan. Kedua, pengesahan laluan mengesahkan tandatangan, kesahan, kekangan CA dan kunci, sambungan kritikal, algoritma, dasar, dan tujuan pengesahan pelayan (server-auth). Ketiga, pengecaman titik akhir membandingkan nama yang dikonfigurasikan dengan SAN. URL DNS memerlukan DNS-ID, manakala URL literal IP memerlukan IP-ID. SNI hanya memilih sijil hos maya. Keempat, TLS mengesahkan CertificateVerify untuk membuktikan rakan setara memegang kunci persendirian daun bagi jabat tangan ini.

Penyemak imbas mungkin mempunyai stor punca yang berbeza, perantara yang dicache atau ditemui, atau punca proksi perusahaan. Truststore tersuai pekerja Java 21 mungkin kekurangan punca atau input pembinaan yang diperlukan, dan pengecualiannya hanya menyatakan bahawa tiada laluan yang boleh diterima dibina. Kegagalan curl IP dijangkakan jika sijil meliputi nama DNS tetapi tidak mempunyai SAN IP.

Mula-mula saya akan menangkap rantaian yang tepat dengan openssl s_client, SNI yang betul, -verify_return_error, dan -verify_hostname. Saya akan menginventori SAN, pengeluar, kesahan, kekangan asas, penggunaan kunci, EKU, algoritma, dan cap jari. Saya kemudian akan mengesahkan daun yang disimpan dan perantara yang disediakan terhadap eksport punca pekerja yang diluluskan, dan menghasilkan semula di dalam kontena Java dengan bendera masa jalanan sebenarnya. curl --resolve membolehkan saya menguji setiap IP pengimbang beban sambil mengekalkan api.example.com sebagai kedua-dua identiti URL dan SNI.

Jika perantara hilang, saya membetulkan berkas rantaian pada semua penamat TLS. Jika punca persendirian atau proksi yang diluluskan tiada, saya mengedarkan punca tersebut melalui aliran kerja truststore terurus dan bukannya mempercayai daun. Jika SAN, jam, atau dasar salah, saya membaiki lapisan tepat tersebut. Saya tidak sekali-kali menggunakan trust-all, melumpuhkan pengesahan nama hos, atau menerima -k sebagai pembaikan. Saya menutup insiden hanya apabila pekerja sebenar berjaya merentasi setiap pinggir dan ujian negatif masih menolak nama hos yang salah serta rantaian yang tidak dipercayai.”

Kesilapan Biasa

• Menganggap pembinaan dan pengesahan rantaian sebagai satu operasi → klien boleh menemui laluan calon yang berbeza sebelum pengesahan → namakan sasaran, set perantara, punca kepercayaan, dan dasar secara berasingan.
• Mempercayai punca kerana pelayan menghantarnya → punca kepercayaan datang daripada dasar tempatan → anggap sijil yang disediakan oleh pelayan sebagai input pembinaan yang tidak dipercayai.
• Menyemak tandatangan tetapi meniadakan kekangan CA → tandatangan yang sah sahaja tidak memberi kebenaran kepada pengeluar untuk menandatangani sijil → semak kekangan asas, panjang laluan, penggunaan kunci, sambungan kritikal, dan tujuan.
• Menggunakan nama sijil sebagai identiti yang dijangkakan → ini membiarkan data yang dipersembahkan memilih perkara yang mesti dibuktikannya → peroleh identiti rujukan daripada URL yang dikonfigurasikan.
• Mengandaikan SNI melakukan pengesahan nama hos → SNI memilih hos maya → lakukan pemadanan SAN sebagai pemeriksaan klien yang berasingan.
• Mengharapkan SAN DNS mengesahkan URL IP → DNS-ID dan IP-ID adalah jenis yang berbeza → gunakan --resolve apabila matlamatnya adalah untuk menetapkan penghalaan sambil mengekalkan identiti DNS.
• Menyalahkan perantara yang hilang daripada satu pengecualian sahaja → truststore, dasar, masa, proksi, dan herotan penggunaan boleh menghasilkan simptom yang serupa → tangkap rantaian sebenar dan hasilkan semula dengan input masa jalanan yang tepat.
• Membaiki dengan -k atau trust-all → ini menukarkan saluran yang disahkan kepada saluran yang tidak disahkan → baiki rantaian, identiti, punca terurus, jam, atau dasar.

Soalan Susulan dan Respons

Susulan 1: Patutkah pelayan menghantar sijil punca?

Biasanya tidak. Pelayan harus menghantar daun dan perantara yang diperlukan untuk mencapai punca yang telah dipercayai oleh klien. Punca yang dihantar oleh pelayan adalah lewah bagi klien yang mempercayainya dan tidak berguna bagi klien yang tidak mempercayainya. Ia juga membazirkan bait jabat tangan.

Susulan 2: Mengapakah penyemak imbas boleh pulih daripada perantara yang hilang manakala klien lain gagal?

Pelaksanaan boleh mempunyai cache perantara atau tingkah laku penemuan yang berbeza. Satu penyemak imbas mungkin sudah memiliki perantara tersebut atau memperolehnya melalui mekanisme khusus pelaksanaan, manakala pekerja yang terpencil hanya mempunyai jabat tangan dan stor tersuainya. Inilah sebabnya pelayan harus menghantar perantara yang diperlukan dan bukannya bergantung pada pemulihan klien. Sahkan laluan sebenar dan bukannya menganggap setiap penyemak imbas bertindak dengan cara yang sama.

Susulan 3: Adakah nama hos yang sepadan menjadikan sijil ditandatangani sendiri (self-signed) selamat?

Tidak. Pemadanan identiti dan kepercayaan laluan adalah bebas. Sijil boleh mengandungi SAN DNS yang betul tetapi tidak mempunyai laluan ke punca yang dipercayai secara tempatan. Penggunaan persendirian boleh mempercayai punca yang ditandatangani sendiri melalui peruntukan terkawal, tetapi semata-mata memadankan nama tidak mewujudkan kepercayaan tersebut.

Susulan 4: Bagaimanakah pembatalan patut dibincangkan dalam jawapan temu duga?

Nyatakan sempadan dasar. CRL, OCSP, stapling, status dicache, akses rangkaian, dan peraturan soft-fail atau hard-fail berbeza merentasi klien. Tentukan perkara yang disemak oleh pengesah sebenar dan cara ia bertindak apabila status tidak tersedia. Jangan dakwa bahawa semua klien melakukan pemeriksaan dalam talian yang sama, dan jangan melemahkan dasar hard-fail yang diperlukan secara senyap untuk menghilangkan gangguan.

Susulan 5: Apakah bukti yang menutup insiden ini?

Rekodkan cap jari daun dan perantara yang disediakan bagi setiap pinggir, laluan yang dibina di bawah punca tepat pekerja, bukti nama DNS dan kunci persendirian yang berjaya, serta permintaan pekerja sebenar yang berjaya. Tambahkan ujian negatif untuk nama DNS yang salah, literal IP tanpa IP-ID, dan rantaian yang tidak dipercayai. Sahkan bahawa tiada pintasan yang kekal, semua tika pengimbang beban menyediakan berkas yang dimaksudkan, pemantauan meliputi tamat tempoh dan pemutaran, serta sebarang punca sementara atau artifak diagnostik mempunyai pemilik dan tarikh penyingkiran.