strongSwan: sleuteltipe, laaier en die verkeerde backend

Lêeruitbreidings dui nie sleutelalgoritmes aan nie, en 'n .pem-omhulsel kan RSA- of ECDSA-materiaal bevat. PEM beskryf hoe grepe verpak word, terwyl RSA en ECDSA verskillende algoritmes aandui, en 'n PKCS12-lêer is weer iets anders. strongSwan laai geloofsbriewe deur plugins en 'n konfigurasie-backend, dus kan 'n sertifikaat in 'n lys verskyn terwyl die private sleutel nooit bruikbaar word nie. Skei daardie lae voordat jy enige geheim wysig.

Enkodering, algoritme en verpakking is drie lae

'n Sleutellêer het 'n enkodering, 'n algoritme en dikwels 'n houer. PEM is die bekende base64-omhulsel; DER is sy binêre eweknie; PKCS12 bundel 'n sertifikaat saam met sy sleutel en ketting. 'n Sertifikaatkettinglêer is nog 'n houer, en dit bevat gewoonlik glad geen private sleutel nie. Nie een van daardie etikette sê of die materiaal binne RSA of ECDSA is nie.

Lees die algoritme uit die objek self. 'n Verskaffer se bemarkingsnaam of 'n lêeruitbreiding is nie bewys nie, want dieselfde uitreiker kan verskillende sleuteltipes uitreik.

Vergelyk publieke sleutels voordat jy die laaier blameer

'n Sertifikaat wat laai, bewys dat die sertifikaat geparseer is, nie dat sy private sleutel teenwoordig of bruikbaar is nie. Lei die publieke sleutel af uit die sertifikaat en uit die voorgestelde private sleutel, en vergelyk dan die twee hashwaardes. As enige onttrekking misluk, stop daar, want 'n hashwaarde van leë uitvoer bewys niks. Ooreenstemmende hashwaardes bewys dat die paar bymekaar hoort, en niks meer oor of die sertifikaat by die taak pas nie.

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

Die tweede opdrag raak private materiaal op jou masjien, maar lewer slegs die publieke helfte. Hou dit so, en plak nooit 'n private sleutel in 'n kaartjie nie. As die sleutel geënkripteer is, laat die ondersteunde gereedskap vir die wagwoord vra eerder as om dit op 'n opdragreël te sit waar die proseslys dit kan blootstel.

Erfenis-ipsec.secrets of swanctl-geloofsbriewe

strongSwan het twee geloofsbriefroetes in algemene gebruik. Die ou starter-stapel lees tipspesifieke inskrywings uit ipsec.secrets, en elke inskrywing moet die regte tipe vir die materiaal noem. Die swanctl- en vici-stapel laai sleutels uit sy eie geloofsbriefgids deur sy eie konfigurasie. Om die lêer te wysig wat die lopende backend nie lees nie, verander niks.

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

Vind watter backend werklik loop, en plaas dan die sleutel waar daardie backend kyk. Die strongSwan 5.9-erfenishandleiding definieer die tipspesifieke geheiminskrywings, en dit is nie swanctl-dokumentasie nie. Om die twee te meng lewer 'n daemon wat 'n lêer ignoreer wat die administrateur as gesaghebbend beskou. 'n Herlaai wat geen fout rapporteer nie, beteken net dat die konfigurasie geparseer is.

Lees die laaigebeurtenis en die outentiseringsuitslag

Lees ná 'n beheerde herlaai die daemon se eie laai-uitvoer vir die spesifieke sleutel. 'n Sertifikaat wat in 'n statuslys verskyn, wys nie dat die private sleutel daarby gepas is nie.

As 'n kliënt steeds misluk, hou die bedienergebeurtenis en die kliëntfout apart. Kettingvalidering, identiteitspassing en metodeversoenbaarheid is later vrae met hul eie bewyse. Skryf die uitkoms neer met die presiese sleutelpad en die hashwaarde wat jy vergelyk het, want die volgende skof sal andersins dieselfde herlaai herhaal. Om die CA te vervang is nie die eerste reaksie op 'n laaierwanpassing nie.