Waarom verwerp OpenConnect die poort ná ’n sertifikaatruil?
’n Verifikasiefout ná ’n sertifikaatruil by die poort is ’n vertrouensbeslissing, nie ’n stukkende tonnel nie. Kies tussen die uitreikende CA en ’n enkele sleutelpen.
Poorte vervang sertifikate, en ’n kliënt wat gister nog gekonnekteer het, begin by die eerste TLS-uitruiling stop. Die boodskap noem ’n verifikasierede eerder as ’n netwerkfout, en die masjien self het nie verander nie, wat die nuttige leidraad is. Wat gebreek het, is die verhouding tussen die sertifikaat wat nou aangebied word en die wortels wat die kliënt bereid is om te oorweeg. Om dit reg te maak, is ’n vertrouensbeslissing, so neem daardie beslissing voordat jy ’n opsie intik.
Lees die fout voordat jy enige vertrouensinstelling verander
’n Fout in die trant van ’n ontbrekende ondertekenaar beteken die ketting eindig by iets wat die kliënt nie aanvaar nie. Dit kan ’n hernieude sertifikaat van ’n interne owerheid wees, ’n vervanging van ’n openbare een, of ’n toestel in die middel wat sy eie sertifikaat aanbied. Die bewoording alleen kan nie daardie gevalle onderskei nie, so kyk na die uitreiker voordat jy besluit.
Voer die verbinding een keer op die voorgrond uit en laat dit misluk, want die interaktiewe uitset bevat die bedienernaam, die uitreikersketting en die vingerafdruk wat die kliënt bereken het. Vergelyk daardie uitreiker met ’n owerheid wat jou organisasie werklik bedryf. As die vingerafdruk verander het terwyl die uitreiker dit nie gedoen het nie, behandel dit as verdag totdat ’n hernuwing deur ’n kanaal bevestig word wat jy reeds vertrou. Om op hierdie punt te raai, is hoe iemand daarmee eindig dat hy ’n onderskepper se sleutel vaspen.
Teken die kliëntweergawe in dieselfde nota aan. ’n Goeie deel van die mislukkings wat soos vertrouensprobleme lyk, kom van ’n ouer kliënt wat ’n nuwer poortuitruiling teëkom.
Kies tussen die uitreiker vertrou en een sleutel vaspen
Beide opsies laat die verbinding slaag. Hulle breek later op teenoorgestelde maniere, so die keuse hoort by die mislukking wat jy kan verdra.
| Approach | Good fit | What breaks it |
|---|---|---|
Trust the issuing CA with --cafile | Internal PKI you can obtain over an already trusted channel | CA rotation, or a client that still falls back to public roots |
Pin one key with --servercert | No CA relationship, or exactly one key should ever be accepted | Any reissue that generates a new key pair |
Gryp na die CA-lêer wanneer die sertifikaat van ’n owerheid kom wat jy onafhanklik kan verifieer, want hernuwings bly dan werk sonder om kliëntargumente aan te raak. Koppel dit aan die skakelaar wat stelselwortels deaktiveer, anders kan ’n openbare owerheid die kontrole namens jou bevredig. Pen eerder vas wanneer die poort geen CA het wat jy kan bekom nie, of wanneer die nouste moontlike uitsondering die doel is. Nie een pad is in die abstrak meer veilig nie: die CA skaal oor hernuwings, die pen is makliker om na te gaan.
Watter een jy ook kies, die vertroude waarde moet aankom deur ’n kanaal wat vertrou is voordat die verandering plaasgevind het. ’n Administrateur, ’n konsole-sessie op die poort, of ’n afskrif wat vooraf geneem is, kwalifiseer almal. Om te kopieer watter vingerafdruk die opdrag ook al wys, is gerieflik en is ook presies wat ’n onderskepper hoop.
Sit die waarde in die opdrag wat jy werklik begin
Die pen reis in ’n bediener-sertifikaat-opsie, en sy voorvoegsel bepaal die enkodering: heksadesimale publieke-sleutel-samestellings onder sha1 of sha256, en die base64-sleutelpen onder pin-sha256. Om dit te verskaf, deaktiveer ook stelselvertroue vir daardie lopie, so die vasgepen sleutel word die hele beslissing.
sudo openconnect --protocol=gp vpn.example.com --user alice \
--servercert pin-sha256:AbCdEf... # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust
Die kliënt pas ’n afgekorte samestelling, en aanvaar so min as vier karakters ná die voorvoegsel, wat ’n lokval eerder as ’n gerief is. ’n Verkorte waarde slaag plaaslik en identifiseer steeds nie die poort wat jy bedoel het nie. Kopieer die volle string wat die kliënt by die eerste poging gedruk het, in plaas daarvan om dit uit ’n boodskap oor te tik. Skuiwe dan die voltooide opsie in die wrapper-skrip, eenheidlêer of profiel wat die verbinding begin, sodat die vertrouensbeslissing nagegaan kan word en latere wysigings doelbewus is.
Werkskerm-bekendstellers en die NetworkManager-inprop stoor hul eie kopie van die verbindingsargumente. ’n Skrip wat op skyf geredigeer is, bereik nie ’n profiel wat vroeër ingevoer is nie, so die gestoorde waarde bly wen.
Hanteer ’n oorskrywing sonder om jouself uit te sluit
Die opsie kan meer as een keer gegee word, so ’n beplande verandering kan die uitgaande en inkomende sleutels saam aanvaar. Voeg die nuwe pen by voordat die poort oorskakel, hou beide gelys terwyl sessies migreer, en laat die afgetrede een val sodra die ou sleutel weg is. Daardie venster het ’n eienaar nodig, want ’n vergete dubbele pen laat ’n sleutel vertrou met niemand wat daaroor waak nie. ’n Herbouing wat ’n vars sleutelpaar oplewer, breek ’n suiwer pen, en herstel is dieselfde prosedure in die ander rigting.
Skryf die veranderingsdatum langs die pen. ’n Pen sonder ’n hersieningsdatum is ’n toekomstige onderbreking wat ’n verwarrende foutboodskap dra.
Sluit die kliëntweergawe uit voordat jy vertroue wysig
’n Verouderde kliënt kan misluk terwyl dit ’n verifikasie-antwoord ontleed wat die poort intussen verander het, en die oppervlakboodskap praat steeds van die verbinding eerder as die ontleder. Vergelyk die geïnstalleerde weergawe met wat die poort dokumenteer, en toets ’n huidige pakket in ’n wegdoenbare profiel voordat jy enige vertrouensinstelling verander.
openconnect --version
Nadat jy dit reggemaak het, verifieer twee dinge eerder as een: die portaal laai deur die tonnel, en ’n gewone interne adres antwoord. ’n Voltooide handdruk bewys net dat die vertrouensbeslissing aanvaar is.