strongSwan: nøkkeltype, laster og feil backend

Filendelser identifiserer ikke nøkkelalgoritmer, og en .pem-konvolutt kan inneholde RSA- eller ECDSA-materiale. PEM beskriver hvordan bytes pakkes inn, mens RSA og ECDSA navngir forskjellige algoritmer, og en PKCS12-fil er en tredje ting. strongSwan laster inn legitimasjon gjennom plugins og en konfigurasjonsbackend, så et sertifikat kan vises i en liste mens den private nøkkelen aldri blir brukbar. Skille disse lagene før du redigerer noen hemmelighet.

Koding, algoritme og emballering er tre lag

En nøkkelfil har en koding, en algoritme og ofte en beholder. PEM er den kjente base64-konvolutten; DER er dens binære motstykke; PKCS12 samler et sertifikat med nøkkelen og kjeden. En sertifikatkjede-fil er nok en beholder, og den inneholder vanligvis ingen privat nøkkel i det hele tatt. Ingen av disse betegnelsene forteller om materialet inni er RSA eller ECDSA.

Les algoritmen fra objektet selv. En leverandørs markedsføringsnavn eller en filendelse er ikke bevis, fordi samme utsteder kan utstede forskjellige nøkkeltyper.

Sammenlign offentlige nøkler før du klandrer lasteren

Et sertifikat som lastes inn, beviser at sertifikatet ble parset, ikke at den private nøkkelen finnes eller er brukbar. Utled den offentlige nøkkelen fra sertifikatet og fra den foreslåtte private nøkkelen, og sammenlign deretter de to hash-ene. Hvis en av uttrekkene mislykkes, stopp der, fordi en hash av tom utdata ikke beviser noe. Samsvarende hasher beviser at paret hører sammen, og ikke noe mer om sertifikatet passer til jobben.

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

Den andre kommandoen berører privat materiale på maskinen din, men sender bare ut den offentlige halvdelen. Hold det slik, og lim aldri en privat nøkkel inn i en sak. Hvis nøkkelen er kryptert, la det støttede verktøyet spørre om passordfrasen i stedet for å sette den på en kommandolinje der prosesslisten kan avsløre den.

Eldre ipsec.secrets eller swanctl-legitimasjon

strongSwan har to vanlige legitimasjonsstier. Den eldre starter-stakken leser typerelaterte oppføringer fra ipsec.secrets, og hver oppføring må angi riktig type for materialet. swanctl- og vici-stakken laster nøkler fra sin egen legitimasjonsmappe gjennom sin egen konfigurasjon. Å redigere filen som den kjørende backend-en ikke leser, endrer ingenting.

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

Finn ut hvilken backend som faktisk kjører, og plasser deretter nøkkelen der den backend-en ser. strongSwan 5.9 eldre håndbok definerer de typerelaterte hemmelighetsoppføringene, og det er ikke swanctl-dokumentasjon. Å blande de to gir en daemon som ignorerer en fil som administratoren mener er autoritativ. En omlasting som ikke rapporterer feil, betyr bare at konfigurasjonen ble parset.

Les innlastingshendelsen og autentiseringsresultatet

Etter en kontrollert omlasting, les daemonens egen innlastingsutdata for den aktuelle nøkkelen. Et sertifikat som er oppført i en statusdump, viser ikke at den private nøkkelen ble matchet til det.

Hvis en klient fortsatt feiler, hold serverhendelsen og klientfeilen atskilt. Kjedevalidering, identitetsmatching og metodekompatibilitet er senere spørsmål med sine egne bevis. Skriv ned resultatet med den nøyaktige nøkkelstien og hashen du sammenlignet, fordi neste skift ellers gjentar den samme omlastingen. Å bytte ut CA-en er ikke den første reaksjonen på et misforhold i lasteren.