Sertifikaat sigbaar in Windows, maar OpenVPN kan nie die sleutel daarvan gebruik nie

Die sertifikaat is in die Windows-sertifikaatkyker sigbaar, en tog kan die kliënt dit nie gebruik nie. Om ’n sertifikaat te sien bewys net dat daar ’n publieke objek in ’n store bestaan. Dit bewys nie dat die verbindingsproses die passende private sleutel kan vind of dat dit mag gebruik word nie.

Drie objekte moet op mekaar pas. Die gekose sertifikaat, die private sleutel agter hom en die rekening waaronder die kliënt loop, is aparte dinge, en elkeen kan op sy eie faal.

Drie objekte, drie antwoorde

Die gemeenskapsweergawe van OpenVPN op Windows dokumenteer ’n CryptoAPI-storekeuse, cryptoapicert, wat ’n duimafdruk neem. Die waarde moet die sertifikaat identifiseer wat jy werklik wil gebruik, nie een met ’n soortgelyke naam nie. Ander OpenVPN-gebaseerde toepassings kan ’n heeltemal ander invoermodel hê, so die keuse is slegs bewys vir die bou wat dit dokumenteer. Bevestig dat jou kliënt die meganisme implementeer voordat jy enigiets stroomaf ontfout.

As die bou die keuse nie ondersteun nie, is die oplossing ’n ander profielformaat, nie ’n ander sertifikaat nie.

Wys die keuse die regte identiteit aan

’n Publieke sertifikaat kan sonder sy private sleutel ingevoer word. Die sertifikaatkyker wys dit in albei gevalle, en daarom lyk hierdie fout asof die kliënt ’n sertifikaat ignoreer wat duidelik daar is. Kyk na die sleutelkoppeling, nie net na die teenwoordigheid van die inskrywing nie.

’n Hernude sertifikaat voeg ’n tweede lokval by. Albei inskrywings kan in die store sit terwyl die profiel nog die ouer duimafdruk noem, en die kliënt bly die identiteit kies wat jy wou aftree.

Kyk na watter identiteit die keuse oplos voordat jy na regte kyk. ’n Verkeerde duimafdruk faal op dieselfde manier as ’n ontbrekende sleutel.

Kan hierdie rekening die sleutel gebruik

Sleuteltoegang geld per rekening. ’n Diens, ’n geskeduleerde taak en ’n interaktiewe lessenaarsessie kan verskillende store-aansigte en verskillende regte hê om ’n private sleutel te gebruik. Dat die sertifikaat in jou eie sessie sigbaar is, sê niks oor die diensrekening nie.

’n Hardewaregesteunde sleutel het dalk sy verskaffer en ’n bevestigingstap nodig. ’n Diens wat nie ’n opdrag kan wys nie, sal nie gered word deur die sleutel na ’n gewone lêer te uitvoer nie.

Lees die plaaslike fout voordat jy enigiets verander. ’n Keusefout, ’n ondertekenfout en ’n afstandverwerping is drie verskillende uitkomste. Net die eerste twee is plaaslik. Die derde beteken die sleutel het gewerk en die bediener het teen die sertifikaat besluit.

Plaaslike gebruik is nie afstandaanvaarding nie

Plaaslike sukses is nie magtiging nie. Sodra die kliënt met sy sleutel onderteken, evalueer die bediener steeds die uitreiker, die geldigheidsvenster, die rol en sy toegangsbeleid. ’n Ander sertifikaat van dieselfde CA dra nie outomaties dieselfde VPN-regte nie.

Die bediener het die vertrouensketting nodig, nie ’n kopie van die kliënt se private sleutel nie. Om die sleutel na die bediener te stuur is nooit die regstelling vir ’n verifikasieprobleem nie.

Werk die fout in volgorde deur

Hou die presiese foutteks. ’n Ontbrekende sleutelreg moet nie ’n CA-verandering word nie, en ’n afstandverwerping moet nie ’n store-herstel word nie. Elkeen het sy eie bewyse.

Werk in die volgorde waarin die fout verskyn: keuse, sleutel, rekening, dan bedienerbeleid. Die gemeenskapskliëntverwysing dokumenteer die Windows-storekeuse vir die weergawe wat jy loop.