Websertifikaatflater yn Access Server: it lege CA-pakket

In lege ca_bundle-wearde of in skansearre PEM stopt de Admin-ynterface. Kontrolearje sertifikaat, kaai en keatling as ien set foar it werstarten, en lit de VPN-PKI gewurde.

In webynlochside dy't net lade wol wylst DNS goed oplost, is meastentiids gjin DNS-probleem. As it tsjinstloch in leech sertifikaatpakketpaad neamt of in PEM-parseflater foar it websertifikaat en de priveekaai, hat de HTTPS-lústerder gjin brûkber materiaal en helpt gjin namme-oplossing. De reparaasje sit yn trije konfiguraasjekaaien en freget net om ien VPN-klantsertifikaat opnij út te jaan.

Wêr't de trije kaaien wier nei wize

De oanpaste websertifikaatset wurdt beskreaun troch cs.cert, cs.priv_key en cs.ca_bundle. Elk bewarret in paad nei in bestân, en de trije wurde troch de tsjinst tegearre brûkt. In sertifikaat mei de ferkearde kaai, of in keatlingbestân dat eins it bledsertifikaat is, falt likegoed út as in lege wearde: de lústerder kin gjin keatling bouwe dy't in browser akseptearret.

Dizze kaaien hearre by de Admin- en Client-webynterface. Se binne skieden fan de PKI dy't sertifikaten oan VPN-klanten útjout, dus ferfanging freget net om klantprofilen, de tsjinstkaai of de sertifikaatautoriteit oan te reitsjen. In web-TLS-flater as reden sjen om de hiele PKI opnij te bouwen is hjir de djoerste misstap.

Ien ûnderskied sparret tiid: in dúdlik lege oanpaste wearde is net deselde tastân as hielendal gjin oerskriuwing. De earste jout de parser in leech paad, dat seit de lochrigel. De twadde lit Access Server op eigen materiaal, dêrom starte guon hosts nei in upgrade goed en oaren net.

Wêrom't in besteand bestân dochs net parset

De parser lêst de markearre blokken yn it bestân, net de bestânsnamme. In .crt mei in priveekaai, in keatling skreaun as ien gearfoege blok dêr't ien sertifikaat ferwachte waard, of in bestân mei in ôfsniene lêste rigel wurde allegear wegere. RFC 7468 definiearret dy lêsbere labels om't se it iennige binne dat de lêzer seit hokker soarte objekt folget.

Undersykje de objekten, net de útwreidings. Op in Linux-host beantwurdzje openssl x509 -noout -subject -issuer -in server.pem en openssl pkey -noout -check -in key.pem de twa fragen dy't der ta dogge, en it fergelykjen fan modulus of iepenbiere kaai fan beide bewiist dat se byinoar hearre. Hâld de priveekaai-útfier bûten tickets en chatlochs; de kontrôle hat in fingerôfdruk nedich, net de kaai.

In leech paad fertsjinnet itselde wantrouwen as in skansearre bestân, om't beide ûndúdlike folgjende flaters jouwe. As it loch seit dat it pakketpaad leech is, lês dan de bewarre wearde foar't jo it bestân debugge.

Mei opset werom nei de efterfalopsje

De CLI fan Access Server hat in falidaasjekontrôle dy't de trije paden as arguminten nimt en meldt oft de set brûkber is. De paden hjirûnder binne foarbylden; ferfang se troch de beskerme lokaasjes op de host:

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

Lês it resultaat foar't jo de rinnende tsjinst oanreitsje, en ymportearje pas dêrnei de wearden en pas se ta fia de dokumintearre operaasje foar de ynstallearre ferzje. De offisjele CLI-tutorial beslacht falidaasje, ymport yn de konfiguraasjedatabase en de tapassingsstap, en syn ferzje jildt mear as hokker gearfetting dan ek.

Kontrolearje de namme dy't brûkers echt ynfiere

As it oanpaste materiaal stikken is en in jildige ynboude efterfal noch bestiet, is de dokumintearre werstelling de trije oanpaste oerskriuwingen fuorthelje en Access Server dy efterfal brûke litte. Regelje earst konseltoegong en in backup fan de hjoeddeiske konfiguraasje, want de tsjinst dy't jo werstarte is dejinge dy't de beheardynterface tsjinnet.

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 hiele konfiguraasjedatabase leegje is gjin sertifikaatreparaasje. Rjochtsje jo op dy trije kaaien, pas ta en befêstigje dat de webynterface antwurdet. De selsûndertekene bestannen ûnder de map web-ssl binne de efterfalboarne, gjin wurkromte: oerskriuwen of opnij generearjen kin it iennige wurkjende materiaal fuorthelje.

Ferwachtsje dat de browser nei it ynwurkjen fan de efterfal in oar sertifikaat toant. Dat is de goede útkomst, en it antwurd is it te ferifearjen fia jo fertroude bestjoerlike proses, net brûkers te learen elke warskôging fuort te klikken.

Werstellen einiget pas nei in slagge oanmelding

De werstelling is net dien as in TCP-lústerder ferskynt. Falidearje de DNS-namme, de identiteit fan it sertifikaat en it keatling foar dy namme, laad dan sawol de Admin- as de Client-webynterface en meitsje in oanmelding ôf. In portkontrôle bewiist dêr neat fan.

Access Server 3.1 en letter kinne ek ferskate websertifikaten per SNI-hostnamme tsjinje. As dat konfigurearre is, binne de standertkaaien en de namme-spesifike ynfieringen aparte sets, en testen fia IP-adres lit maklik in oar sertifikaat sjen as dat brûkers krije. Reparearje en falidearje de set foar de namme dy't mislearre, en werhelje dan de oanmeldtest foar't jo it foarfal slute.

Relatearre artikelen