Anda memeriksa sijil pelayan, melihat masih ada berbulan-bulan pada jam, dan klien masih menolak sambungan dengan mesej tamat tempoh. Tarikh yang anda baca milik daun, dan aduan itu mungkin tentang sesuatu yang lebih dalam di laluan. Pengesahan menelusuri rantai, dan mana-mana sijil yang dipilih oleh jelajah ini boleh gagal dalam tetingkap kesahihannya sendiri. Baca yang mana satu gagal sebelum memperbaharui apa-apa.

Kedalaman menamakan sijil yang gagal

Dalam diagnostik OpenSSL, kedalaman 0 ialah sijil sasaran dan kedalaman 1 ialah pengeluar yang menandatanganinya, dengan nombor lebih tinggi meneruskan ke arah sauh kepercayaan. Tamat tempoh yang dilaporkan pada kedalaman 1 tidak disangkal oleh notAfter semasa pada daun, jadi memeriksa semula sijil yang kelihatan tidak akan pernah menjelaskan ralat itu.

Catat cap jari sijil yang gagal bersama subjeknya, kerana sijil berbeza boleh membawa nama CA yang sama. Penandatanganan silang menghasilkan tepat situasi itu: autoriti yang sama muncul lebih daripada sekali, dengan tarikh kesahihan berbeza, dan pengesah memilih yang tidak anda jangkakan. Label biasa bukan pengecam, dan cap jari ialah yang membezakan dua objek yang berkongsi nama.

Perhatikan juga produk dengan lebih daripada satu peranan sijil. Pada OpenVPN Access Server, sijil yang melindungi antara muka web adalah berasingan daripada yang digunakan untuk sambungan VPN, jadi pelayar yang membuka halaman admin tidak membuktikan apa-apa tentang laluan terowong itu.

Input kepercayaan bukan sama dengan calon rantai

Berikan pengesah kedua-dua input secara berasingan dan jelas. Fail kepercayaan menyimpan sauh yang anda terima; berkas tidak dipercayai menyimpan sijil perantaraan yang ditawarkan untuk membina laluan. Mencampurkannya ialah cara orang secara tidak sengaja menaikkan perantaraan kepada akar dan kemudian tertanya-tanya mengapa ralat yang sama mengikut mereka antara mesin.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Melumpuhkan laluan dan stor lalai dengan -no-CApath -no-CAstore mengekalkan ujian itu jujur: hasilnya kemudian bergantung pada fail yang anda namakan, bukan pada apa yang stesen kerja kebetulan percayai. Rujukan pengesahan OpenSSL mendokumenkan pilihan ini dan diagnostik yang dihasilkannya.

-show_chain mencetak rantai yang dibina apabila pengesahan berjaya, yang berguna untuk mengesahkan laluan itu memang yang anda maksudkan. Apabila ia gagal, simpan kedalaman dan subjek yang dilaporkan; kedua-dua medan itu memberitahu pembaca seterusnya sijil mana yang perlu diperiksa.

Apa yang tidak dilakukan ini ialah menghasilkan semula dasar setiap klien. Pin, sekatan tujuan atau pemeriksaan identiti khusus klien hidup dalam klien, bukan dalam arahan ini. Itulah tetapan yang perlu diperiksa apabila pengesahan lulus di pelayan dan sambungan masih gagal. Asingkan kedua-dua diagnosis, atau anda akan memperbaharui sijil yang sihat sambil mengejar ralat pinning.

Apa yang dibuktikan oleh pemeriksaan dan apa yang ditinggalkannya

Ini ialah pemeriksaan laluan dan tujuan terhadap fail kepercayaan yang anda sediakan. Untuk pemeriksaan nama HTTPS, tambah nama hos yang dijangka melalui pilihan yang sesuai; untuk sambungan VPN, kekalkan pemeriksaan identiti yang dikonfigurasikan klien dan gunakan bahan kepercayaan yang benar-benar dibaca oleh klien itu.

Apa yang dihantar pelayan ialah satu set calon, bukan laluan yang akhirnya akan dibina oleh klien anda. Kepercayaan setempat dan peraturan pembinaan pustaka kedua-duanya membentuk hasilnya, sebab itulah respons yang sama boleh disahkan pada satu mesin dan gagal pada mesin lain. Bandingkan stor kepercayaan terurus dan pelaksanaan TLS klien yang gagal dengan milik klien yang berfungsi sebelum menganggap penilaian yang sama. Perbezaan di situ menjelaskan banyak laporan „hanya komputer riba ini gagal“.

Untuk melihat tetingkap setiap sijil dan bukan satu demi satu, cetak ia sebagai satu set:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Arahan kedua itu menyenaraikan subjek dan pengeluar tanpa menyahkod setiap fail dengan tangan, begitulah anda mengesan perantaraan yang tarikhnya sudah berlalu sementara daun masih kelihatan baik.

Betulkan laluan tanpa melemahkan pengesahan

Apabila perantaraan yang tamat tempoh atau sijil bertandatangan silang yang usang dibekalkan, dapatkan rantai pengeluar yang disokong pada masa ini dan gunakan melalui aliran kerja sijil perkhidmatan yang didokumenkan. Apabila klien kekurangan sauh terurus yang dimaksudkan, kemas kini konfigurasi kepercayaan terurusnya atau perisian klien. Tolak jalan pintas menandakan setiap sijil dalam berkas sebagai akar hanya untuk mendiamkan mesej itu.

Pengendalian akar wajar mendapat nota, kerana ringkasan sering membesar-besarkannya. RFC 5280 menganggap sauh sebagai input yang terletak di luar laluan prospektif, manakala OpenSSL mendokumenkan pemeriksaan kesahihan yang merangkumi sijil CA akarnya. Kedua-dua kenyataan adalah benar untuk sistem mereka sendiri; menggeneralisasikan tingkah laku tamat tempoh akar satu pustaka kepada setiap klien menghasilkan jawapan salah yang yakin.

Selepas perubahan, paksa pengesahan baharu pada klien yang terjejas dan sahkan bahawa mesej tamat tempoh khusus itu telah hilang. Perbaharui daun hanya jika daun itu sendiri tidak sesuai. Melumpuhkan pemeriksaan masa atau memulihkan sijil silang sejarah tidak menghasilkan laluan semasa yang sah; ia hanya menangguhkan kegagalan seterusnya.

Artikel berkaitan