Miskongruo de atestila nomo aŭ eksvalidiĝo: kiel distingi ilin

Du VPN-malsukcesoj aspektas identaj de la seĝo de uzanto kaj postulas kontraŭajn riparojn. Miskongruo de nomo diras, ke la atestilo validas sed estas eldonita por io alia. Eraro pri eksvalidiĝo diras, ke la atestilo ne validas en ĉi tiu momento. Neniu el ili estas pasvorta problemo, kaj restarigi akreditaĵojn estas la plej ofte malŝparita horo en ambaŭ kazoj. Legu la malsukcesan etapon antaŭ ol tuŝi ion ajn.

La erarteksto estas la diagnozo

La kliento diras al vi, kiu kontrolo malsukcesis, eĉ kiam la mesaĝo estas konciza. Miskongruo nomas la gastignomon, kiun ĝi atendis, kaj la nomon, kiun ĝi trovis. Eraro pri eksvalidiĝo mencias validigajn datojn aŭ horon. Tiuj du frazoj montras al malsamaj partoj de la atestilo.

Legu ilin ĉe la etapo, kie ili aperas. Malsukceso dum la manpremo estas atestila problemo; malsukceso post kiam la tunelo staras estas problemo pri enkursigo aŭ akreditaĵoj. Reteni la etapon estas tio, kio malhelpas la esploron drivi en nerilatajn agordojn.

Se la malsukceso varias inter provoj, vi havas trian eblecon: pli ol unu nodo malantaŭ la sama nomo.

Nomkontroloj: kion la kliento komparas

La kliento komparas la identecon, kiun ĝi estis agordita atendi, kun la nomoj en la atestilo, kiuj loĝas en la etendo subjectAltName. Kruda IP en la profilo, kaŝnomo, kiun la atestilo ne listigas, aŭ nomo, kiu nur solviĝas al la sama servilo, ĉiuj malsukcesas ĉi tiun kontrolon. Atingi la ĝustan maŝinon ne samas kiel prezenti la ĝustan identecon.

Inspektu la atestilon, kiun la servilo fakte prezentas, anstataŭ dosieron el pli frua provo. La suba komando petas la nomon, kiun vi agordis, do la respondo inkluzivas la atestilon, kiun reala kliento vidus.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Atestilo de fidinda eldonanto ankoraŭ povas esti por alia servo. Tenu la nomkontrolojn de la kliento ŝaltitaj, ĉar fidi CA ne rajtigas ĉiun nomon, kiun tiu CA iam ajn subskribis. Malŝalti la kontrolon igas agordan eraron eksponiĝo.

Eksvalidiĝo: kies horloĝo estas legata

Valideco estas paro de tempaj markoj, kaj la kontrolanto komparas ilin kun sia propra horloĝo. Aparato kun malĝusta horloĝo raportas validan atestilon kiel eksvalidiĝintan aŭ kiel ankoraŭ ne validan, kaj la riparo estas la horloĝo, ne la atestilo. Diferenco en montrado de horzono ne samas kiel malĝusta suba tempo.

Komparu la datojn de la atestilo kun UTC sur la kliento antaŭ ol konkludi ion ajn:

openssl x509 -in cert.pem -noout -dates
date -u

Se la datoj vere pasis, renovigu per la eldonanto. Se anstataŭo ekzistas sed ankoraŭ ne validiĝis, sekvu la subtenatan transiron anstataŭ movi la horloĝon por akomodi ĝin. Retrodatigi aparaton por kontentigi atestilon estas decido kun sekvoj multe preter la tunelo.

Kial ripari unu malkaŝas la alian

Validigo rulas sekvencon de kontroloj, kaj la unua malsukceso haltigas la raporton. Riparu la nomon kaj la kliento povas poste diri al vi, ke la ĉeno estas nekompleta aŭ ke la atestilo eksvalidiĝis. Tio ne signifas, ke la unua kontrolo estis nenecesa. Ĝi signifas, ke la ĉeno havis pli ol unu problemon, do atendu la duan eraron anstataŭ legi ĝin kiel pruvon, ke la unua riparo estis malĝusta.

Pluraj nodoj plimalbonigas tion. Servo kun ŝarĝbalancado povas prezenti malsamajn atestilojn de malsamaj membroj, do testo, kiu sukcesas dufoje kaj malsukcesas unufoje, parolas al vi pri la floto, ne pri via kliento. Tenu la adreson de la samtavolano kaj la provan tempon en la diagnozo.

Tiu detalo estas tio, kio igas malstabilan bileton reproduktebla.

Pruvu ĝin per freŝa konekto

Post la riparo, malfermu novan konekton anstataŭ daŭrigi malnovan, kaj konfirmu, ke la etapo, kiu antaŭe malsukcesis, nun pasas. Poste konfirmu, ke la tunelo efektive portas trafikon, ĉar sukcesa manpremo ne estas funkcianta vojo.

Konservu la precizan eraretapon kaj la atestildetalojn kun la bileto.

Tiu registraĵo estas tio, kio malhelpas la sekvan personon restarigi kontopasvortojn pro atestila problemo. Identeco kaj valideco estas apartaj demandoj, kaj RFC 5280 estas la referenco por kiel la dua estas taksata.