Retcertifikata eraro en Access Server: malplena CA-pakaĵo

Retpaĝo de ensaluto, kiu ne ŝargiĝas dum DNS solviĝas ĝuste, kutime ne estas DNS-problemo. Se la serva protokolo mencias malplenan vojon de la atestila pakaĵo aŭ malsukceson de PEM-analizo por la reta atestilo kaj privata ŝlosilo, la HTTPS-aŭskultanto havas nenian uzeblan materialon, kaj nenia nom-solvado helpos. La ripariĝo kuŝas en tri agordaj ŝlosiloj, kaj ĝi ne postulas reeldoni eĉ unu VPN-klientan atestilon.

Kion la tri ŝlosiloj vere montras

La propra reta atestilaro estas priskribata per cs.cert, cs.priv_key kaj cs.ca_bundle. Ĉiu konservas vojon al dosiero, kaj la retservo konsumas la tri kune. Atestilo kun malĝusta ŝlosilo, aŭ ĉena dosiero, kiu fakte estas la folia atestilo, malsukcesas same kiel malplena valoro: la aŭskultanto ne povas konstrui ĉenon, kiun retumilo akceptus.

Ĉi tiuj ŝlosiloj apartenas al la Admin- kaj Client-retinterfacoj. Ili estas apartaj de la PKI, kiu eldonas atestilojn al VPN-klientoj, do anstataŭigo ne postulas tuŝi klientajn profilojn, la servilan ŝlosilon aŭ la atestilan aŭtoritaton. Konsideri retan TLS-misojn kialo por tute rekonstrui la PKI estas la plej multekosta eraro ĉi tie.

Unu distingo ŝparas tempon: eksplicite malplena propra valoro ne estas la sama stato kiel nenia anstataŭigo. La unua donas al la analizilo malplenan vojon, tion diras la protokola linio. La dua lasas Access Server sur sia propra materialo, tial iuj gastigantoj startas bone post ĝisdatigo kaj aliaj ne.

Kial ekzistanta dosiero tamen ne analizatas

La analizilo legas la etikeditajn blokojn ene de la dosiero, ne la dosiernomon. .crt enhavanta privatan ŝlosilon, ĉeno skribita kiel unu kunfandita bloko, kie oni atendis unu atestilon, aŭ dosiero konservita kun tranĉita lasta linio ĉiuj estas rifuzataj. RFC 7468 difinas tiujn legeblajn etikedojn ĉar ili estas la sola afero, kiu diras al la leganto, kia objekto sekvas.

Ekzamenu la objektojn, ne la finaĵojn. Sur Linux-gastiganto openssl x509 -noout -subject -issuer -in server.pem kaj openssl pkey -noout -check -in key.pem respondas la du gravajn demandojn, kaj komparo de la modulo aŭ publika ŝlosilo de ambaŭ pruvas, ke ili apartenas kune. Tenu la eligon de la privata ŝlosilo ekster biletoj kaj babilaj protokoloj; la kontrolo bezonas fingrospuron, ne la ŝlosilon.

Malplena vojo meritas la saman suspekton kiel difektita dosiero, ĉar ambaŭ produktas malklarajn postajn erarojn. Se la protokolo diras, ke la pakaĵa vojo estas malplena, legu la konservitan valoron antaŭ ol sencimigi la dosieron.

Reiri al la rezervaĵo intence

La CLI de Access Server inkluzivas validigan kontrolon, kiu prenas la tri vojojn kiel argumentojn kaj raportas, ĉu la aro estas uzebla. La subaj vojoj estas ilustraj; anstataŭigu ilin per la protektitaj lokoj sur la gastiganto:

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

Legu la rezulton antaŭ ol tuŝi la funkciantan servon, kaj nur poste importu la valorojn kaj apliku ilin per la dokumentita operacio por la instalita versio. La oficiala CLI-lernilo kovras validigon, importon en la agordan datumbazon kaj la aplik-paŝon, kaj ĝia versio gravas pli ol iu ajn resumo.

Kontrolu la nomon, kiun uzantoj vere tajpas

Kiam la propra materialo estas difektita kaj valida enkonstruita rezervaĵo ankoraŭ ekzistas, la dokumentita riparo estas forigi la tri proprajn anstataŭigojn kaj lasi Access Server uzi tiun rezervaĵon. Unue certigu konzolan aliron kaj kopion de la nuna agordo, ĉar la servo, kiun vi restartigos, estas tiu, kiu servas la administran interfacon.

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

Viŝi la tutan agordan datumbazon ne estas atestila ripariĝo. Celu tiujn tri ŝlosilojn, apliku, kaj konfirmu, ke la retinterfaco respondas. La memsubskribitaj dosieroj sub la dosierujo web-ssl estas la rezerva rimedo, ne laborspaco: superskribo aŭ regenerado povas forigi la solan funkciantan materialon.

Atendu, ke la retumilo montros alian atestilon post kiam la rezervaĵo efikos. Tio estas la ĝusta rezulto, kaj la respondo estas kontroli ĝin per via fidinda administra procezo, ne instrui uzantojn klaki preter ĉiu averto.

Riparo finiĝas nur post sukcesa ensaluto

Riparo ne finiĝas kiam aperas TCP-aŭskultanto. Kontrolu la DNS-nomon, la atestilan identecon kaj la ĉenon por tiu nomo, poste ŝargu kaj la Admin- kaj la Client-retinterfacon kaj kompletigu ensaluton. Porta kontrolo pruvas neniom el tio.

Access Server 3.1 kaj pli novaj povas ankaŭ servi diversajn retajn atestilojn por ĉiu SNI-gastigantnomo. Se tio estas agordita, la defaŭltaj ŝlosiloj kaj la nom-specifaj rikordoj estas apartaj aroj, kaj testado per IP-adreso facile montras alian atestilon ol tiun, kiun uzantoj ricevas. Riparu kaj kontrolu la aron por la malsukcesinta nomo, poste ripetu la ensalutan teston antaŭ ol fermi la incidenton.