Webcertifikatfejl i Access Server: den tomme CA-pakke

En webloginside, der ikke vil indlæse, mens DNS opløses korrekt, er normalt ikke et DNS-problem. Hvis tjenesteloggen nævner en tom certifikatpakke-sti eller en PEM-parsefejl for webcertifikatet og den private nøgle, har HTTPS-lytteren intet brugbart materiale, og ingen navneopløsning hjælper. Rettelsen ligger i tre konfigurationsnøgler og kræver ikke, at et eneste VPN-klientcertifikat genudstedes.

Hvad de tre nøgler egentlig peger på

Det tilpassede webcertifikatsæt beskrives af cs.cert, cs.priv_key og cs.ca_bundle. Hver gemmer en sti til en fil, og de tre bruges sammen af webtjenesten. Et certifikat med den forkerte nøgle, eller en kædefil der faktisk er bladcertifikatet, fejler som en tom værdi: lytteren kan ikke bygge en kæde, som en browser accepterer.

Disse nøgler hører til Admin- og Client-webgrænsefladen. De er adskilt fra den PKI, der udsteder certifikater til VPN-klienter, så udskiftning kræver ikke, at klientprofiler, servernøglen eller certifikatmyndigheden røres. At behandle en web-TLS-fejl som grund til at genopbygge hele PKI er det dyreste fejltrin her.

Én sondring sparer tid: en udtrykkeligt tom tilpasset værdi er ikke samme tilstand som ingen tilsidesættelse. Den første giver parseren en tom sti, og det er hvad loglinjen siger. Den anden lader Access Server bruge sit eget materiale, og derfor starter nogle værter fint efter en opgradering og andre ikke.

Hvorfor en fil, der findes, stadig ikke kan parses

Parseren læser de mærkede blokke inde i filen, ikke filnavnet. Et .crt med en privat nøgle, en kæde skrevet som én sammenkædet klump, hvor ét certifikat var forventet, eller en fil gemt med en afkortet sidste linje afvises alle. RFC 7468 definerer de læsbare mærker, fordi de er det eneste, der fortæller læseren, hvilken type objekt der følger.

Undersøg objekterne, ikke filendelserne. På en Linux-vært besvarer openssl x509 -noout -subject -issuer -in server.pem og openssl pkey -noout -check -in key.pem de to vigtige spørgsmål, og sammenligning af modulus eller offentlig nøgle for begge beviser, at de hører sammen. Hold den private nøgles output ude af tickets og chatlogs; kontrollen skal bruge et fingeraftryk, ikke nøglen.

En tom sti fortjener samme mistanke som en beskadiget fil, fordi begge giver vage fejl længere fremme. Hvis loggen siger, at pakkestien er tom, så læs den gemte værdi, før du fejlfinder filen.

Fald tilbage med vilje

Access Servers CLI indeholder en valideringskontrol, der tager de tre stier som argumenter og rapporterer, om sættet er brugbart. Stierne nedenfor er illustrative; erstat dem med de beskyttede placeringer på værten:

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

Læs resultatet, før du rører den kørende tjeneste, og importer først derefter værdierne og anvend dem gennem den dokumenterede handling for den installerede version. Den officielle CLI-vejledning dækker validering, import til konfigurationsdatabasen og anvendelsestrin, og dens version betyder mere end nogen opsummering.

Bekræft det navn, brugerne faktisk skriver

Når det tilpassede materiale er ødelagt, og et gyldigt indbygget fallback stadig findes, er den dokumenterede gendannelse at fjerne de tre tilpassede tilsidesættelser og lade Access Server bruge fallbacken. Sørg først for konsoladgang og en sikkerhedskopi af den nuværende konfiguration, for den tjeneste, du genstarter, er den, der betjener administrationsgrænsefladen.

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

At rydde hele konfigurationsdatabasen er ikke en certifikatreparation. Ret dig mod de tre nøgler, anvend, og bekræft at webgrænsefladen svarer. De selvsignerede filer under web-ssl-mappen er fallback-ressourcen, ikke et arbejdsområde: overskrivning eller regenerering kan fjerne det eneste fungerende materiale.

Forvent, at browseren viser et andet certifikat, når fallbacken træder i kraft. Det er det korrekte resultat, og svaret er at bekræfte det gennem din betroede administrative proces, ikke at lære brugerne at klikke gennem hver advarsel.

Gendannelse er først slut efter et vellykket login

Gendannelsen er ikke slut, når en TCP-lytter dukker op. Validér DNS-navnet, certifikatets identitet og kæden for det navn, indlæs derefter både Admin- og Client-webgrænsefladen og gennemfør et login. En portkontrol beviser intet af det.

Access Server 3.1 og nyere kan også betjene forskellige webcertifikater pr. SNI-værtsnavn. Er det konfigureret, er standardnøglerne og de navnespecifikke poster separate sæt, og test via IP-adresse viser let et andet certifikat end det, brugerne får. Ret og bekræft sættet for det navn, der fejlede, og gentag derefter login-testen, før du lukker hændelsen.