Hold OpenVPN-CA-ens signeringsnøkkel utenfor /etc/openvpn

To mapper som ser like ut i en veiledning, gjør helt forskjellige jobber. Den ene holder sertifikatmyndigheten: dens private nøkkel, serienummertelleren og oversikten over alt den har signert. Den andre holder det daemonen trenger for å starte og betjene klienter. Å legge begge på samme vert under samme konto er praktisk for en ettermiddag og dyrt resten av utrullingens levetid, fordi daemonen da kjører ved siden av den ene nøkkelen som kan lage hvilken som helst identitet den ønsker.

Hva CA-arbeidsområdet inneholder

En PKI-mappe er utstederens tilstand, ikke konfigurasjon. Den inneholder CA-ens private nøkkel og sertifikat, en serienummerfil, en indeks over utstedte sertifikater og materialet per identitet som er laget fra dem.

Signering av en forespørsel endrer denne tilstanden, og derfor tilhører arbeidsområdet en administratorkontrollert konto på en vert der VPN-tjenesten ikke kjører. Alle som kan lese CA-ens private nøkkel, kan utstede et sertifikat serveren vil stole på, så nøkkelens beskyttelse er hele tillitsmodellen i én fil. Å kopiere den til et andre sted for å spare et trinn skaper en ekstra ting å beskytte og en ekstra ting å glemme. Hver signatur øker også serienummeret og legger til en oppføring i indeksen, og derfor er arbeidsområdet én kopi av tilstand i stedet for en mappe med filer.

CA-ens offentlige sertifikat er annerledes. Det er ment å distribueres, og det er det klienter og servere bruker for å verifisere hverandre.

Hva daemonen leser når den starter

En kjørende server bruker et lite sett: sitt eget sertifikat, sin egen private nøkkel, CA-sertifikatet for å verifisere parter og det nøkkelmaterialet dens valgte modus krever. Den leser disse stiene ved oppstart og igjen ved omlasting.

Eierskap må vurderes mot enheten som faktisk starter, ikke mot et interaktivt root-skall. Deklarert sandkassing kan gjøre deler av filsystemet skrivebeskyttet eller usynlig selv når en manuell test som root lykkes.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

Den tredje linjen er den folk hopper over. Den spør daemonens egen konto om den kan lese nøkkelen, og det er den eneste versjonen av spørsmålet som betyr noe etter at privilegier er droppet. En null-utgang som root sier ingenting om hva som skjer etter droppet.

De to feilveiene er verdt å skille før du endrer noen tillatelse. En signeringsfeil peker på PKI-mappen, søketillatelsen på dens overordnede mapper og kontoen som kjører utstederen. En oppstartsfeil peker på enheten, dens arbeidsmappe og stiene som er navngitt i serverkonfigurasjonen. Å gjøre hele treet lesbart for alle fikser ingen av dem og fjerner grensen begge er avhengige av.

Hvorfor kopiering av CA-nøkkelen til serveren feiler senere

Kopien starter vanligvis som et feilsøkingstrekk: noen vil fornye en klient på VPN-verten, så CA-nøkkelen havner i /etc/openvpn og fornyelsen virker. Den umiddelbare oppgaven lykkes, og grensen er borte.

Så tas det sikkerhetskopi av serveren, og signeringsmyndigheten blir med i kopiene. Et øyeblikksbilde, en støttepakke eller en kopi av konfigurasjonsmappen bærer nå evnen til å utstede betrodde identiteter så lenge CA-en er gyldig. Den som har den kopien, kan lage et sertifikat for ethvert navn serveren godtar, også navn som aldri ble utstedt. Den eneste registreringen av den utstedelsen er den de velger å beholde.

Å komme seg ut av den tilstanden er ikke et spørsmål om å slette en fil. Du må avgjøre om nøkkelen var eksponert, rotere CA-en hvis den var det, og redistribuere tillit til hver part. Et separat arbeidsområde unngår hele samtalen.

Kontoer, mapper, sikkerhetskopier

Gi utstederen sin egen konto og hjemmemappe, holdt borte fra VPN-verten der det er praktisk. Gi daemonen en annen konto, med lesetilgang til det utrullede materialet og skrivetilgang til ingenting som utsteder sertifikater. Rull ut ved å kopiere offentlige sertifikater utover og aldri ved å trekke utstederens private tilstand innover. Ta sikkerhetskopi av de to rollene separat, fordi deres følsomhet og gjenopprettingshistorier er forskjellige.

Etter en tilbakekalling, oppdater CRL-filen som serverkonfigurasjonen navngir, og last deretter tjenesten på nytt slik at nye tilkoblinger leser den. Easy-RSA-dokumentasjonen dekker arbeidsområdets oppbygning og signeringsflyten; eierskapsreglene rundt det er fortsatt en beslutning om verten din. Bekreft hva tjenesten lastet med openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate i stedet for å anta at omlastingen tok den med.

En test som beviser delingen

Kontroller det negative tilfellet, ikke bare det som virker. Signer et sertifikat fra utstederkontoen som designet, og bekreft deretter at samme konto ikke kan starte tjenesten eller lese serverens private nøkkel. Bekreft deretter at daemonens konto ikke kan lese CA-ens private nøkkel.

De tre kontrollene tar noen minutter og overlever personalendringer, fordi de er utsagn om tillatelser og ikke om vane. Skriv ned resultatet med stiene og kontoene det dekket, pluss datoen du kjørte dem. Den neste som arver denne utrullingen vil ellers utlede grensen på nytt fra en veiledning som aldri hadde en. En datert registrering er også det som gjør neste gjennomgang til minutter i stedet for en ettermiddag.