Å legge til en VPN-klient uten å bygge CA på nytt

Du skal ha ett sertifikat til til en maskin til, og det første treffet i søket starter med en kommando som sletter hele PKI-katalogen. Den kommandoen hører til oppsettet av systemet, ikke til påmelding, og kjøres den, forsvinner CA-en, hele utstedelseshistorikken og alle klientprofilene som hadde tillit til den forrige utstederen. Spørsmålet er egentlig lite: har utstederen din fortsatt en tilstand som kan brukes, og passer den nye enheten med påmeldingsreglene dere allerede følger? Tre forhold avgjør saken, og bare ett av dem gjør et nybygg riktig.

Hva et nybygg egentlig ødelegger

Når en PKI initialiseres på nytt, blir katalogen erstattet av en tom struktur: ny CA-nøkkel og nytt sertifikat, tom utstedelsesdatabase og en serieteller som starter fra null. Klientene blir ikke med automatisk. Profilene deres er bundet til den gamle CA-en, så alle enheter må meldes på igjen, og de som ikke kan nås, må ordnes for hånd.

Det mest lydløse tapet er regnskapet. Tilbakekalling forutsetter at du vet hvilke serienumre som ble utstedt og til hvem. Sletter du indeksen, kan du fortsatt signere, men du kan ikke lenger si trygt hvilke av de utstedte sertifikatene du ønsket å kalle tilbake. En CA-katalog med sertifikater men uten utstederens tilstand er en sikkerhetskopi som gjenoppretter den gale halvdelen av systemet.

Å legge den private CA-nøkkelen ved siden av den kjørende serveren er den andre snarveien som bør avvises: den gjør en signeringsmyndighet som skal stå utenfor nettet til nok en fil på en vert som avslutter trafikk dere ikke stoler på.

Første forhold: er utstederens tilstand fortsatt tilgjengelig?

Finn katalogen serveren faktisk har tillit til, før du bestemmer noe. Sammenlign sertifikatet serveren viser som CA med det som ligger i PKI-katalogen, og gjør det med fingeravtrykk, ikke med filnavn:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Er avtrykkene like, er påmeldingen trinnvis og du skal ikke bygge noe på nytt. Er de forskjellige, signerer du med en CA serveren ikke har tillit til: sertifikatet installeres uten feil og feiler i håndtrykket, og den feilen blir i timevis feiltolket som en feil på klientsiden.

Se deretter etter utstedelsestilstanden: indeksfilen, serietelleren og filen med CRL-nummer. Er indeksen borte men nøkkelen intakt, kan du utstede, men du arver et problem med å føre register over tilbakekallinger. Før det inn i endringsloggen, for den neste tilbakekallingen vil avsløre det.

Andre forhold: hvem sitter med den nye private nøkkelen?

Dette er avgjørelsen brukerne merker, så ta den åpent. En nøkkel som lages på klienten og sendes inn som forespørsel, blir liggende med den private delen på enheten fra første kommando, og administratoren tar aldri i den. En nøkkel som lages på serveren, er lettere for enheter uten verktøy, men gjør administratoren til den som vokter hver klientnøkkel, og gjør et serverinnbrudd mer alvorlig.

Med Easy-RSA 3 mot en eksisterende CA er innlesing og signering av en forespørsel to kommandoer:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Velg sertifikattypen med vilje. En forespørsel som signeres som server- i stedet for klientsertifikat, gir en fil som ser riktig ut og som motparten avviser, og feilmeldingen sier sjelden hvorfor. Bruker du openssl ca, ligger det samme valget i utvidelsene du sender inn, ikke i standarddelen.

Tredje forhold: trenger serveren noe mer enn sertifikatet?

For en vanlig OpenVPN-server med sertifikatautentisering er sertifikatet selve påmeldingen: det felles navnet blir klientens identitet, og klientkataloger, dyttede ruter og faste adresser henger sammen med det navnet. Legger du inn sertifikatet og glemmer oppsettet, kobles tunnelen opp, men rutene brukeren trenger dukker aldri opp.

Plattformer endrer dette. OpenVPN Access Server har sin egen brukerbase, så et signert sertifikat er ikke en konto; kontoen må finnes og være tillatt. Andre gatewayer knytter en identitetsstreng til en gruppe. Påmelding av én enhet berører som regel to systemer, og sertifikatet er bare det første.

Fremgangsmåten trinn for trinn, og når et nybygg er riktig

Rekkefølgen som legger til én enhet uten skade: bekreft utstederen med fingeravtrykk, ta en fersk sikkerhetskopi av PKI-katalogen, les inn og signer forespørselen for klientrollen, overlever sertifikatet med kjeden sin gjennom den godkjente kanalen, og verifiser før brukeren kobler seg på:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

Formålslinjen skal vise SSL client. Avslutt med å oppdatere CA-kopien etter utstedelsen, fordi en kopi som ble tatt før det nye serienummeret ble ført inn, gjenoppretter en tilstand uten enheten du nettopp la til.

Et nybygg er riktig i tre situasjoner: CA-nøkkelen er kompromittert, utstedelsestilstanden er tapt for godt, eller dere bevisst bytter nøkkelalgoritme eller sertifikatpolicy. Alle tre er prosjekter som krever en plan for ny påmelding av hver klient, ikke steg i en forespørsel om én enhet. Gjelder ingen av dem, meld på trinnvis og la utstederen være i fred.