Chyba webového certifikátu v Access Serveru: prázdný balík CA

Webová přihlašovací stránka, která se nenačte, i když se DNS překládá správně, obvykle není problém DNS. Pokud protokol služby zmiňuje prázdnou cestu k balíku certifikátů nebo selhání analýzy PEM u webového certifikátu a soukromého klíče, nemá HTTPS listener použitelný materiál a žádné překládání jmen nepomůže. Oprava je ve třech konfiguračních klíčích a nevyžaduje znovuvydání jediného klientského certifikátu VPN.

Na co tři klíče skutečně ukazují

Vlastní sada webových certifikátů se popisuje klíči cs.cert, cs.priv_key a cs.ca_bundle. Každý ukládá cestu k souboru a všechny tři spotřebovává webová služba společně. Certifikát s nesprávným klíčem nebo soubor řetězu, který je ve skutečnosti koncovým certifikátem, selže stejně jako prázdná hodnota: listener nemůže sestavit řetěz, který by prohlížeč přijal.

Tyto klíče patří webovému rozhraní Admin a Client. Jsou oddělené od PKI, která vydává certifikáty klientům VPN, takže výměna nevyžaduje zásah do klientských profilů, serverového klíče ani certifikační autority. Považovat webovou závadu TLS za důvod k přestavbě celé PKI je tu nejdražší chybný krok.

Jeden rozdíl šetří čas: výslovně prázdná vlastní hodnota není stejný stav jako žádné přepsání. První dává parseru prázdnou cestu, což říká řádek protokolu. Druhá nechává Access Server na vlastním materiálu, proto některé hostitele po upgradu naběhnou dobře a jiné ne.

Proč existující soubor stále nelze analyzovat

Parser čte označené bloky uvnitř souboru, ne název souboru. .crt obsahující soukromý klíč, řetěz zapsaný jako jeden spojený blok tam, kde se čekal jeden certifikát, nebo soubor s uříznutým posledním řádkem se odmítnou. RFC 7468 tyto čitelné značky definuje proto, že jedině ony čtenáři říkají, jaký typ objektu následuje.

Zkoumejte objekty, ne přípony. Na hostiteli Linux odpovídají openssl x509 -noout -subject -issuer -in server.pem a openssl pkey -noout -check -in key.pem na dvě důležité otázky a porovnání modulu nebo veřejného klíče obou dokazuje, že patří k sobě. Výstup soukromého klíče držte mimo tikety a chatové protokoly; kontrole stačí otisk, ne klíč.

Prázdná cesta si zaslouží stejnou nedůvěru jako poškozený soubor, protože obojí dává vágní následné chyby. Pokud protokol říká, že cesta k balíku je prázdná, přečtěte uloženou hodnotu, než začnete ladit soubor.

Vraťte se záměrně k záloze

CLI Access Serveru má ověření, které bere tři cesty jako argumenty a hlásí, zda je sada použitelná. Cesty níže jsou ilustrativní; nahraďte je chráněnými umístěními na hostiteli:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Přečtěte výsledek, než se dotknete běžící služby, a teprve potom importujte hodnoty a použijte je dokumentovanou operací pro nainstalovanou verzi. oficiální tutoriál CLI pokrývá ověření, import do konfigurační databáze a krok použití a jeho verze je důležitější než jakékoli shrnutí.

Ověřte jméno, které uživatelé skutečně zadávají

Když je vlastní materiál poškozený a platná vestavěná záloha stále existuje, dokumentovaná obnova je odstranit tři vlastní přepsání a nechat Access Server použít zálohu. Nejprve zajistěte konzolový přístup a zálohu aktuální konfigurace, protože služba, kterou restartujete, obsluhuje administrační rozhraní.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Smazání celé konfigurační databáze není oprava certifikátu. Zacilte na ty tři klíče, použijte a potvrďte, že webové rozhraní odpovídá. Samopodepsané soubory v adresáři web-ssl jsou záložní zdroj, ne pracovní prostor: přepsání nebo regenerace může odstranit jediný funkční materiál.

Očekávejte, že prohlížeč po uplatnění zálohy ukáže jiný certifikát. To je správný výsledek a odpovědí je ověřit ho důvěryhodným administrativním postupem, ne učit uživatele proklikat každé varování.

Obnova končí až po úspěšném přihlášení

Obnova není hotová, když se objeví TCP listener. Ověřte jméno DNS, identitu certifikátu a řetěz pro toto jméno, poté načtěte obě webová rozhraní Admin a Client a dokončete přihlášení. Kontrola portu nic z toho neprokáže.

Access Server 3.1 a novější mohou obsluhovat různé webové certifikáty pro každé jméno hostitele SNI. Pokud je to nastaveno, výchozí klíče a položky pro konkrétní jméno jsou oddělené sady a testování podle IP adresy snadno ukáže jiný certifikát, než dostávají uživatelé. Opravte a ověřte sadu pro selhávající jméno a před uzavřením incidentu zopakujte test přihlášení.