Kin in server-sertifikaatkeatling de fertrouwensopslach fan de klant oerskriuwe?

In browser toant in sertifikaatwarskôging op in side wêrfan’t de keatling folslein is, en de earste ympuls is de server reparearje. Meastentiids presintearret de server krekt wat er moat. De klant beslút hokker ankers er akseptearret, en gjin gearstalling fan tuskenlizzende sertifikaten kin dat beslút fan ’e oare kant fan ’e ferbining feroarje. Dy grins ferklearret it grutste part fan wat as in sertifikaatprobleem liket.

Falidaasje rint op de klant, mei de ankers fan de klant

Paadfalidaasje nimt de presintearre sertifikaten en bout in keatling nei in fertrouwensanker dat it falidaasjesysteem al hat. RFC 5280 beskriuwt dat model, en it pleatst ankerkar by de lokale ymplemintaasje yn stee fan by de server. In applikaasje kin syn eigen belied derop tafoegje: in fêstsette kaai, in bedriuwsfertrouwensopslach, of in strangere identiteitskontrôle. De sertifikaatlist dy’t in server stjoert is bewiis dat oan dat proses bean wurdt, nea in opdracht oan it proses.

Sa bewiist in folsleine keatling dat de server de stikken hat. It bewiist net dat de klant se akseptearje sil.

Om te sjen wat de server eins stjoert, fier út openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts en tel de sertifikaten yn de útfier. In ûnfolsleine keatling dêr is in reparaasje oan ’e serverkant. In folsleine keatling ferpleatst de fraach nei de klant en syn ankers, dêr’t de server gjin stim hat.

Wat TLS-ynspeksje eins feroaret

In ynspeksje-apparaat beëiniget de TLS-sesje oan ’e klantkant en iepenet in aparte sesje nei de echte tsjinst. De klant falidearret dan it sertifikaat fan it apparaat, dat keatlingje moat nei in anker dat de klant fertrout. Dêrom krije behearde apparaten de ynspeksjewoartel fia apparaatbehear, en dêrom toant in persoanlik apparaat sûnder dy in warskôging.

De regeling is bewust en lokaal. Neat yn ’e keatling fan ’e oarspronklike server kin in net-beheard browser twinge de ferfangende identiteit te akseptearjen, en neat deryn hinderet in beheard apparaat om dat te dwaan.

VPN-beëiniging is gjin HTTPS-ûntsifering

In VPN-laach ferfiert pakketten tusken in klant en in gateway. It fuortheljen dêrfan, of it lêzen fan syn konfiguraasje, leit gjin HTTPS-lading binnen bleat.

De TLS-sesje rint noch altyd tusken de browser en de webserver, mei deselde falidaasjeregels, útsein as eat it eksplisyt beëiniget. It trochinoar heljen fan ’e twa lagen liedt ta in fersyk oan ’e VPN-administrator om it sertifikaat te leverjen, wylst it sertifikaat yn kwestje ta in ynspeksjeproxy of ta de side sels heart. Freegje hokker komponint it sertifikaat presintearret foardat jo in fertrouwensopslach feroarje.

Set ferwachtings yn it komponint dat jo kontrolearje

As jo de applikaasje en syn klant beheare, definiearje dan tegearre de ferwachte tsjinstidentiteit, de akseptearre útjouwers en elke eask foar fêstsetten of klantautentikaasje. Plan fernijing en werstel sa dat in legitim sertifikaatferoaring gjin ûnderbrekking wurdt. As jo allinnich de publike server beheare, dokumintearje dan hokker autentikaasje jo easkje en hokker klantomjouwings jo stypje. It stjoeren fan in foarkarkeatling sertifisearret net it apparaat fan in frjemdling.

Op beheard apparatuer, oplos ynkompatibiliteit fia de applikaasje- en netwurkeigners. Falidaasje útskeakelje, in ûnferklearre woartel tafoegje, of besykje in ynspeksjebelied te oerlibjen, fêstiget net de bedoelde peer-relaasje.

Test it resultaat op in skjin klantprofyl, net op ’e masine dêr’t al in útsûndering tafoege is. Dat is de iennichste kontrôle dy’t sjen lit wat in nij apparaat belibje sil.