strongSwan: tipo de clave, cargador e o backend equivocado

PEM é un contedor, non un tipo de clave. Compare a clave pública do certificado coa privada e despois cárguea mediante o backend que realmente a le.

As extensións de ficheiro non identifican algoritmos de clave, e un sobre .pem pode conter material RSA ou ECDSA. PEM describe como se envolven os bytes, mentres que RSA e ECDSA nomean algoritmos distintos, e un ficheiro PKCS12 é unha terceira cousa. strongSwan carga as credenciais mediante complementos e un backend de configuración, así que un certificado pode aparecer nunha lista mentres a clave privada nunca chega a ser utilizábel. Separe esas capas antes de editar calquera segredo.

Codificación, algoritmo e empaquetado son tres capas

Un ficheiro de clave ten unha codificación, un algoritmo e a miúdo un contedor. PEM é o sobre base64 familiar; DER é a súa contraparte binaria; PKCS12 agrupa un certificado coa súa clave e a súa cadea. Un ficheiro de cadea de certificados é outro contedor máis e normalmente non contén ningunha clave privada. Ningunha desas etiquetas di se o material interior é RSA ou ECDSA.

Lea o algoritmo do propio obxecto. O nome comercial dun provedor ou unha extensión de ficheiro non son proba, porque o mesmo emisor pode entregar tipos de clave distintos.

Compare as claves públicas antes de culpar o cargador

Un certificado que carga demostra que o certificado se analizou, non que a súa clave privada estea presente ou sexa utilizábel. Derive a clave pública do certificado e da clave privada proposta, e despois compare os dous resumos. Se calquera das extraccións falla, detéñase aí, porque o resumo dunha saída baleira non demostra nada. Os resumos coincidentes demostran que o par se corresponde, e nada máis sobre se o certificado serve para o traballo.

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

O segundo comando toca material privado na súa máquina pero só emite a metade pública. Mantéñao así e nunca pegue unha clave privada nun ticket. Se a clave está cifrada, deixe que a ferramenta compatible solicite o contrasinal en lugar de poñelo nunha liña de comandos onde a lista de procesos poida expoñelo.

ipsec.secrets herdado ou credenciais de swanctl

strongSwan ten dúas rutas de credenciais de uso común. A pila starter herdada le as entradas específicas de tipo desde ipsec.secrets, e cada entrada debe indicar o tipo correcto para o material. A pila swanctl e vici carga claves desde o seu propio directorio de credenciais mediante a súa propia configuración. Editar o ficheiro que o backend en execución non le non cambia nada.

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

Averigüe que backend se executa realmente e despois coloque a clave onde ese backend mira. manual herdado de strongSwan 5.9 define as entradas de segredos específicas de tipo, e non é documentación de swanctl. Mesturar ambas produce un daemon que ignora un ficheiro que o administrador cre autoritativo. Unha recarga que non informa ningún erro só significa que a configuración se analizou.

Lea o evento de carga e o resultado de autenticación

Tras unha recarga controlada, lea a saída de carga do propio daemon para a clave concreta. Un certificado listado nun volcado de estado non mostra que a clave privada se emparellase con el.

Se un cliente segue fallando, manteña separados o evento do servidor e o erro do cliente. A validación da cadea, a coincidencia de identidades e a compatibilidade de métodos son cuestións posteriores coas súas propias probas. Anote o resultado coa ruta exacta da clave e o resumo que comparou, porque o seguinte quenda repetirá a mesma recarga se non. Substituír a CA non é a primeira resposta a unha discrepancia do cargador.

Artigos relacionados