strongSwan: ŝlosila tipo, ŝargilo kaj la malĝusta backend

PEM estas ujo, ne ŝlosila tipo. Komparu la publikan ŝlosilon de la atestilo kun la privata, poste ŝargu ĝin per la backend, kiu reale legas ĝin.

Dosieraj finaĵoj ne identigas ŝlosilajn algoritmojn, kaj .pem-ujo povas enhavi RSA- aŭ ECDSA-materialon. PEM priskribas, kiel bajtoj estas pakitaj, dum RSA kaj ECDSA nomas malsamajn algoritmojn, kaj PKCS12-dosiero estas tria afero. strongSwan ŝargas akreditaĵojn per kromaĵoj kaj agorda backend, do atestilo povas aperi en listo dum la privata ŝlosilo neniam fariĝas uzebla. Apartigu tiujn tavolojn antaŭ ol redakti ajnan sekreton.

Kodigo, algoritmo kaj pakaĵo estas tri tavoloj

Ŝlosila dosiero havas kodon, algoritmon kaj ofte ujon. PEM estas la konata base64-ujo; DER estas ĝia binara ekvivalento; PKCS12 kunigas atestilon kun ĝia ŝlosilo kaj ĉeno. Atestila ĉena dosiero estas ankoraŭ alia ujo, kaj ĝi kutime enhavas neniun privatan ŝlosilon. Neniu el tiuj etikedoj diras, ĉu la materialo interne estas RSA aŭ ECDSA.

Legu la algoritmon el la objekto mem. La merkatnomo de provizanto aŭ dosiera finaĵo ne estas pruvo, ĉar la sama eldonanto povas doni malsamajn ŝlosilajn tipojn.

Komparu publikajn ŝlosilojn antaŭ ol kulpigi la ŝargilon

Atestilo, kiu ŝargiĝas, pruvas, ke la atestilo estis analizita, ne ke ĝia privata ŝlosilo ĉeestas aŭ estas uzebla. Derivu la publikan ŝlosilon el la atestilo kaj el la proponita privata ŝlosilo, poste komparu la du haŝojn. Se iu eltiro malsukcesas, haltu tie, ĉar haŝo de malplena eligo pruvas nenion. Kongruaj haŝoj pruvas, ke la paro apartenas kune, kaj nenion pli pri tio, ĉu la atestilo taŭgas por la tasko.

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

La dua komando tuŝas privatan materialon sur via maŝino sed eligas nur la publikan duonon. Tenu ĝin tiel, kaj neniam algluu privatan ŝlosilon en bileton. Se la ŝlosilo estas ĉifrita, lasu la subtenatan ilon peti la pasfrazon anstataŭ meti ĝin sur komandlinion, kie la proceza listo povas malkaŝi ĝin.

Malnovaj ipsec.secrets aŭ swanctl-akreditaĵoj

strongSwan havas du ofte uzatajn akreditaĵajn vojojn. La malnova starter-stako legas tipspecifajn enskribojn el ipsec.secrets, kaj ĉiu enskribo devas nomi la ĝustan tipon por la materialo. La stako swanctl kaj vici ŝargas ŝlosilojn el sia propra akreditaĵa dosierujo per sia propra agordo. Redakti la dosieron, kiun la kuranta backend ne legas, ŝanĝas nenion.

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

Trovu, kiu backend fakte funkcias, poste metu la ŝlosilon tie, kie tiu backend rigardas. malnova manlibro de strongSwan 5.9 difinas la tipspecifajn sekretajn enskribojn, kaj ĝi ne estas swanctl-dokumentaro. Miksi la du kreas demonon, kiu ignoras dosieron, kiun la administranto kredas aŭtoritata. Reŝargo, kiu raportas neniun eraron, nur signifas, ke la agordo estis analizita.

Legu la ŝargan eventon kaj la aŭtentikigan rezulton

Post kontrolita reŝargo, legu la propran ŝargan eligon de la demono por la koncerna ŝlosilo. Atestilo listigita en statusa eligo ne montras, ke la privata ŝlosilo estis parigita al ĝi.

Se kliento ankoraŭ malsukcesas, tenu la servilan eventon kaj la klientan eraron aparte. Ĉena validigo, identeca kongruigo kaj metoda kongruo estas postaj demandoj kun propraj pruvoj. Skribu la rezulton kun la preciza ŝlosila vojo kaj la haŝo, kiun vi komparis, ĉar alie la sekva skipo ripetos la saman reŝargon. Anstataŭigi la CA ne estas la unua respondo al ŝargila miskongruo.

Rilataj artikoloj