Itseallekirjoitettu asiakasvarmenne? VPN-palvelin hylkää sen silti
Asiakasvarmenteen on ketjututtava CA:han, johon palvelin luottaa, eikä itseallekirjoitettu tee sitä koskaan. Tässä on, mitä CSR voi tehdä ja mitä pyytää.
Operaattori lähettää osoitteen ja käyttäjätunnuksen, ja asiakasohjelma pyytää CA-tiedoston, varmenteen ja avaimen. Näiden kolmen luominen paikallisesti tuntuu ilmeiseltä seuraavalta askeleelta. Syntyy varmenne, johon vain oma koneesi uskoo. Palvelimen luottamus on ankkuroitu CA:han, jota et hallitse, joten kättely päättyy ennen kuin se alkaa.
Luottamus asuu palvelimella, ei profiilissasi
Varmenteeseen perustuva todentaminen on vertailu. Asiakasohjelma esittää varmenteen; yhdyskäytävä tarkistaa, onko sen allekirjoittanut jokin sen määrityksessä olevista CA:ista.
Profiilisi nimeää CA-tiedoston, jota asiakasohjelman pitäisi käyttää palvelimen vahvistamiseen. Se ei voi nimetä CA:ta, jota palvelimen pitäisi käyttää sinun vahvistamiseesi. Se puoli määrityksestä ei ole sinun.
Itse tehty varmenne epäonnistuu tässä vertailussa, vaikka se olisi teknisesti täydellinen. Siinä on kelvollinen allekirjoitus, subjekti ja päivämäärät, mutta myöntäjä on CA, josta yhdyskäytävä ei ole koskaan kuullut. Virhe ilmaantuu kättelyn aikana, sen jälkeen kun palvelin on jo pyytänyt varmenteen. Mikään asiakasprofiilissa ei voi muuttaa vastausta.
Miksi itseallekirjoitettu varmenne ei voi korvata sitä
Itseallekirjoitettu varmenne on allekirjoitettu omalla avaimellaan. Allekirjoitus vahvistetaan samaa tiedostoa vastaan, mikä tekee siitä itsensä kanssa yhtäpitävän ja hyödyttömän toisen yhdyskäytävän tunnisteeksi.
Yhdyskäytävä ei kysy, onko varmenne sisäisesti yhtäpitävä. Se kysyy, onko luotettu myöntäjä allekirjoittanut sen.
Siksi virheilmoitukset hämmentävät. Asiakasohjelma voi ilmoittaa vahvistusvirheestä, joka kuulostaa palvelimen ongelmalta, kun taas palvelin kirjaa tuntemattoman myöntäjän. Molemmat kuvaavat samaa ristiriitaa vastakkaisista päistä.
CSR-polku säilyttää yksityisen avaimesi
Voit yhä tehdä suurimman osan työstä paikallisesti. Luo avainpari, rakenna varmenteen allekirjoituspyyntö julkisen puoliskon ympärille ja lähetä pyyntö operaattorille. Koneeltasi lähtee vain pyyntö. Yksityinen puolisko jää sinne, missä loit sen.
openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"
Operaattori allekirjoittaa pyynnön omalla CA:llaan ja palauttaa varmenteen. Yksityinen avaimesi ei koskaan matkustanut, ja tulos ketjutuu ankkuriin, johon yhdyskäytävä luottaa.
Hallitut palvelut jättävät CSR:n usein väliin ja myöntävät koko nipun. Se on kohtuullinen vaihtokauppa, kun sama tarjoaja jo päättää tunnelin ja pitää CA:ta. Avaimen säilytys ei parane sitä pitämällä, koska tarjoaja voisi lyödä uuden milloin tahansa.
Niput tuodaan, niitä ei asenneta
Turvallisuudelta kalskahtavilla nimillä varustetut toimittajaniput ovat usein OpenVPN-profiileja. Ne sisältävät määrityksiä ja joskus varmenteita, eivätkä ne asenna mitään. Tuo tiedosto asiakasohjelmaan, joka puhuu protokollaa, ja yhteys on määritetty.
Käsittelysääntö seuraa sisällöstä. Jos profiiliin on upotettu yksityinen avain, se on tunniste ja ansaitsee saman huolen kuin salasana: ei sähköpostia, ei tietovarastoa, ei jaettua latauskansiota. Kun operaattori toimittaa ca.crt, client.crt ja client.key erikseen, säilytä ne yhdessä rajoittavin oikeuksin ja osoita profiili niihin.
Lisää tarkistukset, jotka operaattori on ehkä jättänyt väliin
Reitittimen luomasta profiilista puuttuu joskus vastapuolen vahvistus. remote-cert-tls server vaatii, että vastapuolen varmenteessa on palvelimen todentamiskäyttötarkoitus, jotta asiakasvarmennetta ei voi toistaa palvelimena. Se yksi rivi on pieni muutos, jolla on selkeä peruste.
verify-x509-name menee pidemmälle, kun operaattori voi nimetä odotetun subjektin tai SANin. Molemmat ovat pieniä lisäyksiä profiiliin, ja molemmat ovat perusteltavissa. Tarkasta, mitä sait, ennen kuin tuot sen.
openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt
Vahvistusasetukset eivät ole korjaus katkenneelle ketjulle. Jos myöntäjä on väärä, vastaus on varmenne oikealta CA:lta, ei lippu, joka kytkee tarkistuksen pois. Vahvistuksen pois kytkeminen muuttaa todentamisvirheen havaitsemattomaksi.
Pyydä yksi nippu: viranomaisen varmenne PEM-muodossa, kyseisen viranomaisen allekirjoittama asiakasvarmenne, avain, jonka loit itse tai joka saapui kanavaa pitkin, johon luotat, ja tarkka palvelimen nimi, jonka varmenne pitäisi esittää. Merkitse vanhenemispäivä samaan viestiin, koska vanhentunut varmenne näyttää kuukausia myöhemmin verkkohäiriöltä.