Android IKEv2: o certificado de usuario e a CA fan traballos distintos
Un campo demostra quen é o teléfono, o outro decide en que pasarela confiar. O perfil IKEv2 de Android manténos separados.
Unha pantalla IKEv2 de Android que pide á vez un certificado de usuario e un de CA parece pedir o mesmo dúas veces. Non é así. IKEv2 autentica os dous extremos nas dúas direccións dentro dun mesmo intercambio, e o teléfono fai un papel distinto en cada dirección: debe probar quen é e decidir en que pasarela confía. O certificado de usuario responde á primeira pregunta, a CA de confianza á segunda, e ningún substitúe o outro.
Dúas direccións de autenticación nun só intercambio
IKEv2 levanta unha canle de control en dúas fases. A primeira negocia algoritmos e claves; a segunda, IKE_AUTH, leva unha carga AUTH de cada lado xunto coa súa identidade. A carga é unha sinatura ou un MAC sobre o intercambio e vérifícase contra algo en que o receptor xa confía.
A pasarela proba a súa identidade co seu propio certificado, e o teléfono valida a cadea ata unha raíz que acepta e comproba que a identidade do certificado coincide coa pasarela que quería alcanzar; o teléfono proba a súa identidade coas súas credenciais, e a pasarela vérifícaas contra a CA que emitiu o certificado de cliente.
Ese é todo o mecanismo. O certificado de usuario é unha declaración do teléfono sobre si mesmo; o campo CA é unha declaración sobre a quen crerá. Un perfil con un pero non co outro non completa a autenticación mutua e reintentar non o cambia. Os fallos mesmo se ven distintos: sen clave de usuario o teléfono non pode asinar, e sen ancoraxe de confianza non pode aceptar o certificado da pasarela.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Que pide o xerador de perfís de Android
O xerador de perfís IKEv2 de Android expón cada método por separado, non como un único modo de certificado. A sinatura dixital toma un certificado de usuario, unha clave privada e unha CA raíz do servidor; os demais toman usuario e contrasinal, ou unha clave precompartida.
Lea esa sinatura con atención, porque describe o mecanismo anterior. Non hai campo para a clave privada no método de usuario e contrasinal nin ancoraxe de confianza en PSK, porque proban cousas distintas. Pegar un contrasinal nun campo de certificado produce un perfil que falla en IKE_AUTH cunha mensaxe que non nomea ningún dos dous.
O tipo de clave privada documentado para a sinatura dixital é RSA. Un menú etiquetado IPsec ou certificado non implica soporte de ECDSA, e un perfil construído sobre esa suposición falla na API da plataforma antes de que exista rede.
Por que non abonda un certificado de usuario público
A carga AUTH é unha sinatura sobre o intercambio feita coa clave privada do cliente. O certificado público permite á pasarela comprobar unha sinatura, pero non fai nada polo teléfono, que necesita a clave para xerala. Importar só .crt e deixar a clave atrás é a forma máis común deste fallo.
A infraestrutura de claves de Android reflícteo: escoller unha identidade de cliente pasa por KeyChain, que esixe acceso á clave privada correspondente, non só unha entrada de certificado. Un paquete de inscrición ou un fluxo de xestión de dispositivos que instale o par xunto é a vía normal; copiar o ficheiro á man non adoita sero.
Así que os dous elementos non son un lote de certificados e o seu duplicado. Un é un par de claves co que a plataforma debe poder asinar; o outro, unha ancoraxe de confianza coa que compara. Compruébeos como dous feitos separados: pode asinar este perfil e sabe a quen confiar?
As ancoraxes de confianza son da aplicación, non do teléfono
Instalar unha raíz no almacén do usuario non fai que todas as aplicacións confíen nela: desde Android 7 unha app debe optar por iso mediante a súa configuración de seguridade de rede, e antes desa versión as CA instaladas polo usuario aceptábanse moito máis amplamente. A configuración de confianza varía e un cliente VPN que xestiona o seu propio material pode non mirar nunca o almacén. Por iso o mesmo ficheiro de CA funciona nun cliente e parece ignorado noutro.
Hai dous modelos. Un perfil xestionado polo sistema usa a instalación de certificados do dispositivo ou a alta de administrador e despois referencia a CA prevista. Un VPN xestionado pola aplicación garda o seu propio material e a súa propia importación documentada, que pode estar separada dos axustes de Android. Alí tamén se repara unha cadea rota.
Decida en que modelo está antes de importar nada e confirme despois a selección de confianza do perfil activo. Se as instrucións do operador e o menú do cliente non coinciden, para esa instalación gaña o comportamento documentado do cliente, pero a CA debe seguir vindo do operador por unha canle verificable. O nome dun ficheiro non proba quen o emitiu.
Escolla o modo e logo os ficheiros
O modo certificado necesita un par de claves de cliente, a CA emisora no lado da pasarela, unha ancoraxe de confianza para o certificado da pasarela e unha expectativa de que identidade debe levar. Usuario e contrasinal substitúen o par por credenciais pero manteñen a confianza na pasarela. PSK substitúe ambos por un segredo compartido e cambia o modelo de confianza en vez de simplificalo.
Escolla o que escolla, manteña a validación normal activada. Unha opción de non verificar elimina a comprobación para a que existe o campo CA; non arranxa unha ancoraxe ausente. O mesmo vale para aceptar calquera certificado de servidor porque a conexión funcione sen el.
Despois verifique no lugar correcto: importe o material, conecte unha vez e confirme nos detalles que a identidade da pasarela é a esperada e que o perfil informa do método que pretendía. Unha conexión correcta co método equivocado é unha configuración que aínda non entende e fallará cando o operador endureza unha política.