Access Serveri veebisertifikaadi viga: tühi CA-pakett

Tühi ca_bundle väärtus või rikutud PEM peatab Admin-liidese. Kontrollige sertifikaat, võti ja ahel ühe komplektina enne taaskäivitust ning jätke VPN PKI puutumata.

Veebi sisselogimisleht, mis ei laadi, kui DNS laheneb õigesti, ei ole tavaliselt DNS-probleem. Kui teenuse logi mainib tühja sertifikaadipaketi teed või veebisertifikaadi ja privaatvõtme PEM-i parsimise tõrget, ei ole HTTPS-kuulajal kasutatavat materjali ja nime lahendamine ei aita. Parandus on kolmes konfiguratsioonivõtmes ega nõua ühegi VPN-i kliendisertifikaadi uuesti väljastamist.

Millele kolm võtit tegelikult osutavad

Kohandatud veebisertifikaatide komplekti kirjeldavad cs.cert, cs.priv_key ja cs.ca_bundle. Igaüks hoiab faili teed ning veebiteenus kasutab kõiki kolme koos. Vale võtmega sertifikaat või ahelfail, mis on tegelikult lehtsertifikaat, ebaõnnestub nagu tühi väärtus: kuulaja ei suuda koostada ahelat, mille brauser aktsepteeriks.

Need võtmed kuuluvad Admini ja Clienti veebiliidesele. Need on eraldi PKI-st, mis väljastab sertifikaate VPN-i klientidele, seega asendamine ei nõua kliendiprofiilide, serverivõtme ega sertifitseerimisasutuse puudutamist. Veebi TLS-tõrke pidamine kogu PKI ülesehitamise põhjuseks on siin kalleim vale samm.

Üks eristus säästab aega: selgelt tühi kohandatud väärtus ei ole sama olek kui ülekirjutuse täielik puudumine. Esimene annab parserile tühja tee, seda ütlebki logirida. Teine jätab Access Serveri tema enda materjalile, seepärast käivitub osa hoste pärast uuendust korralikult ja teised mitte.

Miks olemasolev fail ikkagi ei parsita

Parser loeb faili sees olevaid märgistatud plokke, mitte failinime. .crt, mis sisaldab privaatvõtit, ahel, mis on kirjutatud ühe kokkusulatatud plokina sinna, kus oodati üht sertifikaati, või fail, mille viimane rida on kärbitud, lükatakse kõik tagasi. RFC 7468 määratleb need loetavad sildid seetõttu, et need on ainus, mis ütleb lugejale, milline objekt järgneb.

Uurige objekte, mitte laiendeid. Linuxi hostis vastavad openssl x509 -noout -subject -issuer -in server.pem ja openssl pkey -noout -check -in key.pem kahele olulisele küsimusele ning mõlema mooduli või avaliku võtme võrdlemine tõestab, et need kuuluvad kokku. Hoidke privaatvõtme väljund piletitest ja vestluslogidest eemal; kontrolliks on vaja sõrmejälge, mitte võtit.

Tühi tee väärib sama kahtlust nagu rikutud fail, sest mõlemad annavad ebamääraseid järgnevaid vigu. Kui logi ütleb, et paketi tee on tühi, lugege salvestatud väärtust enne, kui hakkate faili siluma.

Lülituge teadlikult varulahendusele

Access Serveri CLI sisaldab valideerimiskontrolli, mis võtab kolm teed argumentidena ja teatab, kas komplekt on kasutatav. Allolevad teed on illustratiivsed; asendage need hosti kaitstud asukohtadega:

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

Lugege tulemust enne, kui puudutate töötavat teenust, ja alles siis importige väärtused ning rakendage need paigaldatud versiooni jaoks dokumenteeritud toiminguga. ametlik CLI-õpetus katab valideerimise, konfiguratsiooniandmebaasi importimise ja rakendamise sammu ning selle versioon loeb rohkem kui ükski kokkuvõte.

Kontrollige nime, mille kasutajad tegelikult sisestavad

Kui kohandatud materjal on katki ja kehtiv sisseehitatud varulahendus on veel olemas, on dokumenteeritud taastamine kolme kohandatud ülekirjutuse eemaldamine ja Access Serveri lubamine seda varulahendust kasutada. Tagage esmalt konsoolipääs ja praeguse konfiguratsiooni varukoopia, sest teenus, mille taaskäivitate, teenindab haldusliidest.

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

Kogu konfiguratsiooniandmebaasi tühjendamine ei ole sertifikaadi parandus. Sihtige neid kolme võtit, rakendage ja veenduge, et veebiliides vastab. Kataloogis web-ssl olevad iseallkirjastatud failid on varulahenduse ressurss, mitte tööruum: nende ülekirjutamine või uuesti genereerimine võib eemaldada ainsa töötava materjali.

Oodake, et brauser näitab pärast varulahenduse jõustumist teistsugust sertifikaati. See on õige tulemus ja vastus on seda kontrollida oma usaldusväärse haldusprotsessi kaudu, mitte õpetada kasutajaid igast hoiatusest läbi klõpsama.

Taastamine lõpeb alles pärast edukat sisselogimist

Taastamine ei ole lõppenud, kui ilmub TCP-kuulaja. Kontrollige DNS-nime, sertifikaadi identiteeti ja selle nime ahelat, seejärel laadige nii Admini kui Clienti veebiliides ja lõpetage sisselogimine. Pordikontroll ei tõesta neist midagi.

Access Server 3.1 ja uuemad võivad teenindada erinevaid veebisertifikaate iga SNI-hostinime kohta. Kui see on konfigureeritud, on vaikevõtmed ja nimepõhised kirjed eraldi komplektid ning IP-aadressi järgi testimine näitab kergesti teistsugust sertifikaati kui kasutajad saavad. Parandage ja kontrollige nurjunud nime komplekt ning korrake sisselogimistesti enne juhtumi sulgemist.

Seotud artiklid