Access Serverin verkkosertifikaattivirhe: tyhjä CA-nippu

Verkkokirjautumissivu, joka ei lataudu, vaikka DNS ratkeaa oikein, ei yleensä ole DNS-ongelma. Jos palvelun loki mainitsee tyhjän sertifikaattinipun polun tai verkkosertifikaatin ja yksityisen avaimen PEM-jäsennyksen epäonnistumisen, HTTPS-kuuntelijalla ei ole käyttökelpoista materiaalia eikä nimenratkaisu auta. Korjaus on kolmessa asetusavaimessa eikä vaadi yhdenkään VPN-asiakassertifikaatin uudelleenmyöntämistä.

Mihin kolme avainta todella viittaavat

Mukautettu verkkosertifikaattijoukko kuvataan avaimilla cs.cert, cs.priv_key ja cs.ca_bundle. Jokainen tallentaa polun tiedostoon, ja verkkopalvelu käyttää kaikkia kolmea yhdessä. Väärällä avaimella varustettu sertifikaatti tai ketjutiedosto, joka onkin lehtisertifikaatti, epäonnistuu kuin tyhjä arvo: kuuntelija ei voi rakentaa ketjua, jonka selain hyväksyisi.

Nämä avaimet kuuluvat Admin- ja Client-verkkokäyttöliittymään. Ne ovat erillään PKI:stä, joka myöntää sertifikaatteja VPN-asiakkaille, joten vaihtaminen ei vaadi asiakasprofiilien, palvelinavaimen tai sertifikaattiviranomaisen koskemista. Verkko-TLS-vian pitäminen syynä koko PKI:n uudelleenrakentamiseen on kallein väärä askel tässä.

Yksi ero säästää aikaa: nimenomaisesti tyhjä mukautettu arvo ei ole sama tila kuin ettei ohitusta ole lainkaan. Ensimmäinen antaa jäsentimelle tyhjän polun, ja sen lokirivi kertoo. Toinen jättää Access Serverin omalle materiaalilleen, siksi jotkin isännät käynnistyvät päivityksen jälkeen hyvin ja toiset eivät.

Miksi olemassa oleva tiedosto ei silti jäsenny

Jäsennin lukee tiedoston sisällä olevat merkityt lohkot, ei tiedoston nimeä. .crt, joka sisältää yksityisen avaimen, ketju yhtenä yhdistettynä lohkona siinä missä odotettiin yhtä sertifikaattia, tai tiedosto, jonka viimeinen rivi on katkaistu, hylätään kaikki. RFC 7468 määrittelee ne luettavat tunnisteet siksi, että ne ovat ainoa asia, joka kertoo lukijalle, minkä tyyppinen objekti seuraa.

Tutki objekteja, älä päätteitä. Linux-isännällä openssl x509 -noout -subject -issuer -in server.pem ja openssl pkey -noout -check -in key.pem vastaavat kahteen tärkeään kysymykseen, ja molempien moduluksen tai julkisen avaimen vertailu todistaa, että ne kuuluvat yhteen. Pidä yksityisen avaimen tuloste poissa tiketeistä ja chat-lokeista; tarkistus tarvitsee sormenjäljen, ei avainta.

Tyhjä polku ansaitsee saman epäluulon kuin vioittunut tiedosto, koska molemmat tuottavat epämääräisiä myöhempiä virheitä. Jos loki sanoo nipun polun olevan tyhjä, lue tallennettu arvo ennen kuin alat selvittää tiedostoa.

Palaa varavaihtoehtoon tarkoituksella

Access Serverin CLI sisältää tarkistuksen, joka ottaa kolme polkua argumenteiksi ja kertoo, onko joukko käyttökelpoinen. Alla olevat polut ovat esimerkkejä; korvaa ne isännän suojatuilla sijainneilla:

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

Lue tulos ennen kuin kosket käynnissä olevaa palvelua, ja vasta sitten tuo arvot ja ota ne käyttöön asennetun version dokumentoidulla toiminnolla. virallinen CLI-opas kattaa tarkistuksen, tuonnin asetustietokantaan ja käyttöönottovaiheen, ja sen versio on tärkeämpi kuin mikään yhteenveto.

Vahvista nimi, jonka käyttäjät todella kirjoittavat

Kun mukautettu materiaali on rikki ja kelvollinen sisäänrakennettu varavaihtoehto on vielä olemassa, dokumentoitu palautus on poistaa kolme mukautettua ohitusta ja antaa Access Serverin käyttää sitä varavaihtoehtoa. Järjestä ensin konsoliyhteys ja nykyisen kokoonpanon varmuuskopio, koska palvelu, jonka käynnistät uudelleen, tarjoaa hallintakäyttöliittymän.

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

Koko asetustietokannan tyhjentäminen ei ole sertifikaattikorjaus. Kohdista ne kolme avainta, ota käyttöön ja varmista, että verkkokäyttöliittymä vastaa. Hakemiston web-ssl itsesignatut tiedostot ovat varavaihtoehdon resurssi, eivät työtila: niiden ylikirjoittaminen tai uudelleenluonti voi poistaa ainoan toimivan materiaalin.

Odota selaimen näyttävän eri sertifikaattia, kun varavaihtoehto astuu voimaan. Se on oikea tulos, ja vastaus on vahvistaa se luotetun hallintaprosessisi kautta, ei opettaa käyttäjiä ohittamaan jokaista varoitusta.

Palautus päättyy vasta onnistuneeseen kirjautumiseen

Palautus ei ole valmis, kun TCP-kuuntelija ilmestyy. Tarkista DNS-nimi, sertifikaatin identiteetti ja ketju sille nimelle, lataa sitten sekä Admin- että Client-verkkokäyttöliittymä ja suorita kirjautuminen loppuun. Porttitarkistus ei todista mitään näistä.

Access Server 3.1 ja uudemmat voivat tarjota eri verkkosertifikaatteja jokaiselle SNI-isäntänimelle. Jos se on määritetty, oletusavaimet ja nimikohtaiset merkinnät ovat erillisiä joukkoja, ja IP-osoitteella testaaminen näyttää helposti eri sertifikaatin kuin käyttäjät saavat. Korjaa ja vahvista epäonnistuneen nimen joukko ja toista kirjautumistesti ennen tapauksen sulkemista.