strongSwan: lloji i çelësit, ngarkuesi dhe backend-i i gabuar

Zgjerimet e skedarëve nuk identifikojnë algoritmet e çelësave, dhe një zarf .pem mund të përmbajë material RSA ose ECDSA. PEM përshkruan si paketohen bajtët, ndërsa RSA dhe ECDSA emërtojnë algoritme të ndryshme, dhe një skedar PKCS12 është një gjë e tretë. strongSwan ngarkon kredencialet përmes shtojcave dhe një backend konfigurimi, kështu që një certifikatë mund të shfaqet në një listë ndërsa çelësi privat nuk bëhet kurrë i përdorshëm. Ndani ato shtresa përpara se të modifikoni çdo sekret.

Kodimi, algoritmi dhe paketimi janë tre shtresa

Një skedar çelësi ka një kodim, një algoritëm dhe shpesh një kontejner. PEM është zarfi i njohur base64; DER është homologu i tij binare; PKCS12 bashkon një certifikatë me çelësin dhe zinxhirin e saj. Skedari i zinxhirit të certifikatave është një kontejner tjetër dhe zakonisht nuk përmban asnjë çelës privat. Asnjë prej këtyre etiketave nuk thotë nëse materiali brenda është RSA ose ECDSA.

Lexoni algoritmin nga vetë objekti. Emri i marketingut i një furnizuesi ose një zgjerim skedari nuk janë provë, sepse i njëjti lëshues mund të japë lloje të ndryshme çelësash.

Krahasoni çelësat publikë përpara se të fajësoni ngarkuesin

Një certifikatë që ngarkohet provon që certifikata u analizua, jo që çelësi i saj privat është i pranishëm ose i përdorshëm. Nxirrni çelësin publik nga certifikata dhe nga çelësi privat i propozuar, më pas krahasoni dy përmbledhjet. Nëse çdo nxjerrje dështon, ndaloni atje, sepse përmbledhja e një daljeje bosh nuk provon asgjë. Përmbledhjet që përputhen provojnë që çifti i përket njëri-tjetrit, dhe asgjë më shumë rreth asaj nëse certifikata i përshtatet punës.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

Komanda e dytë prek material privat në makinën tuaj por nxjerr vetëm gjysmën publike. Mbani kështu, dhe kurrë mos ngjitni një çelës privat në një tiketë. Nëse çelësi është i kriptuar, lëreni mjetin e mbështetur të kërkojë frazën e kalimit në vend që ta vendosni në një rresht komande ku lista e proceseve mund ta ekspozojë.

ipsec.secrets i vjetër ose kredencialet swanctl

strongSwan ka dy shtigje kredencialesh të përdorura zakonisht. Staku i vjetër starter lexon hyrjet specifike për llojin nga ipsec.secrets, dhe çdo hyrje duhet të emërtojë llojin e duhur për materialin. Staku swanctl dhe vici ngarkon çelësat nga drejtoria e tij e kredencialeve përmes konfigurimit të tij. Modifikimi i skedarit që backend-i në punë nuk e lexon nuk ndryshon asgjë.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Zbuloni cili backend po punon vërtet, më pas vendosni çelësin atje ku ai backend shikon. manual i vjetër strongSwan 5.9 përcakton hyrjet e sekreteve specifike për llojin, dhe ky nuk është dokumentacion swanctl. Përzierja e të dyjave prodhon një daemon që injoron një skedar që administratori e konsideron autoritativ. Një ringarkim që nuk raporton gabim do të thotë vetëm që konfigurimi u analizua.

Lexoni ngjarjen e ngarkimit dhe rezultatin e autentikimit

Pas një ringarkimi të kontrolluar, lexoni daljen e ngarkimit të vetë daemon-it për çelësin konkret. Një certifikatë e listuar në një dump statusi nuk tregon që çelësi privat u përputh me të.

Nëse një klient ende dështon, mbani ngjarjen e serverit dhe gabimin e klientit të ndara. Validimi i zinxhirit, përputhja e identitetit dhe përputhshmëria e metodave janë pyetje të mëvonshme me provat e tyre. Shkruani rezultatin me shtegun e saktë të çelësit dhe përmbledhjen që krahasuat, sepse përndryshe ndërrimi tjetër do të përsëritë të njëjtin ringarkim. Zëvendësimi i CA nuk është reagimi i parë ndaj një mospërputhjeje të ngarkuesit.