IKEv2-sertifikaat en SAN: wêrom't de identiteitskontrôle mislearret

Jo sertifikaatketting giet nei in fertroude CA, de datums binne goed, en de peer wegert noch altyd om faze 1 te foltôgjen mei in identiteitsflater. Berikberens en in jildige hantekening binne mar de helte fan wat in IKEv2-klant kontrolearret. De oare helte is oft de identiteit dy't er ferwachtet yn it sertifikaat yn it goede fjild stiet, en dy ferwachting wurdt troch it profyl bepaald, net troch de bestânsnamme fan it sertifikaat.

It symptoom hat altyd deselde foarm

In ferbiningsprofyl wurdt fan in hostnamme nei in IP-adres feroare, of fernijd fan in sertifikaat mei in DNS-namme nei ien dat allinnich adressen draacht, en de tunnel stopet mei ûnderhanneljen. Der is neat op it netwurkpaad feroare. De klant berikt de peer, ûntfangt in sertifikaat en wiist de identiteit fan de peer ôf, om't de identifikaasje dy't er ferwachtsje moast net fertsjintwurdige is yn in fjild dat er akseptearret. Fernijingen binne de gewoane oanlieding, om't it ferfangende sertifikaat faak út in oar sjabloan komt as datjinge dat it ferfangt.

Dêrnei logge beide kanten eat nutteleas, wêrtroch't de flater meastentiids as in sertifikaatprobleem rapportearre wurdt. It klantlog kin de identiteit neame dy't it woe, en dy namme is it oanwizing dy't jo sykje, net de ferfaldatum.

Keppelje it type identifikaasje, net allinnich de wearde

In dNSName-SAN en in iPAddress-SAN binne ferskillende fjilden mei ferskillende oerienkomingsregels, dus in sertifikaat dat 203.0.113.10 as DNS-string draacht, foldocht net oan in klant dy't in IP-identiteit ferwachtet. Moderne falidearders negearje de mienskiplike namme foar in grut part, dus it freonlike label yn 'e sertifikaatdetails bewissiget neat oer wat oerienkomme sil. As in hostnamme by it oplossen fan problemen troch in adres ferfongen waard, nim dan oan dat de ferwachte identiteit dermei ferhuze is oant jo it kontrolearre hawwe. Fergelykje de string yn it profyl mei de string yn 'e SAN teken foar teken, want in punt oan 'e ein of in oerstallich spasje is genôch.

Jokertekens binne in gemak allinnich foar DNS en folgje har eigen oerienkomingsregels, wat noch in reden is wêrom't in profyl op basis fan IP nea op har fertrouwe moat.

Fyn wêr't elke klant de ferwachting bewarret

Yn strongSwan komt de wearde dy't mei it sertifikaat ferlike wurdt út 'e ynstelling foar peer-identiteit: rightid yn 'e klassike konfiguraasje, of de id fan in seksje foar fiere ferbining yn swanctl. De dokumintaasje oer Apple IKEv2-ynteroperabiliteit is hjir nuttich, om't dy de identiteitskonvinsjes útlizt dy't in profylstjoerde klant brûkt, en dy konvinsjes ferklearje in klasse fan misferhâldingen dy't op it netwurk tafallich lykje.

Apple-konfiguraasjeprofylen drage in fjild foar fiere identifikaasje, en de wearde dêr is wat de klant kontrolearret, net it serveradres yn 'e ferbiningsynstellingen. Windows- en apparaatklanten hawwe elk har eigen fjild mei har eigen standertwearde, en de standert folget faak it adres dat jo yntypen hawwe. As twa fjilden ferskille, wint it fjild dat de klant echt lêst, en dat is selden it fjild dat jo bewurke hawwe.

Reparearje it profyl of it sertifikaat bewust

Ynspektearje it sertifikaat fan de peer mei goedkarde ark en list de SAN-ynfieringen mei har typen op foardat jo eat feroarje. Dy ynspeksje freget gjin priveekaai en gjin upload, en besljochtet de fraach yn sekonden. As de ynset ien DNS-identiteit bedoelt, moat it sertifikaat dy as dNSName-ynfiering drage, en as it in adres bedoelt, hat it sertifikaat in iPAddress-ynfiering nedich foar krekt dat adres.

As it sertifikaat ferkeard is, freegje de operator dan om in ferbettere ien mei de spesifike ferwachte identifikaasje. As it profyl ferkeard is, reparearje it profyl en lit it sertifikaat gewurde. It útskeakeljen fan identiteitsfalidaasje lit de flater ferdwine en hellet de kontrôle wei dat de tunnel mei de bedoelde peer praat.

Dokumintearje de ferwachte identiteit per klantplatfoarm, om't in wearde dy't ien klant automatysk ôfliedt op in oar miskien eksplisyt wêze moat.

Jou de fernijingsoanfraach fjouwer feiten

Skriuw de ferwachte identifikaasje en it type derfan op, de SAN-ynfieringen dy't it hjoeddeiske sertifikaat echt hat, de klant en ferzje dy't de kontrôle dogge, en de krekte flatertekst. In fernijingsoanfraach boud fan dy fjouwer rigels krijt de earste kear it goede sertifikaat, ynstee fan noch ien mei deselde bekende bestânsnamme.