Förnyat VPN-certifikat: vissa klienter avvisar det fortfarande

Halva miljön återansluter efter förnyelsen och tre enheter vägrar, var och en med en varning om gatewayens identitet. Själva förnyelsen är rutin. Det de tre enheterna håller är en pinnning till det gamla objektet, och en pinnning är inte en CA-lista, en namnkontroll eller en post i förtroendelagret. Jämför de tre mekanismerna innan du rör någon klient.

En förnyelse, två beteenden

Klienterna som återansluter har ett förtroendebeslut som fortfarande passerar, och de som vägrar har ett krav som det nya certifikatet inte uppfyller. Den skillnaden är information, inte brus. Läs den felande klientens meddelande noggrant. Namnavvikelse, okänd utfärdare och ändrat fingeravtryck är tre olika domar, och bara den sista pekar på en pinnning.

Kontrollera också vilken profil den felande klienten valde. En importerad kopia som bor i sitt eget lager ändras inte när administratören redigerar originalfilen någon annanstans.

En förnyelse ersätter objektet, inte bara datumet

Ett fingeravtryck identifierar certifikatets kodade innehåll. Förnyelsen skapar ett nytt certifikat, så fingeravtrycket ändras även när subjektnamnet och den publika nyckeln förblir identiska. Det är väntat och ofarligt för klienter som litar på en CA och verifierar namnet. Det är fatalt för en klient som är konfigurerad att acceptera exakt ett certifikat, och det är också fatalt för en klient vars förtroendelager aldrig fick den nya utfärdaren.

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

Den andra raden svarar på en annan fråga, om nyckelparet överlevde. En förnyelse som återanvänder nyckeln behåller det värdet och ändrar bara certifikatet, och det är just det fall där administratören frestas att anta att ingenting har ändrats. Inspektera certifikatet som är utrullat, inte det på byggvärden. Att jämföra en fil i ett repository bevisar vad som genererades, inte vad en lyssnare presenterar just nu.

Läs vad klienten pinnar

Vissa klienter håller ett fingeravtryck i sin profil och jämför det vid varje anslutning. Andra lagrar det i ett förtroendelager på plattformen, och ytterligare andra förlitar sig bara på en CA. Reparationen skiljer sig i varje fall, så identifiera mekanismen först.

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

Det första kommandot visar en pinnning i en konventionell profil; det andra visar fingeravtrycket som endpointen faktiskt betjänar just nu. När de två skiljer sig har du lokaliserat felet utan att gissa. Klistra inte in det nya värdet i varje klient som klagar. En klient som vägrar av utfärdarskäl kommer att fortsätta vägra, och du har lärt dig själv att fingeravtrycket var problemet när det inte var det.

Jämför certifikatet som varje backend betjänar

Oregelbundna resultat betyder oftast mer än en endpoint, och en förnyelse som tillämpats på en nod lämnar de andra att presentera det gamla objektet. Jämför varje backend efter adress i stället för efter det gemensamma namnet.

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

En pool där en nod ligger efter förklarar en klient som ansluter vid andra försöket och misslyckas vid det första. Det förklarar också en övervakningskontroll som passerar medan användarna klagar. Åtgärda eftersläpningen först. Att rulla ut förtroendekonfigurationen innan varje nod betjänar det nya certifikatet skapar ett fönster där ingenting fungerar, och att rulla ut den efteråt lämnar klienterna att misslyckas oförutsägbart.

Ändra förtroende via den hanterade vägen

Bekräfta utbytet genom en redan betrodd administrativ kanal innan du accepterar det någonstans. Ett rimligt utgångsdatum är inte bevis på ägande. Uppdatera den hanterade konfigurationen genom processen som äger den, med eventuellt planerat överlapp av acceptabla identiteter, och behåll namneverifieringen som utrullningen kräver. Pinnning utan namnkontroll är en svagare design än det CA-förtroende den ersatte.

Verifiera sedan per klient, anslut, bekräfta identiteten den accepterade och notera certifikatversionen den nu litar på. En varning som avvisats en gång har en tendens att återkomma vid nästa förnyelse.