Kion via VPN-kliento kontrolas antaŭ ol fidi atestilon

Via VPN-kliento diras, ke la atestilo ne povis esti kontrolita, kaj la dialogo haltas tie. La dosiero ĉeestas, la servilo funkcias, kaj la sama profilo funkciis sur alia tekkomputilo pasintmonate. Sub tiu unulinia averto la kliento trapasis la samtavolan atestilon tra kvar pordegoj: atestila aŭtoritato, kiun vi agordis, garantias la subskriban vojon, tiu vojo atingas la aŭtoritaton, la samtavola nomo estas tiu, kiun vi petis, kaj la atestilo estas nun uzebla por ĉi tiu celo. Trovu la pordegon, kiu fermiĝis, kaj la riparo kutime estas unu dosiero; se vi preterlasos tiun paŝon, vi reimportos pakaĵojn la tutan posttagmezon.

Legi la dialogon antaŭ ol redakti la profilon

Atestilajn erarojn formuladas la suba biblioteko, ne la VPN-produkto, kiun vi instalis, do la preciza signoĉeno estas via unua pruvo. «Ne eblas akiri atestilon de loka eldoninto» montras la vojon aŭ la fidhokon. «La atestilo eksvalidiĝis aŭ ankoraŭ ne validas» montras la tempon. «Nesubtenata atestila celo» montras la etenditan ŝlosiluzon. Nomo-miskongruo diras al vi, kiun nomon ĝi volis. Neniu el la kvar ripariĝas per reinstalo de la kliento.

Altigu la protokoladon antaŭ ol ŝanĝi ion ajn. OpenVPN raportas la kontrolfiaskon ĉirkaŭ la manpremo, kiam vi rulas ĝin kun --verb 4, kaj strongSwan registras siajn decidojn pri identeco kaj ĉeno en la protokolon charon. Poste konfirmu, kiun atestilon vi ekzamenas, ĉar homoj rutine testas la dosieron sur la disko, dum la profilo enigas pli malnovan kopion. Kiam la profilo enigas PEM-blokojn, la enigita atestilo estas tiu, kiu testiĝas.

Atestila aŭtoritato subskribas identecojn, ne permesojn

La aŭtoritato tenas nomon kaj subskriban ŝlosilon. Ĝi eldonas atestilojn, kiuj ligas publikan ŝlosilon al tiu nomo laŭ sia propra politiko, kun valideca fenestro kaj uzaj limigoj alkroĉitaj. Via kliento bezonas nur la atestilon de la aŭtoritato por rekoni la eldoninton; ĝi neniam bezonas la subskriban ŝlosilon, kaj sendi tiun ŝlosilon al klientoj donus al ili la kapablon fabriki ajnan identecon, kiun la deplojo fidas.

Fidi aŭtoritaton faras ĉiun atestilon, kiun ĝi subskribis, kandidato, ne la ĝustan samtavolon. Atestilo de retservilo de la sama interna CA ankaŭ estas kandidato. Tial ekzistas la nomaj kaj celaj pordegoj, kaj tial kompromitita CA-ŝlosilo pli gravas ol iu ajn unuopa servilo: ĝi atingas ĉiun identecon, kiun la aŭtoritato iam eldonis. Disdonu klientajn atestilojn po aparato, por ke perdita tekkomputilo estu unu revoko anstataŭ ŝlosilregenerado por la tuta deplojo.

Rebonu la vojon, kiun la kliento provas boni

La vojo iras de la samtavola atestilo, tra nulo aŭ pli da interaj atestiloj, al radiko en via fidsubrejo. Mankanta intera atestilo estas la plej ofta ĉena fiasko, kaj de la klientsflanko ĝi aspektas idente al nefidinda radiko. Legu unue la folion, poste lasu OpenSSL boni la vojon el la materialo, kiun vi intencas sendi.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Elirstato nulo signifas, ke la vojo boniĝis el tiuj dosieroj; fiasko nomas la atestilon, kiun ĝi ne povis atingi. Se openssl verify sukcesas dum la kliento ankoraŭ rifuzas, la diferenco estas en tio, kion la servilo efektive sendas, aŭ en tio, kiun fidosieron la profilo ŝarĝas. En OpenVPN interaj atestiloj povas vojaĝi kun la servila atestildosiero aŭ esti liveritaj aparte per --extra-certs, kaj pakaĵo kun du radikoj skribitaj sub la sama subjektnomo sendos unu el viaj klientoj laŭ la malĝusta branĉo.

Nomo kaj celo estas apartaj pordegoj

Ĉenbona konstruado neniam demandas, ĉu la nomo estas via. OpenVPN kontrolas ĝin nur kiam la profilo agordas --verify-x509-name, kaj la pli malnova kutimo kongruigi nur la komunan nomon rompiĝas ĉe atestiloj, kies identecoj vivas en subjectAltName. IKEv2-deplojoj kongruigas la agorditan identecon kun SAN-eroj aŭ kun la distinga nomo, laŭ la kliento, kaj sovaĝkarta aŭ %any-valoro silente malŝaltas la komparadon, kiun vi pensis havi.

Poste venas tempo kaj celo. Tekkomputilo, kies horloĝo antaŭas kelkajn horojn, rifuzas atestilon, kiu ankoraŭ ne validas, kaj eksvalidiĝinta intera atestilo fiaskigas la vojon dum la folio estas aktuala. Celaj fiaskoj venas de atestilo sen serverAuth en etendita ŝlosiluzo, aŭ kun keyUsage, kiu ne permesas la manpreman subskribon, kion OpenSSL raportas kiel nesubtenatan atestilan celon. Reeldonu el la ĝusta ŝablono; nenio en tiu mesaĝo estas kialo malŝalti la kontrolon.

Revoko funkcias nur se iu agordis ĝin

CRL aŭ OCSP-respondo ne konsultiĝas aŭtomate. Sur OpenVPN-servilo, klientaj atestiloj kontroliĝas kontraŭ listo nur kiam --crl-verify montras al unu. Klientflanka kontrolo de la servila atestilo dependas de la efektivigo kaj ofte mankas. strongSwan bezonas sian revokan kromaĵon kaj politikon antaŭ ol rigardi CRL por samtavolo.

Tio klarigas la bileton, kiun vi fine ricevos: revokita klienta atestilo ankoraŭ konektiĝas, kaj ĉiuj konkludas, ke revoko estas rompita. Nenio kontrolis. Publikigu kaj refreŝigu la CRL, aŭ tenu klientajn atestilojn sufiĉe mallongdaŭraj, ke eksdata revoko gravas mallonge, kaj ekzercu la revokan vojon per laboratoria atestilo antaŭ ol vi bezonos ĝin dum incidento.

Ripara ordo, kiu tenas la kontrolon ŝaltita

Ordigi laŭ simptomo antaŭ ol tuŝi dosierojn, ĉar ĉiu vico de la tabelo sendas vin al alia objekto.

Trairu la liston en unu paso: konfirmu la dosieron, kiun la profilo ŝarĝas, bonu la vojon mem, kontrolu, ĉu la servilo sendas la interan atestilon, komparu la horloĝon, legu la SAN, legu la EKU, poste rekonektu kaj observu la saman protokollinion malaperi. Se aparato tute ne povas ricevi CA, fiksado estas la honesta alternativo, ĉar OpenVPN 2.6 akceptas --peer-fingerprint kaj mallarĝigas fidon al unu ŝlosilo anstataŭ forigi la kontrolon. RFC 5280 estas la referenco pri tio, kion signifas ĉiu el tiuj kampoj.