Error sa web certificate sa Access Server: walang laman na CA bundle

Ang web login page na hindi naglo-load habang tama ang DNS resolution ay karaniwang hindi problema sa DNS. Kung binanggit ng service log ang walang laman na path ng certificate bundle o pagkabigo ng PEM parsing para sa web certificate at private key, walang magamit na materyal ang HTTPS listener at walang tulong ang name resolution. Nasa tatlong configuration key ang pag-aayos at hindi ito nangangailangan ng muling pag-issue ng kahit isang VPN client certificate.

Ano talaga ang tinutukoy ng tatlong key

Ang custom na web certificate set ay inilalarawan ng cs.cert, cs.priv_key at cs.ca_bundle. Bawat isa ay nag-iimbak ng path sa file, at ginagamit ng web service ang tatlo nang sabay. Ang certificate na may maling key, o chain file na talagang leaf certificate, ay nabigo tulad ng walang laman na value.

Ang mga key na ito ay para sa Admin at Client web interface. Hiwalay ang mga ito sa PKI na naglalabas ng certificate sa mga VPN client kaya hindi kailangang galawin ang profile, server key o certificate authority. Ang muling pagbuo ng buong PKI ang pinakamahal na pagkakamali dito.

Isang pagkakaiba ang nakakatipid ng oras: ang sadyang walang laman na custom value ay hindi parehong estado sa walang anumang override. Ang una ay nagbibigay sa parser ng walang laman na path, iyon ang sinasabi ng log line. Ang pangalawa ay iniiwan ang Access Server sa sarili nitong materyal.

Bakit hindi pa rin nababasa ang file na mayroon

Binabasa ng parser ang mga may label na bloke sa loob ng file, hindi ang pangalan ng file. Ang .crt na may private key, chain na isinulat bilang isang bloke, o file na may putol na huling linya ay tinatanggihan. Itinatakda ng RFC 7468 ang mga nababasang label dahil sila lang ang nagsasabi kung anong uri ng object ang susunod.

Suriin ang mga object, hindi ang extension. Sa Linux host, sinasagot ng openssl x509 -noout -subject -issuer -in server.pem at openssl pkey -noout -check -in key.pem ang dalawang mahalagang tanong, at ang paghahambing ng modulus o public key ay nagpapatunay na magkapares sila. Ilayo ang output ng private key sa mga ticket at chat log.

Ang walang laman na path ay karapat-dapat sa parehong pagdududa tulad ng sirang file, dahil parehong nagdudulot ng malabong kasunod na error. Kung sinasabi ng log na walang laman ang bundle path, basahin ang naka-save na value bago i-debug ang file.

Sadyang bumalik sa fallback

May validation check ang CLI ng Access Server na tumatanggap ng tatlong path bilang argumento at nag-uulat kung magagamit ang set. Ang mga path sa ibaba ay halimbawa lamang; palitan ng protektadong lokasyon sa host.

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

Basahin ang resulta bago hawakan ang tumatakbong service, saka i-import ang mga value at ilapat sa dokumentadong operasyon para sa naka-install na bersyon. Sinasaklaw ng opisyal na CLI tutorial ang validation, import at application step, at mas mahalaga ang bersyon nito kaysa anumang buod.

I-verify ang pangalang talagang tinitipa ng mga user

Kapag sira ang custom na materyal at may valid pang built-in fallback, ang dokumentadong pagbawi ay alisin ang tatlong override at hayaang gamitin ng Access Server ang fallback na iyon. Maghanda muna ng console access at kopya ng kasalukuyang configuration.

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

Ang pagbura ng buong configuration database ay hindi pag-aayos ng certificate. I-target ang tatlong key na iyon, ilapat at kumpirmahing tumutugon ang web interface. Ang self-signed na file sa web-ssl directory ay fallback resource, hindi workspace.

Asahan na magpapakita ang browser ng ibang certificate pagkatapos gumana ang fallback. Iyon ang tamang resulta; i-verify ito sa iyong pinagkakatiwalaang administrative process.

Natatapos lang ang pagbawi pagkatapos ng matagumpay na pag-sign in

Hindi pa tapos ang pagbawi kapag may TCP listener. I-validate ang DNS name, pagkakakilanlan ng certificate at chain para sa pangalang iyon, saka i-load ang Admin at Client web interface at tapusin ang pag-sign in. Walang napapatunayan ang port check sa mga iyon.

Maaari ring maghatid ng ibat ibang web certificate ang Access Server 3.1 pataas sa bawat SNI hostname. Kung naka-configure ito, magkahiwalay na set ang default na key at ang mga entry na partikular sa pangalan, at ang pagsubok sa IP address ay madaling magpakita ng ibang certificate kaysa natatanggap ng mga user. Ayusin at i-validate ang set para sa pangalang nabigo, at ulitin ang pagsubok sa pag-sign in bago isara ang insidente.