Websertifikaatfout in Access Server: die leë CA-bundel herstel

^n Leë ca_bundle-waarde of ^n misvormde PEM stop die Admin-koppelvlak. Valideer sertifikaat, sleutel en ketting saam voordat jy herbegin, en laat die VPN-PKI ongemoeid.

'n Webaanmeldbladsy wat nie laai nie terwyl DNS korrek oplos, is gewoonlik nie 'n DNS-fout nie. Noem die dienslog 'n leë sertifikaatbundelpad of 'n PEM-ontledingsfout vir die websertifikaat en privaatsleutel, dan het die HTTPS-luisteraar geen bruikbare materiaal nie en help geen naamresolusie nie. Die regstelling lê in drie konfigurasiesleutels, sonder om enige VPN-kliëntsertifikaat opnuut uit te reik.

Waarna die drie sleutels werklik wys

Die pasgemaakte websertifikaatstel word deur cs.cert, cs.priv_key en cs.ca_bundle beskryf. Elkeen stoor 'n pad na 'n lêer, en die drie word saam deur die webdiens gebruik. 'n Sertifikaat met die verkeerde sleutel, of 'n kettinglêer wat eintlik die bladsertifikaat is, faal soos 'n leë waarde: die luisteraar bou nie 'n ketting wat 'n blaaier aanvaar nie.

Hierdie sleutels hoort by die Admin- en Client-webkoppelvlak. Hulle is afsonderlik van die PKI wat sertifikate aan VPN-kliënte uitreik, dus hoef kliëntprofiele, bedienersleutel en sertifikaatowerheid nie aangeraak te word nie. Om 'n web-TLS-fout as rede te sien om die hele PKI te herbou, is die duurste verkeerde draai hier.

Een onderskeid spaar tyd: 'n uitdruklik leë pasgemaakte waarde is nie dieselfde as geen oorheersing nie. Die eerste gee die ontleder 'n leë pad, dit is wat die loglyn sê. Die tweede laat Access Server op sy eie materiaal, daarom begin sommige gashere ná 'n opgradering goed en ander nie.

Waarom 'n bestaande lêer steeds nie ontleed nie

Die ontleder lees die gemerkte blokke binne die lêer, nie die lêernaam nie. 'n .crt met 'n privaatsleutel, 'n ketting as een saamgevoegde klomp waar een sertifikaat verwag is, of 'n lêer met 'n afgekapte laaste reël word verwerp. RFC 7468 definieer daardie leesbare etikette omdat hulle die enigste aanduiding is van watter objek volg.

Ondersoek die objekte, nie die uitbreidings nie. Op 'n Linux-gasheer beantwoord openssl x509 -noout -subject -issuer -in server.pem en openssl pkey -noout -check -in key.pem die twee vrae wat saak maak, en vergelyking van die modulus of publieke sleutel van albei bewys hulle hoort saam. Hou privaatsleutel-uitset uit kaartjies en kletslogs; die kontrole het 'n vingerafdruk nodig, nie die sleutel nie.

'n Leë pad verdien dieselfde agterdog as 'n misvormde lêer, want albei lewer vae foute stroomaf. Sê die log die bundelpad is leeg, lees dan die gestoorde waarde voordat jy die lêer ontfout.

Val doelbewus terug

Access Server se CLI het 'n valideringskontrole wat die drie paaie as argumente neem en rapporteer of die stel bruikbaar is. Die paaie hieronder is voorbeelde; vervang dit met die beskermde liggings op die gasheer:

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

Lees die resultaat voordat jy die lopende diens aanraak, en voer eers daarna die waardes in en pas dit toe met die gedokumenteerde bewerking vir die geïnstalleerde weergawe. Die amptelike CLI-tutoriaal dek validering, invoer in die konfigurasiedatabasis en die toepassingstap, en sy weergawe maak meer saak as enige opsomming.

Verifieer die naam wat gebruikers werklik tik

Is die pasgemaakte materiaal stukkend en bestaan 'n geldige ingeboude terugval, dan is die gedokumenteerde herstel om die drie oorheersings te verwyder en Access Server die terugval te laat gebruik. Reël eers konsoltoegang en 'n rugsteun van die huidige konfigurasie, want die diens wat jy herbegin, bedien die administrasiekoppelvlak.

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

Om die hele konfigurasiedatabasis te wis is nie 'n sertifikaatherstel nie. Teiken daardie drie sleutels, pas toe en bevestig dat die webkoppelvlak antwoord. Die selfondertekende lêers onder die web-ssl-gids is die terugvalbron, nie 'n wegdoenbare ruimte nie: oorskryf of hergenereer hulle kan die enigste werkende materiaal verwyder.

Verwag dat die blaaier 'n ander sertifikaat wys nadat die terugval werk. Dit is die korrekte uitkoms; verifieer dit deur jou vertroude administratiewe proses en leer gebruikers nie om elke waarskuwing daarna deur te klik nie.

Herstel is eers klaar na 'n geslaagde aanmelding

Herstel is nie klaar wanneer 'n TCP-luisteraar verskyn nie. Valideer die DNS-naam, die sertifikaatidentiteit en die ketting vir daardie naam, laai dan die Admin- en Client-webkoppelvlak en voltooi 'n aanmelding. 'n Poortkontrole bewys niks daarvan nie.

Access Server 3.1 en later kan ook verskillende websertifikate per SNI-gasheernaam bedien. Is dit gekonfigureer, dan is die verstek-sleutels en die gasheernaam-inskrywings aparte stelle, en toets per IP-adres wys maklik 'n ander sertifikaat as wat gebruikers kry. Maak die stel vir die falende naam reg, verifieer dit en herhaal die aanmeldingstoets voordat jy die voorval sluit.

Verwante artikels