Android IKEv2 грешка во довербата: пратете средно CA, а не коренско
Телефонот го одбива порталот бидејќи синџирот што го доби завршува прерано. Одлучете: да го пратите средното, да го поправите идентитетот или да го смените типот на клучот.
Телефонот одбива да се поврзе и печати No trusted RSA public key found for vpn.example.net, додека истиот сертификат на порталот работи од преносен компјутер на истата мрежа. Примамливиот потег е повторно издавање на сертификатот. Пред да го направите тоа, утврдете која од трите грешки ја имате, бидејќи само една од нив е за содржината на сертификатот. Пораката опфаќа нецелосен синџир, несовпаѓање на идентитетот и неподдржан клуч или потпис, и секоја има различно решение.
Три грешки зад една порака
Android гради синџир од сертификатот на порталот до CA избрано во VPN профилот, потоа го проверува името на серверот спрема профилот. Известувањето го соопштува исходот, не фазата. Грешка во довербата значи дека синџирот не можел да се заврши од сертификатите доставени во размената; грешка во идентитетот значи дека синџирот е валидиран, но името не се совпаѓа; грешка во алгоритмот значи дека уредот или профилот не го прифаќа типот на клуч или потписот.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
Одлучете врз основа на докази, наместо да ги пробувате поправките по ред. Еден обид со ниво на дневник 2 кон демонот ви кажува во кој ред сте, и чини помалку од повторно издавање на сертификат што никогаш не бил погрешен.
Прво одлучете: дали пристигна целиот синџир?
strongSwan го праќа сертификатот конфигуриран за таа врска, а средните сертификати се одделни акредитиви. Тие мора да се вчитаат како CA сертификати пред демонот да може да ги стави во товар, затоа распоредот каде серверскиот сертификат е потпишан од среден сертификат, коренот е сидро на доверба, а средниот сертификат живее само во градниот директориум на CA, го произведува токму овој неуспех: само листот на жицата, синџирот завршува рано на телефонот.
Проверете што држи демонот со swanctl --list-certs на swanctl распоред или ipsec listcerts со постариот starter. Средниот сертификат треба да се појави како CA сертификат со коренот над него. Ако недостасува, ниту една клиентска опција не помага; ако е присутен, преминете на следното прашање.
Потоа проверете дали ќе биде пратен. swanctl.conf референцата го документира send_cert, чија стандардна вредност ifasked праќа сертификати само кога партнерот побарал; always праќа секогаш. Стариот еквивалент е leftsendcert=always во ipsec.conf. Оваа поставка го контролира праќањето, не достапноста, па не може да го надомести средниот сертификат што демонот никогаш не го вчитал.
Ако синџирот е краток, вчитајте го средниот сертификат каде што бара демонот
Ставете го средниот сертификат во директориумот за CA, а не покрај листот: /etc/ipsec.d/cacerts за ipsec.conf поставка, /etc/swanctl/x509ca за swanctl, или патеката што ја заменува вашиот пакет. Вчитајте ја конфигурацијата повторно и повторно наведете ги сертификатите. Некои верзии праќаат и пакет што го содржи синџирот во датотеката на листот, но директориумот за CA е преносливо решение низ верзии и пакети.
Проверете и од клиентската страна. Телефонот гледа само што пренесла размената, па дневникот на демонот на ниво 2 треба да го покаже средниот сертификат во пренесените сертификати. Ако дневникот го покажува, а телефонот сè уште не успева, вие сте во друг ред од табелата, и понатамошното прилагодување на CA-датотеки нема да го промени исходот.
Ако синџирот е целосен, престанете да уредувате сертификати
Грешка во идентитетот е несовпаѓање меѓу името во VPN профилот и името во сертификатот. Android го споредува идентитетот на серверот што сте го конфигурирале со сертификатот што го валидирал, па профил што покажува на адреса додека сертификатот именува име на домаќин, или профил што именува име на домаќин што сертификатот не го покрива, не успева по успешна валидација на синџирот. Поправете ја страната што е погрешна и држете ги профилот и сертификатот усогласени кога една од нив се менува.
Грешка во алгоритмот се појавува со валиден синџир и соодветно име. Изданијата на Android се разликуваат по тоа кои типови клучеви и шеми на потпис ги прифаќаат, а самиот тип на профил ги ограничува опциите. Ако порталот користи постара или невообичаена комбинација, споредете ја со она што уредот го поддржува пред да претпоставите дека сертификатот е оштетен. Дневникот на демонот ќе покаже дека ракувањето напредува подалеку отколку во случајот со доверба, што е сигнал дека синџирот веќе не е проблем.
Не инсталирајте го средниот сертификат како кориснички корен на телефонот
Инсталирањето на средниот сертификат како кориснички сертификат на телефонот го отстранува предупредувањето и го менува моделот на доверба на телефонот за секоја апликација што прифаќа кориснички инсталирани корени. Исто така крие грешка во испораката што ќе го погоди следниот клиент, и го остава порталот да праќа нецелосен синџир на секој иден уред. Трајната поправка е на серверот, еднаш, за сите клиенти.
Држете ги трите одлуки одделно во записот за промени: кои сертификати биле пренесени, кој идентитет бил спореден и кој алгоритам бил договорен. Порталот што секогаш го праќа целиот синџир, профилот што правилно го именува сертификатот и типот на клуч што флотата го поддржува се три мали факти, и тие се целиот овој неуспех.