CA com assinatura cruzada: a chave coincide, a ligação AKI não

Dois certificados CA podem ter a mesma chave pública e o mesmo sujeito e mesmo assim não ser intercambiáveis. Um é autoassinado, o outro é assinado em cruz pela raiz antiga, e os nomes de emitente, números de série e assinaturas diferem. Uma folha pode ligar-se especificamente a um deles através do seu Authority Key Identifier. Essa ligação permanece invisível até um cliente escolher a cadeia errada e o handshake falhar sem motivo evidente.

Executa estas cinco verificações por ordem: cada uma exclui uma falha diferente.

Verificação 1: desenha as duas cadeias antes de tocar no modelo

Anota os percursos. A população antiga confia na Raiz antiga A, que emitiu a CA B, que emitiu a folha do servidor. A população nova confia diretamente na CA B autoassinada. Ambos os certificados B levam a mesma chave e o mesmo sujeito, e é exatamente por isso que quem lê uma linha de sujeito vê uma CA onde o cliente vê duas.

A cópia com assinatura cruzada também tem de ser um certificado CA real, com basic constraints e key usage que permitam assinar.

Verificação 2: compara os campos AKI, não apenas a chave

O nome do emitente da folha tem de corresponder ao sujeito de B, e essa parte costuma verificar-se. O Authority Key Identifier é onde as duas cópias divergem, porque pode levar um identificador de chave, um emitente de certificado e um número de série. O identificador de chave corresponde a ambas as cópias, uma vez que a chave é idêntica. Os campos de emitente e série correspondem exatamente a uma, e por isso uma cadeia construída contra a cópia autoassinada pode falhar contra a assinada em cruz.

Inspeciona a folha em vez de adivinhar: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Depois compara os dois candidatos com openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", e o mesmo comando contra a cópia autoassinada.

Se a folha leva emitente e número de série, só o certificado que esses valores descrevem completa a cadeia, seja qual for a cópia que o cliente carregou.

Verificação 3: muda a política de emissão, nunca os bytes assinados

As extensões vivem dentro da assinatura. Acrescentar, remover ou editar uma numa folha existente não é uma reparação, é outro certificado e exige reemissão. A mudança pertence à política de emissão: authorityKeyIdentifier = keyid,issuer:always faz com que as folhas novas levem a ligação específica do certificado, enquanto keyid sozinho mantém a forma mais frouxa que convém a uma transição deliberada de assinatura cruzada. Decide qual quer a tua PKI antes de o lote seguinte ser assinado.

Editar um modelo partilhado também altera todos os certificados futuros, não apenas o servidor à tua frente.

Verificação 4: verifica cada população de confiança separadamente

Testa o percurso antigo e o novo como execuções separadas. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem exercita a rota com assinatura cruzada, e o mesmo comando com a raiz nova e sem ficheiro untrusted exercita a rota autoassinada. Misturar as duas raízes num só pacote esconde que cadeia foi selecionada. Repete depois com clientes reais, porque um backend VPN pode preferir uma cadeia ou fixar um certificado de formas que o openssl não faz.

Entrega o certificado intermédio através da configuração de serviço que o cliente realmente lê, não através de uma página wiki.

Verificação 5: mantém o percurso antigo num relógio de retirada

A assinatura cruzada mantém vivo por desenho um percurso de confiança antigo, o que é ao mesmo tempo o objetivo e o risco. Não corrige uma raiz antiga comprometida nem remove essa raiz de nenhum cliente. Anota quando o percurso antigo deixa de conceder confiança, e confirma que esse dia chega mesmo.

Se todos os clientes conseguirem aceitar a raiz nova antes de as folhas se moverem, uma implantação simples de dupla confiança é mais simples do que a assinatura cruzada, e deixa uma coisa menos para retirar.