Triemtafterfoegsels bepale gjin kaai-algoritmen, en in .pem-omhulsel kin RSA- of ECDSA-materiaal befetsje. PEM beskriuwt hoe't bytes ferpakt wurde, wylst RSA en ECDSA ferskate algoritmen neame, en in PKCS12-triem is wer in trêde ding. strongSwan laadt bewiisstikken fia plugins en in konfiguraasje-backend, dat in sertifikaat kin yn in list ferskine wylst de partikuliere kaai nea brûkber wurdt. Skied dy lagen foardat jo hokker geheim dan ek bewurkje.

Kodearring, algoritme en ferpakking binne trije lagen

In kaaitriem hat in kodearring, in algoritme en faak in kontener. PEM is it fertroude base64-omhulsel; DER is syn binêre tsjinhinger; PKCS12 bondelt in sertifikaat mei syn kaai en ketting. In sertifikaatkettingtriem is noch in kontener, en dy befettet meastentiids hielendal gjin partikuliere kaai. Gjin fan dy labels seit oft it materiaal binnen RSA of ECDSA is.

Lês it algoritme út it objekt sels. De marketingnamme fan in leveransier of in triemtafterfoegsel is gjin bewiis, want deselde útjouwer kin ferskate kaaisoarten leverje.

Fergelykje iepenbiere kaaien foardat jo de lader de skuld jouwe

In sertifikaat dat laadt, bewiist dat it sertifikaat parsd is, net dat syn partikuliere kaai oanwêzich of brûkber is. Lied de iepenbiere kaai ôf út it sertifikaat en út 'e foarstelde partikuliere kaai, en fergelykje dan de twa hashes. As ien fan 'e ekstraksjes mislearret, stopje dêr, want in hash fan lege útfier bewiist neat. Oerienkommende hashes bewiise dat it pear byinoar heart, en neat mear oer oft it sertifikaat by de taak past.

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

It twadde kommando rekket partikulier materiaal op jo masine oan mar jout allinnich de iepenbiere helte út. Hâld it sa, en plakje nea in partikuliere kaai yn in ticket. As de kaai fersifere is, lit it stipe helpmiddel dan om de wachtwurdsin freegje ynstee fan it op in kommandorigel te setten dêr't de prosessenlist it bleatstelle kin.

Legere ipsec.secrets of swanctl-bewiisstikken

strongSwan hat twa faak brûkte bewiisstikpaden. De âlde starter-stapel lêst typespesifike ynfieringen út ipsec.secrets, en elke ynfiering moat it juste type foar it materiaal neame. De swanctl- en vici-stapel laadt kaaien út syn eigen bewiisstikmap fia syn eigen konfiguraasje. It bewurkjen fan 'e triem dy't de rinnende backend net lêst, feroaret neat.

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

Fyn út hokker backend echt rint, en pleats de kaai dan dêr't dy backend sjocht. âlde hânlieding fan strongSwan 5.9 beskriuwt de typespesifike geheimynfieringen, en it is gjin swanctl-dokumintaasje. It mingen fan beide makket in daemon dy't in triem negearret dy't de behearder as gesachhawwend beskôget. In werlading dy't gjin flater rapportearret, betsjut allinnich dat de konfiguraasje parsd is.

Lês it laadbarren en it autentikaasjerêsultaat

Lês nei in beheinde werlading de eigen laadútfier fan 'e daemon foar de spesifike kaai. In sertifikaat dat yn in statusdump neamd wurdt, lit net sjen dat de partikuliere kaai dêrmei matche waard.

As in klant noch altyd mislearret, hâld it tsjinnerbarren en de klantflater apart. Kettingfalidaasje, identiteitsmatching en metoadekompatibiliteit binne lettere fragen mei har eigen bewiis. Skriuw de útkomst del mei it krekte kaaispaad en de hash dy't jo fergelike hawwe, want oars werhellet de folgjende ploech deselde werlading. It ferfangen fan 'e CA is net de earste reaksje op in laderôfwiking.

Relatearre artikelen