Foliosertifikato valida, ĉeno eksvalidiĝis: legu la profundecon

Vi kontrolas la servilan sertifikaton, vidas monatojn restantajn sur la horloĝo, kaj la kliento tamen rifuzas la konekton kun mesaĝo pri eksvalidiĝo. La dato, kiun vi legas, apartenas al la folio, kaj la plendo povas temi pri io pli profunda en la vojo. Kontrolado trairas ĉenon, kaj iu ajn sertifikato, kiun tiu trairo elektas, povas malsukcesi en sia propra valideca fenestro. Legu, kiu malsukcesis, antaŭ ol vi renovigos ion ajn.

La profundo nomas la sertifikaton, kiu malsukcesis

En OpenSSL-diagnostiko, profundo 0 estas la cela sertifikato kaj profundo 1 estas la eldoninto, kiu subskribis ĝin, kun pli altaj nombroj daŭrantaj al la fida ankro. Eksvalidiĝo raportita ĉe profundo 1 ne estas kontraŭdirata de aktuala notAfter sur la folio, do rekontroli la videblan sertifikaton neniam klarigos la eraron.

Notu la fingrospuron de la malsukcesinta sertifikato kune kun ĝia subjekto, ĉar malsamaj sertifikatoj povas porti la saman nomon de CA. Kruca subskribado kreas ĝuste tiun situacion: la sama aŭtoritato aperas pli ol unufoje, kun malsamaj validecdatoj, kaj la kontrolilo elektis tiun, kiun vi ne atendis. Konata etikedo ne estas identigilo, kaj fingrospuro estas tio, kio distingas du objektojn, kiuj dividas nomon.

Atentu ankaŭ produktojn kun pli ol unu sertifikata rolo. Ĉe OpenVPN Access Server, la sertifikatoj protektantaj la retajn interfacojn estas apartaj de tiuj uzataj por VPN-konektoj, do retumilo, kiu malfermas la administran paĝon, pruvas nenion pri la vojo de la tunelo.

Fidaj enigoj ne samas al ĉenaj kandidatoj

Donu al la kontrolilo la du enigojn aparte kaj eksplicite. La fida dosiero tenas la ankrojn, kiujn vi akceptas; la nefidinda pakaĵo tenas perajn sertifikatojn proponitajn por konstrui la vojon. Miksi ilin estas kiel homoj hazarde promocias peran sertifikaton al radiko kaj poste demandas sin, kial la sama eraro sekvas ilin inter maŝinoj.

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

Malŝalti la defaŭltan vojon kaj konservejon per -no-CApath -no-CAstore tenas la teston honesta: la rezulto tiam dependas de la dosieroj, kiujn vi nomis, ne de tio, kion la laborstacio hazarde fidas. La OpenSSL-kontrolreferenco dokumentas tiujn ĉi opciojn kaj la diagnostikon, kiun ili produktas.

-show_chain presas la konstruitan ĉenon kiam kontrolado sukcesas, kio utilas por konfirmi, ke la vojo estas tiu, kiun vi intencis. Kiam ĝi malsukcesas, tenu la raportitan profundon kaj subjekton; tiuj du kampoj diras al la sekva leganto, kiun sertifikaton inspekti.

Kion ĉi tio ne faras, estas reprodukti la politikon de ĉiu kliento. Pinglo, celo-limigo aŭ klient-specifa identeckontrolo vivas en la kliento, ne en ĉi tiu komando. Tiuj estas la agordoj por inspekti kiam kontrolado sukcesas ĉe la servilo kaj la konekto ankoraŭ malsukcesas. Tenu la du diagnozojn apartaj, alie vi renovigos sanan sertifikaton postkurante pinglan eraron.

Kion la kontrolo pruvas kaj kion ĝi ellasas

Ĉi tio estas voja kaj cela kontrolo kontraŭ fida dosiero, kiun vi liveris. Por HTTPS-noma kontrolo, aldonu la atendatan gastigantnomon per la taŭga opcio; por VPN-konekto, tenu la agorditajn identeckontrolojn de la kliento kaj uzu la fidan materialon, kiun tiu kliento efektive legas.

Kion servilo sendas, estas aro de kandidatoj, ne la vojo, kiun via kliento finfine konstruos. Loka fido kaj la konstruaj reguloj de la biblioteko ambaŭ formas la rezulton, pro kio la sama respondo povas kontroliĝi sur unu maŝino kaj malsukcesi sur alia. Komparu la prizorgatan fidkonservejon kaj TLS-implementon de la malsukcesanta kliento kun tiuj de funkcianta kliento antaŭ ol supozi identan takson. Diferenco tie klarigas multajn raportojn „nur ĉi tiu tekkomputilo malsukcesas“.

Por vidi la fenestron de ĉiu sertifikato anstataŭ unu post la alia, presu ilin kiel aron:

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

Tiu dua komando listigas subjektojn kaj eldonintojn sen mane maldekodigi ĉiun dosieron, tiel vi rimarkas peran sertifikaton, kies dato pasis dum la folio ankoraŭ aspektas bona.

Riparu la vojon sen malfortigi la kontroladon

Kiam eksvalida pera aŭ malaktuala kruc-subskribita sertifikato estas liverata, akiru la nun subtenatan ĉenon de la eldoninto kaj deploju ĝin tra la dokumentita sertifikata laborfluo de la servo. Kiam la kliento mankas la intencitan prizorgatan ankron, ĝisdatigu ĝian administritan fidagordon aŭ la klientan programaron. Rezistu la fuŝsolvon marki ĉiun sertifikaton en la pakaĵo kiel radikon nur por silentigi la mesaĝon.

Traktado de radiko meritas noton, ĉar resumoj ofte troigas ĝin. RFC 5280 traktas la ankron kiel enigon, kiu staras ekster la antaŭvida vojo, dum OpenSSL dokumentas valideckontrolojn, kiuj inkluzivas sian radikan CA-sertifikaton. Ambaŭ asertoj validas por siaj propraj sistemoj; ĝeneraligi la radikan eksvalidiĝan konduton de unu biblioteko al ĉiu kliento produktas memfidajn malĝustajn respondojn.

Post la ŝanĝo, devigu freŝan aŭtentikigon ĉe la tuŝita kliento kaj konfirmu, ke la specifa eksvalidiĝa mesaĝo malaperis. Renovigu la folion nur se la folio mem estas netaŭga. Malŝalti tempokontrolojn aŭ restarigi historian krucan sertifikaton ne produktas validan nunan vojon; ĝi nur prokrastas la sekvan malsukceson.