Android IKEv2-vertrouensfout: stuur die intermediere CA, nie ’n wortel nie

Die selfoon weier om te koppel en druk No trusted RSA public key found for vpn.example.net, terwyl dieselfde gateway-sertifikaat van ’n skootrekenaar op dieselfde netwerk af werk. Die versoeking is om die sertifikaat opnuut uit te reik. Voordat jy dit doen, bepaal watter van drie foute jy het, want net een daarvan gaan oor die sertifikaat se inhoud. Die boodskap dek ’n onvolledige ketting, ’n identiteitsbotsing en ’n ongesteunde sleutel of handtekening, en elkeen het ’n ander herstel.

Drie foute agter een boodskap

Android bou ’n ketting van die gateway-sertifikaat na die CA wat in die VPN-profiel gekies is, en vergelyk dan die bedienernaam met die profiel. Die kennisgewing meld die uitkoms, nie die stadium nie. ’n Vertrouensfout beteken die ketting kon nie voltooi word met die sertifikate wat in die uitruiling gestuur is nie; ’n identiteitsfout beteken die ketting is geldig maar die naam stem nie ooreen nie; ’n algoritmefout beteken die toestel of profiel aanvaar nie die sleuteltipe of die handtekening nie.

Bespreek met bewyse eerder as om herstellings in volgorde te probeer. Een poging teen logvlak 2 op die daemon sê vir jou in watter ry jy is, en dit kos minder as om ’n sertifikaat te heruit te reik wat nooit verkeerd was nie.

Bepaal eers: het die hele ketting aangekom?

strongSwan stuur die sertifikaat wat vir daardie verbinding opgestel is, en intermediere sertifikate is aparte geloofsbriewe. Hulle moet as CA-sertifikate gelaai word voordat die daemon hulle in ’n las kan plaas, so ’n uitleg waar die bedienersertifikaat deur ’n intermediere een onderteken is, die wortel die vertrouensanker is en die intermediere sertifikaat net in die CA se bougids leef, lewer presies hierdie fout: die blaar alleen op die draad en die ketting wat vroeg op die selfoon eindig.

Kontroleer wat die daemon hou met swanctl --list-certs op ’n swanctl-ontplooiing, of ipsec listcerts met die ouer starter. Die intermediere sertifikaat behoort as ’n CA-sertifikaat te verskyn met die wortel daarbo. As dit ontbreek, sal geen kliëntopsie help nie; as dit daar is, gaan aan na die volgende vraag.

Kyk dan of dit gestuur sou word. Die swanctl.conf-verwysing dokumenteer send_cert, waarvan die verstek ifasked sertifikate net stuur wanneer die eweknie gevra het, terwyl always ongeag stuur. Die ou ekwivalent is leftsendcert=always in ipsec.conf. Daardie instelling beheer stuur, nie beskikbaarheid nie, so dit kan nie ’n intermediere sertifikaat vergoed wat die daemon nooit gelaai het nie.

As die ketting kort is, laai die intermediere sertifikaat waar die daemon soek

Plaas die intermediere sertifikaat in die CA-gids eerder as langs die blaar: /etc/ipsec.d/cacerts vir ’n opstelling met ipsec.conf, /etc/swanctl/x509ca vir swanctl, of die pad wat jou pakket vervang. Laai die opstelling weer en lys die sertifikate opnuut. Sommige weergawes stuur ook ’n bondel wat die ketting in die blaar-lêer bevat, maar die CA-gids is die oordraagbare reëling oor weergawes en pakkette.

Verifieer ook van die kliëntkant. Die selfoon sien net wat die uitruiling gedra het, so die daemon-log op vlak 2 behoort die intermediere sertifikaat in die gestuurde sertifikate te wys. As die log dit wys en die selfoon faal steeds, is jy in ’n ander ry van die tabel, en om CA-lêers aan te pas sal die uitkoms nie verander nie.

As die ketting volledig is, stop om sertifikate te wysig

’n Identiteitsfout is ’n verskil tussen die naam in die VPN-profiel en die naam in die sertifikaat. Android vergelyk die bedieneridentiteit wat jy opgestel het met die sertifikaat wat dit gevalideer het, so ’n profiel wat na ’n adres wys terwyl die sertifikaat ’n hostnaam noem, of ’n profiel met ’n hostnaam wat die sertifikaat nie dek nie, faal ná suksesvolle kettingvalidasie. Maak die verkeerde kant reg en hou profiel en sertifikaat in lyn wanneer een van hulle verander.

’n Algoritmefout verskyn met ’n geldige ketting en ’n ooreenstemmende naam. Android-weergawes verskil in watter sleuteltipes en handtekeningskemas hulle aanvaar, en die profieltipo self beperk die opsies. As die gateway ’n ouer of ongewone kombinasie gebruik, vergelyk dit met wat die toestel ondersteun voordat jy aanvaar die sertifikaat is beskadig. Die daemon-log sal wys die handdruk vorder verder as in die vertrouensgeval, wat die teken is dat die ketting nie meer die probleem is nie.

Moenie die intermediere sertifikaat as ’n gebruiker-wortel op die selfoon installeer nie

Om die ontbrekende intermediere sertifikaat as ’n gebruikersertifikaat op die selfoon te installeer, laat die waarskuwing verdwyn en verander die selfoon se vertrouensmodel vir elke app wat gebruiker-geïnstalleerde wortels aanvaar. Dit verberg ook ’n afleweringsfout wat die volgende kliënt sal tref, en dit laat die gateway ’n onvolledige ketting aan elke toekomstige toestel stuur. Die blywende herstelling is by die bediener, een keer, vir alle kliënte.

Hou die drie besluite apart in die veranderingsrekord: watter sertifikate gestuur is, watter identiteit vergelyk is en watter algoritme onderhandel is. ’n Gateway wat altyd sy volle ketting stuur, ’n profiel wat die sertifikaat korrek noem en ’n sleuteltipe wat die vloot ondersteun is drie klein feite, en hulle is die hele fout.