Webcertificaatfout in Access Server: de lege CA-bundel

Een web-loginpagina die niet laadt terwijl DNS correct resolveert, is meestal geen DNS-probleem. Als het servicelog een leeg pad van de certificaatbundel of een PEM-parsefout voor het webcertificaat en de privésleutel noemt, heeft de HTTPS-listener geen bruikbaar materiaal en helpt naamresolutie niet. De reparatie zit in drie configuratiesleutels en vereist geen heruitgifte van één VPN-clientcertificaat.

Waar de drie sleutels echt naar wijzen

De aangepaste set webcertificaten wordt beschreven door cs.cert, cs.priv_key en cs.ca_bundle. Elk slaat een pad naar een bestand op, en de webservice gebruikt alle drie samen. Een certificaat met de verkeerde sleutel, of een ketenbestand dat eigenlijk het bladcertificaat is, faalt net als een lege waarde.

Deze sleutels horen bij de Admin- en Client-webinterface. Ze zijn gescheiden van de PKI die certificaten aan VPN-clients uitgeeft, dus vervangen vereist geen aanpassing van profielen, de serversleutel of de certificaatautoriteit. De hele PKI opnieuw bouwen is hier de duurste fout.

Eén onderscheid bespaart tijd: een expliciet lege aangepaste waarde is niet dezelfde toestand als helemaal geen overschrijving. De eerste geeft de parser een leeg pad, dat zegt de logregel. De tweede laat Access Server op zijn eigen materiaal.

Waarom een bestaand bestand toch niet wordt geparsed

De parser leest de gelabelde blokken in het bestand, niet de bestandsnaam. Een .crt met een privésleutel, een keten als één samengevoegd blok, of een bestand met een afgekapte laatste regel wordt geweigerd. RFC 7468 definieert die leesbare labels omdat ze het enige zijn dat zegt welk object volgt.

Onderzoek de objecten, niet de extensies. Op een Linux-host beantwoorden openssl x509 -noout -subject -issuer -in server.pem en openssl pkey -noout -check -in key.pem de twee belangrijke vragen, en vergelijking van modulus of publieke sleutel bewijst dat ze bij elkaar horen. Houd de privésleutel-uitvoer buiten tickets en chatlogs.

Een leeg pad verdient hetzelfde wantrouwen als een beschadigd bestand, omdat beide vage vervolgproblemen geven. Zegt het log dat het bundlepad leeg is, lees dan de opgeslagen waarde voordat u het bestand debugt.

Valideer de set voordat u iets herstart

De CLI van Access Server heeft een validatie die de drie paden als argumenten neemt en meldt of de set bruikbaar is. De paden hieronder zijn voorbeelden; vervang ze door de beveiligde locaties op de host.

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

Lees het resultaat voordat u de draaiende service aanraakt, importeer daarna de waarden en pas ze toe via de gedocumenteerde handeling voor de geïnstalleerde versie. De officiële CLI-tutorial behandelt validatie, import en de toepassingsstap, en de versie ervan weegt zwaarder dan elke samenvatting.

Terugvallen op de reserve met een reden

Als het aangepaste materiaal stuk is en een geldige ingebouwde fallback nog bestaat, is de gedocumenteerde herstelstap de drie overschrijvingen verwijderen en Access Server die fallback laten gebruiken. Regel eerst consoletoegang en een kopie van de huidige configuratie.

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

De hele configuratiedatabase wissen is geen certificaatreparatie. Richt u op die drie sleutels, pas toe en bevestig dat de webinterface antwoordt. De zelfondertekende bestanden in de map web-ssl zijn de fallbackbron, geen werkruimte.

Verwacht dat de browser een ander certificaat toont nadat de fallback ingaat. Dat is de juiste uitkomst; verifieer het via uw vertrouwde beheerproces.

Controleer de naam die gebruikers echt typen

Herstel is niet klaar wanneer een TCP-listener verschijnt. Valideer de DNS-naam, de identiteit van het certificaat en de keten voor die naam, laad daarna zowel de Admin- als de Client-webinterface en rond een login af. Een poortcontrole bewijst daar niets van.

Access Server 3.1 en later kunnen per SNI-hostnaam verschillende webcertificaten serveren. Is dat geconfigureerd, dan zijn de standaardsleutels en de naamgebonden vermeldingen aparte sets, en testen via IP-adres toont makkelijk een ander certificaat dan gebruikers krijgen. Repareer en valideer de set voor de naam die faalde, en herhaal de login-test voordat u het incident sluit.