strongSwan send_cert: quando o certificado IKE é enviado

Os gateways registam falhas de autenticação relacionadas com certificados, e o primeiro impulso é adicionar outra CA ao recetor. Isso pressupõe que o certificado chegou e foi rejeitado. A outra possibilidade é nunca ter sido enviado, e isso é decidido pela política de ligação do emissor. Determine qual dos dois casos ocorreu antes de mexer na confiança.

O que o send_cert controla na prática

A autenticação por certificado exige que o certificado de entidade final do peer chegue ao outro lado através da troca IKE ou de um aprovisionamento prévio. No swanctl, a definição da ligação send_cert determina se este extremo inclui a sua carga de certificado: nunca, sempre ou ifasked. O valor predefinido ifasked envia-o em resposta a um pedido de certificado do peer. Pedir um certificado é uma definição separada, porque pedir ao outro lado o seu certificado não é o mesmo que oferecer o próprio.

Implementações mais antigas de ipsec.conf usavam leftsendcert e rightsendcert, e esses nomes correspondem às funções local e remota, não diretamente ao swanctl.

Leia uma tentativa antes de alterar a ligação

Diagnostique a partir de uma única tentativa controlada, não da impressão geral de que há certificados envolvidos. Tanto a política como a associação ativa podem ser inspecionadas.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

A lista de ligações mostra o valor configurado de send_cert, e a lista de SA mostra que ligações chegaram realmente a estabelecer-se. O registo acrescenta detalhes da negociação: se foi recebido um pedido de certificado e se saiu uma carga de certificado. Uma falha de autenticação genérica não identifica um problema de entrega, por isso procure a troca concreta antes de concluir algo. Anote o carimbo temporal da tentativa para que a janela do registo cubra todo o handshake.

A confiança do recetor é uma decisão separada

Entrega e confiança são propriedades diferentes, e corrigir uma não corrige a outra. Um recetor tem de possuir a âncora de confiança pretendida, receber uma cadeia utilizável e corresponder à identidade esperada do peer. Um certificado de entidade final que chega sem o seu intermédio continua a falhar uma verificação rigorosa da cadeia. Por outro lado, instalar uma CA não obriga de modo algum um peer a enviar o seu certificado.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

A inspeção mostra que emissor assinou o certificado e quando expira, e é a isso que a âncora do recetor tem de corresponder. Confie na CA emissora que a implementação possui, não em cada intermédio da cadeia, porque promover cada intermédio a raiz alarga a confiança muito além de um único peer. Mantenha a verificação de identidade ativa, pois uma ligação que só funciona com a validação desativada não é uma correção. Onde a cadeia está incompleta, repare o aprovisionamento em vez da política do emissor.

Altere o emissor apenas com provas

Quando o registo mostra que o certificado nunca foi enviado e que o recetor o pediu de facto, colocar send_cert em always é uma alteração justificada para essa ligação. Aplique-a na configuração do swanctl, recarregue as ligações e estabeleça uma sessão nova em vez de reutilizar a SA existente. Confirme que a carga do certificado aparece agora e que o recetor a aceita face à âncora pretendida. Se nada mudar, a falha estava afinal do lado da confiança e a definição do emissor não era a causa.

Escreva a troca observada, a âncora e a verificação resultante no registo de alterações. Uma correção de certificado que não possa ser descrita nesses termos é uma coincidência.