Eroare de certificat web în Access Server: pachetul CA gol

O valoare ca_bundle goală sau un PEM deteriorat oprește interfața Admin. Validați certificatul, cheia și lanțul ca un singur set înainte de repornire și nu atingeți PKI-ul VPN.

O pagină de autentificare web care nu se încarcă în timp ce DNS se rezolvă corect nu este de obicei o problemă DNS. Dacă jurnalul serviciului menționează o cale goală a pachetului de certificate sau o eroare de parsare PEM pentru certificatul web și cheia privată, ascultătorul HTTPS nu are material utilizabil și rezolvarea numelor nu ajută. Reparația stă în trei chei de configurare și nu cere reemiterea niciunui certificat de client VPN.

Spre ce indică de fapt cele trei chei

Setul personalizat de certificate web este descris de cs.cert, cs.priv_key și cs.ca_bundle. Fiecare stochează o cale către un fișier, iar serviciul web le folosește pe toate trei împreună. Un certificat cu cheia greșită sau un fișier de lanț care este de fapt certificatul frunză eșuează ca o valoare goală.

Aceste chei aparțin interfeței web Admin și Client. Sunt separate de PKI-ul care emite certificate clienților VPN, așa că înlocuirea nu cere atingerea profilelor, a cheii serverului sau a autorității de certificare. Reconstruirea întregului PKI este cea mai scumpă greșeală aici.

O distincție economisește timp: o valoare personalizată explicit goală nu este aceeași stare ca lipsa oricărei suprascrieri. Prima îi dă parserului o cale goală, exact ce spune linia de jurnal. A doua lasă Access Server pe propriul material.

De ce un fișier existent tot nu se parsează

Parserul citește blocurile etichetate din interiorul fișierului, nu numele fișierului. Un .crt care conține o cheie privată, un lanț scris ca un singur bloc sau un fișier salvat cu ultima linie trunchiată sunt respinse. RFC 7468 definește acele etichete tocmai pentru că sunt singurul lucru care spune ce tip de obiect urmează.

Examinați obiectele, nu extensiile. Pe un host Linux, openssl x509 -noout -subject -issuer -in server.pem și openssl pkey -noout -check -in key.pem răspund la cele două întrebări importante, iar compararea modulului sau a cheii publice dovedește că se potrivesc. Țineți ieșirea cheii private în afara tichetelor și a jurnalelor de chat.

O cale goală merită aceeași suspiciune ca un fișier deteriorat, pentru că ambele produc erori ulterioare vagi. Dacă jurnalul spune că calea pachetului este goală, citiți valoarea stocată înainte de a depana fișierul.

Reveniți la rezervă intenționat

CLI-ul Access Server are o validare care preia cele trei căi ca argumente și raportează dacă setul este utilizabil. Căile de mai jos sunt exemple; înlocuiți-le cu locațiile protejate de pe host.

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

Citiți rezultatul înainte de a atinge serviciul care rulează, apoi importați valorile și aplicați-le prin operația documentată pentru versiunea instalată. tutorialul oficial CLI acoperă validarea, importul și pasul de aplicare, iar versiunea sa contează mai mult decât orice rezumat.

Verificați numele pe care utilizatorii îl scriu

Când materialul personalizat este stricat și există încă o rezervă integrată validă, recuperarea documentată este să eliminați cele trei suprascrieri și să lăsați Access Server să folosească acea rezervă. Asigurați mai întâi accesul la consolă și o copie a configurației curente.

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

Ștergerea întregii baze de date de configurare nu este o reparație de certificat. Țintiți acele trei chei, aplicați și confirmați că interfața web răspunde. Fișierele auto-semnate din directorul web-ssl sunt resursa de rezervă, nu un spațiu de lucru.

Așteptați-vă ca browserul să afișeze un alt certificat după ce rezerva intră în vigoare. Acesta este rezultatul corect; verificați-l prin procesul administrativ de încredere.

Recuperarea se încheie doar după o autentificare reușită

Recuperarea nu s-a încheiat când apare un ascultător TCP. Validați numele DNS, identitatea certificatului și lanțul pentru acel nume, apoi încărcați ambele interfețe web Admin și Client și finalizați o autentificare. O verificare de port nu dovedește nimic din toate acestea.

Access Server 3.1 și versiunile ulterioare pot servi certificate web diferite pentru fiecare nume de host SNI. Dacă este configurat, cheile implicite și intrările specifice numelui sunt seturi separate, iar testarea prin adresă IP arată ușor un certificat diferit de cel pe care îl primesc utilizatorii. Reparați și validați setul pentru numele care a eșuat și repetați testul de autentificare înainte de a închide incidentul.

Articole similare