strongSwan: tipo de chave, carregador e o backend errado

PEM é um contêiner, não um tipo de chave. Compare a chave pública do certificado com a privada e depois carregue-a pelo backend que realmente a lê.

As extensões de ficheiro não identificam algoritmos de chave, e um envelope .pem pode conter material RSA ou ECDSA. O PEM descreve como os bytes são empacotados, enquanto RSA e ECDSA designam algoritmos diferentes, e um ficheiro PKCS12 é uma terceira coisa. O strongSwan carrega credenciais através de plugins e de um backend de configuração, pelo que um certificado pode aparecer numa lista enquanto a chave privada nunca se torna utilizável. Separe essas camadas antes de editar qualquer segredo.

Codificação, algoritmo e empacotamento são três camadas

Um ficheiro de chave tem uma codificação, um algoritmo e muitas vezes um contêiner. O PEM é o conhecido envelope base64; o DER é a sua contraparte binária; o PKCS12 agrupa um certificado com a sua chave e cadeia. Um ficheiro de cadeia de certificados é mais um contêiner, e normalmente não contém qualquer chave privada. Nenhum desses rótulos diz se o material lá dentro é RSA ou ECDSA.

Leia o algoritmo do próprio objeto. O nome comercial de um fornecedor ou uma extensão de ficheiro não são prova, porque o mesmo emissor pode emitir tipos de chave diferentes.

Compare as chaves públicas antes de culpar o carregador

Um certificado que carrega prova que o certificado foi analisado, não que a sua chave privada esteja presente ou seja utilizável. Derive a chave pública do certificado e da chave privada proposta, e depois compare os dois resumos. Se qualquer extração falhar, pare aí, porque o resumo de uma saída vazia não prova nada. Resumos coincidentes provam que o par se corresponde, e nada mais sobre se o certificado serve para o trabalho.

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 em material privado na sua máquina mas emite apenas a metade pública. Mantenha-o assim e nunca cole uma chave privada num ticket. Se a chave estiver cifrada, deixe a ferramenta suportada pedir a frase-passe em vez de a colocar numa linha de comandos onde a lista de processos a possa expor.

ipsec.secrets antigo ou credenciais swanctl

O strongSwan tem dois caminhos de credenciais habitualmente usados. A pilha starter antiga lê entradas específicas do tipo a partir de ipsec.secrets, e cada entrada tem de indicar o tipo correto para o material. A pilha swanctl e vici carrega chaves do seu próprio diretório de credenciais através da sua própria configuração. Editar o ficheiro que o backend em execução não lê não muda nada.

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

Descubra qual backend está realmente em execução e depois coloque a chave onde esse backend olha. manual antigo do strongSwan 5.9 define as entradas de segredos específicas do tipo, e não é documentação do swanctl. Misturar as duas coisas produz um daemon que ignora um ficheiro que o administrador considera autoritativo. Um recarregamento que não reporta erros significa apenas que a configuração foi analisada.

Leia o evento de carregamento e o resultado da autenticação

Após um recarregamento controlado, leia a saída de carregamento do próprio daemon para a chave concreta. Um certificado listado num dump de estado não mostra que a chave privada tenha sido emparelhada com ele.

Se um cliente continuar a falhar, mantenha o evento do servidor e o erro do cliente separados. A validação da cadeia, a correspondência de identidades e a compatibilidade de métodos são questões posteriores com as suas próprias provas. Anote o resultado com o caminho exato da chave e o resumo que comparou, porque o turno seguinte repetirá o mesmo recarregamento caso contrário. Substituir a CA não é a primeira resposta a uma discrepância do carregador.

Artigos relacionados