Public Key Infrastructure (PKI) er en metode for å validere autentisiteten til en ellers ukjent enhet på tvers av upålitelige nettverk. PKI fungerer ved å etablere en tillitskjede, i stedet for å stole eksplisitt på hver enkelt vert eller enhet. For at et sertifikat presentert av en ekstern enhet skal være klarert, 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 firmaadresse, eierskap, kontaktinformasjon osv., og å sikre at CA-en har fulgt beste praksis, som å gjennomgå periodiske sikkerhetsrevisjoner av uavhengige etterforskere og opprettholde en alltid tilgjengelig liste over tilbakekalte sertifikater. Dette er langt utenfor omfanget av BLFS (som det er for de fleste Linux distribusjoner). Sertifikatlageret som er gitt her er hentet fra Mozilla Foundation, som har etablert svært strenge inkluderingsregler beskrevet her.
Denne pakken sender et CA sertifikat for å validere identiteten
til https://hg-edge.mozilla.org/.
Hvis tillitskjeden til dette nettstedet har blitt endret etter
utgivelsen av make-ca-1.16.1, kan det hende at det ikke lykkes å
få revisjonen av certdata.txt
fra
serveren. Bruk en oppdatert make-ca utgivelse på the release
page hvis dette problemet oppstår.
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
tillitsankrene og de genererte sertifikatlagrene (og overstyre
Mozillas tillit). I tillegg vil eventuelle endrede tillitsverdier
bli kopiert fra tillitsankrene til /etc/ssl/local
før noen oppdateringer, som
bevarer tilpassede tillitsverdier som avviker fra Mozilla når du
bruker trust
verktøyet fra p11-kit for å operere på tillitslagret.
Før du installerer pakken, bør du legge til en ekstra instruksjon til make-ca skript som lager en kompatibilitetssymbolsk lenke som brukes av Debian Linux pakker og er påkrevd av Steam-1.0.0.83 ettersom hovedutviklingen skjer på Debian Linux. Legg til instruksjonen i skriptet nå:
cat >> make-ca << "EOF"
ln -svf /etc/pki/tls/certs/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt
EOF
Nå for å installere make-ca skriptet, må det installeres på riktig
sted som root
bruker:
make install && install -vdm755 /etc/ssl/local
Teknisk sett er denne pakken allerede installert på dette tidspunktet. Men de fleste pakkene som lister make-ca som en avhengighet krever faktisk at systemsertifikatlageret er satt opp av denne pakken, i stedet for make-ca programmet i seg selv. Så instruksjonene for å bruke make-ca for å sette opp systemsertifikatets lagre er inkludert i denne delen.
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 å
oppdatere lagret når make-ca oppgraderes, eller å legge til flere
butikker etter hvert som nødvendig programvare installeres,
erstatt -g
bryteren med
-r
bryteren i
kommandolinjen. Hvis du pakker, kjør make-ca --help for å se alle
tilgjengelige kommandolinjealternativer.
/usr/sbin/make-ca -g
For de fleste brukere er ingen ytterligere 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 den
riktige versjonen for de fleste systemer. Det finnes flere andre
varianter av filen tilgjengelig for bruk som kan være foretrukket
av en eller annen grunn, inkludert filene som følger med Mozilla
produkter i denne boken. RedHat og OpenSUSE bruker for eksempel
versjonen som er inkludert i nss-3.115. Ytterligere oppstrøms nedlastinger er
tilgjengelige 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 finnes tre typer tillit som er anerkjent av make-ca skriptet,
SSL/TLS, S/Mime, og codeSigning. For OpenSSL, disse er serverAuth
, emailProtection
, og codeSigning
henholdsvis. Hvis ett av
de tre tillitsargumentene utelates, 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. Klienter som
bruker GnuTLS uten p11-kit støtten er ikke klar over pålitelige
sertifikater. For å inkludere denne CA-en i ca-bundle.crt
, email-ca-bundle.crt
, eller objsign-ca-bundle.crt
filene (GnuTLS legacy
pakker), må den ha hensiktsmessige tillitsargumenter.
/etc/ssl/local
mappen er tilgjengelig
for å legge til flere CA sertifikater i systemets tillitslager.
Denne mappen brukes også til å lagre sertifikater som ble lagt til
eller endret i systemets tillitslager av p11-kit-0.25.5 slik 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 til å tilordne standard tillitsverdier for
systemankrene.
Hvis du trenger å overstyre tillitsverdier, eller på annen måte
trenger å opprette en OpenSSL klarert sertifikat manuelt fra en
vanlig PEM kodet fil, må du legge til tillitsargumenter til
openssl kommandoen,
og opprett et nytt sertifikat. For eksempel, ved å bruke CAcert roots, hvis du vil
stole på begge for alle tre rollene, vil følgende kommandoer
opprette passende OpenSSL klarerte sertifikater (kjør som
root
bruker etter at 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
Av og til kan det være tilfeller der du ikke er enig i Mozillas
inkludering av en bestemt sertifiseringsinstans. Hvis du vil
overstyre standardtilliten til en bestemt CA, kan du ganske enkelt
opprette en kopi av det eksisterende sertifikatet i /etc/ssl/local
med forskjellige
tillitsargumenter. Hvis du for eksempel ikke vil stole på
"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/MLFS, den inkluderte pip3 modulen med leverandørsertifikater fra Certifi modulen. Det var nødvendig, det betyr at når pip3 brukes kan det referere til disse sertifikatene, hovedsakelig når man oppretter et virtuelt miljø eller når man installerer en modul med alle wheel avhengigheter på én gang.
Det er generelt ansett at systemadministratoren bør ha ansvaret for hvilke sertifikater som er tilgjengelige. Nå som make-ca-1.16.1 og p11-kit-0.25.5 har blitt installert og make-ca har blitt konfigurert, er det mulig å gjøre sånn at pip3 bruker systemsertifikatene.
De leverandørsertifikatene som er installert i LFS er et øyeblikksbilde fra da den innhentede versjonen når Certifi ble opprettet. Hvis du regelmessig oppdaterer systemsertifikatene, vil leverandørversjonen bli utdatert.
For å bruke systemsertifikatene i Python3, bør du sette
_PIP_STANDALONE_CERT
å 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 testet
moduler, og disse inkluderer Requests og Certifi moduler i
~/.local/lib/python3.13/
da vil
disse lokale modulene bli brukt i stedet for systemsertifikatene
med mindre du fjerner de lokale modulene.
Sørg nå for at variabelen blir satt ved oppstart ved å opprette
følgende Bash oppstartsfil som root
bruker:
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
Nå henter du hovedprofilen:
source /etc/profile
Hvis du kopierer profilskriptene til et nytt system, må du installere denne pakken før du installerer Python moduler fra noen av LFS bøkene, inkludert denne, slik at sertifikatene pip3 stoler på kan finnes.