Neshoda názvu certifikátu nebo expirace: jak je rozlišit

Dvě selhání VPN vypadají z uživatelova místa stejně a vyžadují opačné opravy. Neshoda názvu říká, že certifikát je platný, ale vydaný pro něco jiného. Chyba expirace říká, že certifikát v tomto okamžiku není platný. Ani jedno není problém s heslem a resetování přihlašovacích údajů je v obou případech nejčastěji promarněná hodina. Přečtěte si fázi, ve které selhání vzniká, dříve než se čehokoli dotknete.

Text chyby je diagnóza

Klient vám řekne, která kontrola selhala, i když je zpráva stručná. Neshoda pojmenuje název hostitele, který očekávala, a název, který našla. Chyba expirace zmiňuje data platnosti nebo čas. Tyto dvě věty ukazují na různé části certifikátu.

Čtěte je ve fázi, kde se objevují. Selhání během handshake je problém certifikátu; selhání poté, co tunel běží, je problém směrování nebo přihlašovacích údajů. Zachování fáze brání tomu, aby vyšetřování sklouzlo k nesouvisejícím nastavením.

Pokud se selhání mezi pokusy liší, máte třetí možnost: více než jeden uzel za stejným názvem.

Kontroly názvu: co klient porovnává

Klient porovnává identitu, kterou byl nakonfigurován očekávat, s názvy v certifikátu, které žijí v rozšíření subjectAltName. Surová IP v profilu, alias, který certifikát neuvádí, nebo název, který se jen překládá na stejný server, všechny v této kontrole selhávají. Dosáhnout správného stroje není totéž jako předložit správnou identitu.

Prohlédněte certifikát, který server skutečně předkládá, ne soubor z dřívějšího pokusu. Příkaz níže žádá název, který jste nastavili, takže odpověď obsahuje certifikát, který by viděl skutečný klient.

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

Certifikát od důvěryhodného vydavatele může být stále pro jinou službu. Ponechte kontroly názvu v klientovi zapnuté, protože důvěra v CA neopravňuje každý název, který tato CA kdy podepsala. Vypnutí kontroly mění chybu konfigurace ve vystavení.

Expirace: čí hodiny se čtou

Platnost je dvojice časových razítek a ověřovatel je porovnává s vlastními hodinami. Zařízení se špatnými hodinami hlásí platný certifikát jako propadlý nebo jako dosud neplatný a opravou jsou hodiny, ne certifikát. Rozdíl v zobrazení časového pásma není totéž jako špatný základní čas.

Porovnejte data certifikátu s UTC na klientovi, než cokoli uzavřete:

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

Pokud data skutečně uplynula, obnovte certifikát přes vydavatele. Pokud náhrada existuje, ale ještě nenabyla platnosti, postupujte podle podporovaného přechodu, místo abyste posouvali hodiny, aby se přizpůsobily. Posunout datum zařízení zpět, aby vyhovělo certifikátu, je rozhodnutí s následky daleko za tunelem.

Proč oprava jednoho odhalí druhé

Validace provádí sled kontrol a první selhání zastaví zprávu. Opravte název a klient vám pak může říct, že řetězec je neúplný nebo že certifikát vypršel. To neznamená, že první kontrola byla zbytečná. Znamená to, že řetězec měl více než jeden problém, takže očekávejte druhou chybu, místo abyste ji četli jako důkaz, že první oprava byla špatná.

Více uzlů to zhoršuje. Služba s vyvažováním zátěže může předkládat různé certifikáty od různých členů, takže test, který dvakrát projde a jednou selže, vám říká o flotile, ne o vašem klientovi. Ponechte v diagnóze adresu protějšku a čas pokusu.

Právě tento detail mění nestabilní tiket v reprodukovatelný.

Dokažte to novým připojením

Po opravě otevřete nové připojení, místo abyste obnovovali staré, a potvrďte, že fáze, která dříve selhávala, nyní prochází. Poté potvrďte, že tunel skutečně přenáší provoz, protože úspěšný handshake není funkční trasa.

Uchovejte přesnou fázi chyby a podrobnosti certifikátu u tiketu.

Právě tento záznam brání dalšímu člověku resetovat hesla účtů kvůli problému s certifikátem. Identita a platnost jsou oddělené otázky a RFC 5280 je referencí pro to, jak se druhá z nich vyhodnocuje.