Offentlig nøkkelinfrastruktur (PKI) er en metode for å validere ektheten av en ellers ukjent enhet på tvers av uklarerte nettverk. PKI fungerer med å etablere en tillitskjede, i stedet for å stole på hver enkelt vert eller enhet eksplisitt. For å få et sertifikat presentert av en fjern enhet som skal stoles på, må sertifikatet presentere en komplett kjede av sertifikater som kan valideres ved hjelp av rotsertifikatet til en Sertifiseringsinstans (CA) som er klarert av den lokale maskinen.
Å etablere tillit med en CA innebærer å validere ting som selskap adresse, eierskap, kontaktinformasjon osv., og sikre at CA har fulgt beste praksis, som å gjennomgå periodiske sikkerhetsrevisjoner av uavhengige etterforskere og opprettholde en alltid tilgjengelig sertifikatopphevelsesliste. Dette er godt utenfor omfanget av BLFS (som det er for de fleste Linux distribusjoner). Sertifikatlageret som oppgis her er hentet fra Mozilla Foundation, som har etablert svært strenge retningslinjer for inkludering beskrevet her.
Denne pakken er kjent for å bygge og fungere riktig ved å bruke en LFS 12.2 plattform.
Nedlasting (HTTP): https://github.com/lfs-book/make-ca/archive/v1.14/make-ca-1.14.tar.gz
Nedlastingsstørrelse: 40 KB
Nedlasting MD5 Sum: e99d2985ead0037caedb765fd66b33f0
Estimert diskplass som kreves: 164 KB (med alle kjøretidsdeps)
Estimert byggetid: 0.1 SBU (med alle kjøretidsdeps)
Denne pakken sender et CA sertifikat for å validere identiteten
til https://hg.mozilla.org/. Hvis
tillitskjeden til denne nettsiden har blitt endret etter
utgivelsen av make-ca-1.14, det kan mislykkes å få revisjonen av
certdata.txt
fra serveren. Bruk en
oppdatert make-ca utgivelse på the release
page hvis dette problemet oppstår.
p11-kit-0.25.5 (kjøretid, bygget etter libtasn1-4.19.0, kreves i de følgende instruksjoner for å generere sertifikatlagre fra tillitsankere, og hver gang make-ca kjøres)
nss-3.103 (å generere en delt NSSDB)
make-ca skriptet vil laste ned og
behandle sertifikatene som er inkludert i certdata.txt
filen til bruk som tillitsankere for
p11-kit-0.25.5 tillitsmodulen. I tillegg vil
den generere systemsertifikatlagre som brukes av BLFS applikasjoner
(hvis de anbefalte og valgfrie applikasjonene finnes på systemet).
Eventuelle lokale sertifikater lagret i /etc/ssl/local
vil bli importert til både
tillitsankere og de genererte sertifikatlagrene (overstyrer
Mozillas tillit). I tillegg vil eventuelle modifiserte
tillitsverdier bli kopiert fra tillitsankere til /etc/ssl/local
før evt oppdateringer, som bevarer
tilpassede tillitsverdier som er forskjellige fra Mozilla når det
brukes trust verktøy
fra p11-kit for å operere på
tillitslageret.
For å installere de forskjellige sertifikatlagrene, installer først
make-ca skriptet til riktig
plassering. Som root
bruker:
make install && install -vdm755 /etc/ssl/local
Teknisk sett er denne pakken allerede installert på dette tidspunktet. Men de fleste pakker som lister make-ca som en avhengighet krever faktisk at systemsertifikatlageret er satt opp av denne pakken, heller enn make-ca programmet i seg selv. Så instruksjonene for å bruke make-ca for å sette opp systemsertifikatlageret er inkludert i denne delen. Du bør sørge for at nødvendige kjøretidsavhengighet for make-ca er tilfredstilt nå, og fortsett å følge instruksjonene.
Som root
bruker, last ned
sertifikatkilden og klargjør for systembruk med følgende kommando:
Hvis du kjører skriptet en gang til med samme versjon av
certdata.txt
, for eksempel for å
oppdatere lagre når make-ca er
oppgradert, eller for å legge til flere lagre etter hvert som den
nødvendige programvaren er installert, erstatt -g
bryteren med -r
bryter i kommandolinjen. Hvis
innpakning, kjør make-ca
--help for å se alle tilgjengelige kommandoers
linjealternativer.
/usr/sbin/make-ca -g
Du bør periodisk oppdatere lagrene med kommandoen ovenfor, enten
manuelt eller via en systemd timer. En timer
er installert i /usr/lib/systemd/system/update-pki.timer
det,
hvis aktivert, vil se etter oppdateringer ukentlig.
Kjør følgende kommandoer, som
root
bruker, for å aktiver systemd timer:
systemctl enable update-pki.timer
For de fleste brukere er ingen ekstra konfigurasjon nødvendig, men
standard certdata.txt
filen levert av
make-ca er hentet fra mozilla-release grenen, og er modifisert for
å gi en Mercurial revisjon. Dette vil være riktig versjon for de
fleste systemer. Det er flere andre varianter av filen tilgjengelig
for bruk som kan foretrekkes av en eller annen grunn, inkludert
filene som leveres med Mozilla produkter i denne boken. RedHat og
OpenSUSE, for eksempel, bruker versjonen inkludert i nss-3.103. Ytterligere
oppstrømsnedlastinger er tilgjengelig på lenkene som er inkludert i
/etc/make-ca/make-ca.conf.dist
. Bare
kopier filen til /etc/make-ca.conf
og
rediger etter behov.
Det er tre tillitstyper som er anerkjent av make-ca skriptet, SSL/TLS, S/Mime, og code
signing. For OpenSSL, er disse
serverAuth
, emailProtection
, og codeSigning
henholdsvis. Hvis en av
de tre tillitsargumentene er utelatt, er sertifikatet verken
klarert, eller avvist for den rollen. Klienter som bruker
OpenSSL eller NSS som støter på dette sertifikatet vil gi en
advarsel til brukeren. Klienter som bruker GnuTLS uten p11-kit støtte er ikke klar over klarerte
sertifikater. For å inkludere denne CA i ca-bundle.crt
, email-ca-bundle.crt
, eller objsign-ca-bundle.crt
filer (GnuTLS gamle pakker), den må ha passende
tillitsargumenter.
/etc/ssl/local
mappen er tilgjengelig
for å legge til flere CA sertifikater til systemtillitslageret.
Denne katalogen brukes også til å lagre sertifikater som ble lagt
til eller endret i systemtillitslageret av p11-kit-0.25.5 sånn at
tillitsverdier opprettholdes på tvers av oppgraderinger. Filer i
denne mappen må være i OpenSSL
klarert sertifikatformat. Sertifikater importert ved hjelp av
trust verktøyet fra
p11-kit-0.25.5 vil bruke x509 Extended Key
Usage verdiene for å tildele standard tillitsverdier for
systemankrene.
Hvis du trenger å overstyre tillitsverdier, eller på annen måte
trenger å opprette et OpenSSL
klarert sertifikat manuelt fra en vanlig PEM kodet fil, må du legge
til tillitsargumenter til openssl kommandoen, og opprette
et nytt sertifikat. For eksempel ved å bruke CAcert roots, hvis du vil stole på
begge for alle tre rollene, følgende kommandoer vil opprette
passende OpenSSL klarerte sertifikater (kjør som root
etter at Wget-1.24.5 er
installert):
wget http://www.cacert.org/certs/root.crt && wget http://www.cacert.org/certs/class3.crt && openssl x509 -in root.crt -text -fingerprint -setalias "CAcert Class 1 root" \ -addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \ > /etc/ssl/local/CAcert_Class_1_root.pem && openssl x509 -in class3.crt -text -fingerprint -setalias "CAcert Class 3 root" \ -addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \ > /etc/ssl/local/CAcert_Class_3_root.pem && /usr/sbin/make-ca -r
Noen ganger kan det være tilfeller der du ikke er enig med Mozillas
inkludering av en bestemt sertifiseringsinstans. Hvis du vil
overstyre standardtilliten til en bestemt CA, lag ganske enkelt en
kopi av det eksisterende sertifikatet i /etc/ssl/local
med ulik tillitsargumenter. For
eksempel, hvis du ønsker å mistro "Makebelieve_CA_Root" filen, kjør
følgende kommandoer:
openssl x509 -in /etc/ssl/certs/Makebelieve_CA_Root.pem \ -text \ -fingerprint \ -setalias "Disabled Makebelieve CA Root" \ -addreject serverAuth \ -addreject emailProtection \ -addreject codeSigning \ > /etc/ssl/local/Disabled_Makebelieve_CA_Root.pem && /usr/sbin/make-ca -r
Når Python3 ble installert i LFS, inkluderte det pip3 modulen med forhandlersertifikater fra Certifi modulen. Det var nødvendig, men det betyr at når som helst pip3 brukes kan den referere til disse sertifikatene, først og fremst når du oppretter et virtuelt miljø eller når installere en modul med alle dens wheel avhengigheter på en gang.
Det anses generelt at systemadministratoren bør være ansvarlig for hvilke sertifikater som er tilgjengelige. Nå som make-ca-1.14 og p11-kit-0.25.5 har blitt installert og make-ca er konfigurert, er det mulig å få pip3 til å bruke systemsertifikatene.
Sertifikatene som er installert i LFS er et øyeblikksbilde fra når en trukket inn versjon av Certifi ble laget. Hvis du regelmessig oppdaterer systemsertifikatene, vil leverandørversjonen bli utdatert.
For å bruke systemsertifikatene i Python3, bør du sette _PIP_STANDALONE_CERT
til å peke på dem, f.eks for
bash skallet:
export _PIP_STANDALONE_CERT=/etc/pki/tls/certs/ca-bundle.crt
Hvis du har laget virtuelle miljøer, for eksempel når du tester
moduler, og de inkluderer Requests og Certifi moduler i ~/.local/lib/python3.12/
, da vil de lokale
modulene bli brukt i stedet for systemsertifikatene med mindre du
fjerner de lokale modulene.
For å bruke systemsertifikatene i Python3 med BLFS profilene, legg til følgende variabel til systemet eller personlig profil:
mkdir -pv /etc/profile.d &&
cat > /etc/profile.d/pythoncerts.sh << "EOF"
# Begin /etc/profile.d/pythoncerts.sh
export _PIP_STANDALONE_CERT=/etc/pki/tls/certs/ca-bundle.crt
# End /etc/profile.d/pythoncerts.sh
EOF