Websertifikatfeil i Access Server: den tomme CA-pakken

En innloggingsside på nettet som ikke lastes mens DNS løses riktig, er vanligvis ikke et DNS-problem. Hvis tjenesteloggen nevner en tom sertifikatpakke-sti eller en PEM-parsefeil for websertifikatet og den private nøkkelen, har HTTPS-lytteren ingen brukbar materiale, og navneoppslag hjelper ikke. Reparasjonen ligger i tre konfigurasjonsnøkler og krever ikke at et eneste VPN-klient sertifikat utstedes på nytt.

Hva de tre nøklene faktisk peker på

Det egendefinerte websertifikatsettet beskrives av cs.cert, cs.priv_key og cs.ca_bundle. Hver lagrer en sti til en fil, og webtjenesten bruker alle tre sammen. Et sertifikat med feil nøkkel, eller en kjedefil som egentlig er bladsertifikatet, feiler som en tom verdi.

Disse nøklene tilhører Admin- og Client-webgrensesnittet. De er atskilt fra PKI-en som utsteder sertifikater til VPN-klienter, så utskifting krever ikke at klientprofiler, servernøkkelen eller sertifikatmyndigheten berøres. Å bygge hele PKI-en på nytt er den dyreste feilen her.

Én forskjell sparer tid: en uttrykkelig tom egendefinert verdi er ikke samme tilstand som ingen overstyring i det hele tatt. Den første gir parseren en tom sti, det er hva logglinjen sier. Den andre lar Access Server stå på sitt eget materiale.

Hvorfor en fil som finnes fortsatt ikke parses

Parseren leser de merkede blokkene i filen, ikke filnavnet. En .crt med privat nøkkel, en kjede skrevet som én sammenføyd blokk, eller en fil lagret med avkuttet siste linje blir avvist. RFC 7468 definerer disse lesbare etikettene fordi de er det eneste som forteller leseren hvilken objekttype som følger.

Undersøk objektene, ikke filendelsene. På en Linux-vert svarer openssl x509 -noout -subject -issuer -in server.pem og openssl pkey -noout -check -in key.pem på de to viktige spørsmålene, og sammenligning av modulus eller offentlig nøkkel beviser at de hører sammen. Hold den private nøkkelens utdata unna saker og chatlogger.

En tom sti fortjener samme mistanke som en ødelagt fil, fordi begge gir vage feil lenger frem. Hvis loggen sier at pakkestien er tom, les den lagrede verdien før du feilsøker filen.

Gå bevisst tilbake til reserve

Access Servers CLI har en valideringskontroll som tar de tre stiene som argumenter og rapporterer om settet er brukbart. Stiene nedenfor er eksempler; bytt dem ut med de beskyttede plasseringene på verten.

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

Les resultatet før du rører den kjørende tjenesten, og importer først deretter verdiene og bruk dem gjennom den dokumenterte operasjonen for den installerte versjonen. Den offisielle CLI-veiledningen dekker validering, import og brukstrinnet, og versjonen teller mer enn noen oppsummering.

Bekreft navnet brukerne faktisk skriver

Når det egendefinerte materialet er ødelagt og en gyldig innebygd reserve fortsatt finnes, er den dokumenterte gjenopprettingen å fjerne de tre overstyringene og la Access Server bruke reserven. Sikre først konsolltilgang og en kopi av gjeldende konfigurasjon.

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

Å tømme hele konfigurasjonsdatabasen er ikke en sertifikatreparasjon. Rette deg mot de tre nøklene, bruk dem og bekreft at webgrensesnittet svarer. De selvsignerte filene under web-ssl er reserveressursen, ikke et arbeidsområde.

Forvent at nettleseren viser et annet sertifikat etter at reserven trer i kraft. Det er riktig resultat; bekreft det gjennom din betrodde administrative prosess.

Gjenopprettingen er først ferdig etter vellykket innlogging

Gjenopprettingen er ikke ferdig når en TCP-lytter dukker opp. Valider DNS-navnet, sertifikatets identitet og kjeden for det navnet, last deretter både Admin- og Client-grensesnittet og fullfør innlogging. En portkontroll beviser ingenting av dette.

Access Server 3.1 og nyere kan betjene ulike websertifikater per SNI-vertsnavn. Er det konfigurert, er standardnøklene og de navnespesifikke oppføringene separate sett, og testing via IP-adresse viser lett et annet sertifikat enn brukerne får. Rett og bekreft settet for navnet som feilet, og gjenta innloggingstesten før du lukker hendelsen.