strongSwan send_cert: milloin IKE-varmente lähetetään

Yhdyskäytävät kirjaavat varmenteisiin liittyviä todennusvirheitä, ja ensimmäinen ajatus on lisätä vastaanottajalle vielä yksi CA. Se olettaa, että varmenne saapui ja hylättiin. Toinen mahdollisuus on, ettei sitä koskaan lähetetty, ja sen ratkaisee lähettäjän yhteyden käytäntö. Selvitä, kumpi kahdesta tapahtui, ennen kuin muutat luottamusta.

Mitä send_cert todella ohjaa

Varmennetodennus vaatii, että vertaiskoneen loppuolion varmenne saavuttaa toisen osapuolen IKE-vaihdon tai aiemman käyttöönoton kautta. swanctlissa yhteyden asetus send_cert määrää, sisällyttääkö tämä päätepiste varmennehyötykuormansa: ei koskaan, aina tai ifasked. Oletus ifasked lähettää sen vastauksena vertaiskoneen varmentepyyntöön. Varmenteen pyytäminen on erillinen asetus, sillä toiselta osapuolelta sen varmenteen pyytäminen ei ole sama asia kuin oman tarjoaminen.

Vanhemmat ipsec.conf-asennukset käyttivät leftsendcert ja rightsendcert -asetuksia, ja nämä nimet vastaavat paikallisia ja etärooleja eivätkä suoraan swanctlia.

Lue yksi yritys ennen yhteyden muuttamista

Tee diagnoosi yhdestä kontrolloidusta yrityksestä, ei yleisestä vaikutelmasta, että varmenteet ovat mukana. Sekä käytäntö että aktiivinen assosiaatio ovat tarkasteltavissa.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

Yhteysluettelo näyttää määritetyn send_cert-arvon, ja SA-luettelo näyttää, mitkä yhteydet todella muodostuivat. Loki lisää neuvottelun yksityiskohdat: vastaanotettiinko varmentepyyntö ja lähtikö varmennehyötykuorma. Yleinen todennusvirhe ei osoita toimitushäiriötä, joten etsi kyseinen vaihto ennen kuin päättelet mitään. Kirjaa yrityksen aikaleima, jotta loki-ikkuna kattaa koko kättelyn.

Vastaanottajan luottamus on erillinen päätös

Toimitus ja luottamus ovat eri ominaisuuksia, eikä toisen korjaaminen korjaa toista. Vastaanottajalla on oltava aiottu luottamusankkuri, saatava käyttökelpoinen ketju ja vastattava odotettua vertaiskoneen identiteettiä. Loppuolion varmenne, joka saapuu ilman välivarmennettaan, epäonnistuu silti tiukassa ketjutarkistuksessa. Toisaalta CA:n asentaminen ei pakota vertaiskonetta lähettämään varmennettaan lainkaan.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

Tarkastus näyttää, mikä myöntäjä allekirjoitti varmenteen ja milloin se vanhenee, ja sitä vastaanottajan ankkurin on vastattava. Luota käyttöönoton omistamaan myöntävään CA:han, älä jokaiseen ketjun välivarmenneeseen, sillä jokaisen välivarmenteen korottaminen juureksi laajentaa luottamusta paljon kauemmas kuin yhteen vertaiskoneeseen. Pidä identiteetin vahvistus käytössä, sillä yhteys, joka onnistuu vain validointi pois päältä, ei ole korjaus. Jos ketju on puutteellinen, korjaa käyttöönotto eikä lähettäjän käytäntöä.

Muuta lähettäjää vain todisteilla

Kun loki osoittaa, ettei varmennetta koskaan lähetetty ja vastaanottaja kuitenkin pyysi sitä, send_cert-asetus always on perusteltu muutos kyseiselle yhteydelle. Ota se käyttöön swanctl-määrityksessä, lataa yhteydet uudelleen ja muodosta uusi istunto sen sijaan, että käyttäisit olemassa olevaa SA:ta uudelleen. Vahvista, että varmennehyötykuorma nyt näkyy ja että vastaanottaja hyväksyy sen aiottua ankkuria vasten. Jos mikään ei muutu, vika oli kuitenkin luottamuspuolella eikä lähettäjän asetus ollut syy.

Kirjaa havaittu vaihto, ankkuri ja siitä seuraava vahvistus muutosrekisteriin. Varmenteen korjaus, jota ei voi kuvata noilla termeillä, on sattumaa.