strongSwan: tipo de clave, cargador y el backend equivocado

Las extensiones de archivo no identifican algoritmos de clave, y un sobre .pem puede contener material RSA o ECDSA. PEM describe cómo se envuelven los bytes, mientras que RSA y ECDSA nombran algoritmos distintos, y un archivo PKCS12 es una tercera cosa. strongSwan carga las credenciales mediante complementos y un backend de configuración, así que un certificado puede aparecer en una lista mientras la clave privada nunca llega a ser utilizable. Separe esas capas antes de editar cualquier secreto.

Codificación, algoritmo y empaquetado son tres capas

Un archivo de clave tiene una codificación, un algoritmo y a menudo un contenedor. PEM es el sobre base64 conocido; DER es su contraparte binaria; PKCS12 agrupa un certificado con su clave y su cadena. Un archivo de cadena de certificados es otro contenedor más y normalmente no contiene ninguna clave privada. Ninguna de esas etiquetas dice si el material interior es RSA o ECDSA.

Lea el algoritmo del propio objeto. El nombre comercial de un proveedor o una extensión de archivo no son prueba, porque el mismo emisor puede entregar tipos de clave distintos.

Compare las claves públicas antes de culpar al cargador

Un certificado que carga demuestra que el certificado se analizó, no que su clave privada esté presente o sea utilizable. Derive la clave pública del certificado y de la clave privada propuesta, y luego compare los dos resúmenes. Si alguna de las extracciones falla, deténgase ahí, porque el resumen de una salida vacía no demuestra nada. Los resúmenes coincidentes demuestran que el par se corresponde, y nada más sobre si el certificado sirve para el trabajo.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

El segundo comando toca material privado en su máquina pero emite solo la mitad pública. Manténgalo así y nunca pegue una clave privada en un ticket. Si la clave está cifrada, deje que la herramienta compatible solicite la frase de contraseña en lugar de ponerla en una línea de comandos donde la lista de procesos pueda exponerla.

ipsec.secrets heredado o credenciales de swanctl

strongSwan tiene dos rutas de credenciales de uso común. La pila starter heredada lee las entradas específicas de tipo desde ipsec.secrets, y cada entrada debe indicar el tipo correcto para el material. La pila swanctl y vici carga claves desde su propio directorio de credenciales mediante su propia configuración. Editar el archivo que el backend en ejecución no lee no cambia nada.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Averigüe qué backend se ejecuta realmente y luego coloque la clave donde ese backend mira. manual heredado de strongSwan 5.9 define las entradas de secretos específicas de tipo, y no es documentación de swanctl. Mezclar ambas produce un daemon que ignora un archivo que el administrador cree autoritativo. Una recarga que no informa ningún error solo significa que la configuración se analizó.

Lea el evento de carga y el resultado de autenticación

Tras una recarga controlada, lea la salida de carga del propio daemon para la clave concreta. Un certificado listado en un volcado de estado no muestra que la clave privada se haya emparejado con él.

Si un cliente sigue fallando, mantenga separados el evento del servidor y el error del cliente. La validación de la cadena, la coincidencia de identidades y la compatibilidad de métodos son cuestiones posteriores con sus propias pruebas. Anote el resultado con la ruta exacta de la clave y el resumen que comparó, porque el siguiente turno repetirá la misma recarga si no. Sustituir la CA no es la primera respuesta a una discrepancia del cargador.