Renovigita VPN-atestilo: iuj klientoj ankoraŭ malakceptas ĝin

Duono de la infrastrukturo rekonektiĝas post la renovigo kaj tri aparatoj rifuzas, ĉiu kun averto pri la identeco de la enirejo. La renovigo mem estas rutino. Tio, kion tiuj tri aparatoj tenas, estas pinglo al la malnova objekto, kaj pinglo ne estas CA-listo, nomkontrolo aŭ enskribo en fida konservejo. Komparu la tri mekanismojn antaŭ ol tuŝi ajnan klienton.

Unu renovigo, du kondutoj

La klientoj, kiuj rekonektiĝas, havas fiddecidon, kiu ankoraŭ pasas, kaj tiuj, kiuj rifuzas, havas postulon, kiun la nova atestilo ne plenumas. Tiu diferenco estas informo, ne bruo. Legu la mesaĝon de la malsukcesanta kliento precize. Nommalkongruo, nekonata eldonanto kaj ŝanĝita fingrospuro estas tri malsamaj verdiktoj, kaj nur la lasta montras pinglon.

Ankaŭ kontrolu, kiun profilon la malsukcesanta kliento elektis. Importita kopio, kiu loĝas en sia propra konservejo, ne ŝanĝiĝas kiam la administranto redaktas la originalan dosieron aliloke.

Renovigo anstataŭigas la objekton, ne nur la daton

Fingrospuro identigas la kodigitan enhavon de la atestilo. Renovigo produktas novan atestilon, do la fingrospuro ŝanĝiĝas eĉ kiam la subjekta nomo kaj la publika ŝlosilo restas identaj. Tio estas atendita kaj senmalutila por klientoj, kiuj fidas CA kaj kontrolas la nomon. Ĝi estas mortiga por kliento agordita por akcepti precize unu atestilon, kaj ĝi ankaŭ estas mortiga por kliento, kies fida konservejo neniam ricevis la novan eldonanton.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

La dua linio respondas al alia demando: ĉu la ŝlosilparo postvivis. Renovigo, kiu reuzis la ŝlosilon, konservas tiun valoron kaj ŝanĝas nur la atestilon, kio estas precize la kazo, en kiu administranto estas tentata supozi, ke nenio ŝanĝiĝis. Inspektu la atestilon, kiu estas deplojita, ne tiun sur la konstrua gastiganto. Kompari dosieron en deponejo pruvas, kio estis generita, ne kion nun prezentas aŭskultanto.

Legu, kion la kliento pinglas

Iuj klientoj tenas fingrospuron en sia profilo kaj komparas ĝin ĉe ĉiu konekto. Aliaj konservas ĝin en platforma fida konservejo, kaj aliaj denove fidas nur CA. La riparo diferencas en ĉiu kazo, do unue identigu la mekanismon.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

La unua komando montras pinglon en konvencia profilo; la dua montras la fingrospuron, kiun la finpunkto efektive prezentas nun. Kiam tiuj du diferencas, vi lokis la fiaskon sen diveni. Ne algluu la novan valoron en ĉiun klienton, kiu plendas. Kliento rifuzanta pro eldonanto daŭre rifuzos, kaj vi estos lerniginta al vi, ke la fingrospuro estis la problemo kiam ĝi ne estis.

Komparu la atestilon, kiun prezentas ĉiu backendo

Intermitaj rezultoj kutime signifas pli ol unu finpunkton, kaj renovigo aplikita al unu nodo lasas la aliajn prezenti la malnovan objekton. Komparu ĉiun backendon laŭ adreso anstataŭ laŭ la komuna nomo.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Naĝejo, en kiu unu nodo malfruas, klarigas klienton, kiu konektiĝas ĉe la dua provo kaj fiaskas ĉe la unua. Ĝi ankaŭ klarigas monitoran kontrolon, kiu pasas dum uzantoj plendas. Riparu la malfruon unue. Ruli la fidan agordon antaŭ ol ĉiu nodo prezentas la novan atestilon kreas fenestron, en kiu nenio funkcias, kaj ruli poste lasas klientojn fiaski neantaŭvideble.

Ŝanĝu fidon per la administrata vojo

Konfirmu la anstataŭigon per jam fidinda administra kanalo antaŭ ol akcepti ĝin ie ajn. Verŝajna findato ne estas pruvo de posedo. Ĝisdatigu la administran agordon per tiu ajn procezo, kiu posedas ĝin, kun iu ajn planita interkovro de akcepteblaj identecoj, kaj konservu la nomkontrolon, kiun la deplojo postulas. Pinglo sen nomkontrolo estas pli malforta dezajno ol la CA-fido, kiun ĝi anstataŭigis.

Poste kontrolu laŭ kliento: konektiĝu, konfirmu la identecon, kiun ĝi akceptis, kaj notu la atestilan version, kiun ĝi nun fidas. Averto forĵetita unufoje havas manieron reveni ĉe la sekva renovigo.