Webbcertifikatfel i Access Server: den tomma CA-paketen

Ett tomt ca_bundle-värde eller en skadad PEM stoppar Admin-gränssnittet. Validera certifikat, nyckel och kedja som en uppsättning före omstart, och lämna VPN-PKI i fred.

En inloggningssida som inte laddas medan DNS löses korrekt är oftast inget DNS-problem. Om tjänsteloggen nämner en tom sökväg till certifikatpaketet eller ett PEM-parsefel för webbcertifikatet och den privata nyckeln, har HTTPS-lyssnaren inget användbart material och namnmatchning hjälper inte. Reparationen sitter i tre konfigurationsnycklar och kräver inte att ett enda VPN-klientcertifikat utfärdas på nytt.

Vad de tre nycklarna faktiskt pekar på

Den anpassade webbcertifikatsuppsättningen beskrivs av cs.cert, cs.priv_key och cs.ca_bundle. Var och en lagrar en sökväg till en fil, och webbtjänsten använder alla tre tillsammans. Ett certifikat med fel nyckel, eller en kedjefil som egentligen är lövcertifikatet, misslyckas som ett tomt värde.

Dessa nycklar tillhör Admin- och Client-webbgränssnittet. De är åtskilda från PKI:n som utfärdar certifikat till VPN-klienter, så utbyte kräver inte att profiler, servernyckeln eller certifikatmyndigheten rörs. Att bygga om hela PKI:n är det dyraste felet här.

En skillnad sparar tid: ett uttryckligen tomt anpassat värde är inte samma tillstånd som ingen åsidosättning alls. Den första ger parsern en tom sökväg, det är vad loggraden säger. Den andra låter Access Server stå på eget material.

Varför en befintlig fil ändå inte parsas

Parsern läser de märkta blocken i filen, inte filnamnet. En .crt med privat nyckel, en kedja skriven som ett sammanfogat block, eller en fil sparad med avkortad sista rad avvisas. RFC 7468 definierar dessa läsbara etiketter eftersom de är det enda som talar om vilken objekttyp som följer.

Granska objekten, inte filändelserna. På en Linux-värd svarar openssl x509 -noout -subject -issuer -in server.pem och openssl pkey -noout -check -in key.pem på de två viktiga frågorna, och jämförelse av modulus eller publik nyckel bevisar att de hör ihop. Håll den privata nyckelns utdata borta från ärenden och chattloggar.

En tom sökväg förtjänar samma misstanke som en skadad fil, eftersom båda ger vaga följdfel. Om loggen säger att paketets sökväg är tom, läs det sparade värdet innan du felsöker filen.

Gå medvetet tillbaka till reserven

Access Servers CLI har en valideringskontroll som tar de tre sökvägarna som argument och rapporterar om uppsättningen är användbar. Sökvägarna nedan är exempel; byt ut dem mot de skyddade platserna på värden.

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

Läs resultatet innan du rör den körande tjänsten, och importera först därefter värdena och tillämpa dem via den dokumenterade åtgärden för den installerade versionen. Den officiella CLI-handledningen täcker validering, import och tillämpningssteget, och dess version väger tyngre än någon sammanfattning.

Verifiera namnet användarna faktiskt skriver

När det anpassade materialet är trasigt och en giltig inbyggd reserv fortfarande finns, är den dokumenterade återställningen att ta bort de tre åsidosättningarna och låta Access Server använda reserven. Ordna först konsolåtkomst och en kopia av nuvarande konfiguration.

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

Att rensa hela konfigurationsdatabasen är ingen certifikatreparation. Rikta in dig på de tre nycklarna, tillämpa och bekräfta att webbgränssnittet svarar. De självsignerade filerna under web-ssl är reservresursen, inte en arbetsyta.

Räkna med att webbläsaren visar ett annat certifikat när reserven träder i kraft. Det är rätt resultat; verifiera det genom din betrodda administrativa process.

Återställningen är klar först efter en lyckad inloggning

Återställningen är inte klar när en TCP-lyssnare dyker upp. Validera DNS-namnet, certifikatets identitet och kedjan för det namnet, ladda sedan både Admin- och Client-gränssnittet och slutför en inloggning. En portkontroll bevisar inget av detta.

Access Server 3.1 och senare kan betjäna olika webbcertifikat per SNI-värdnamn. Är det konfigurerat är standardnycklarna och de namnspecifika posterna separata uppsättningar, och test via IP-adress visar lätt ett annat certifikat än användarna får. Reparera och validera uppsättningen för namnet som misslyckades, och upprepa inloggningstestet innan du stänger incidenten.

Relaterade artiklar