O que o seu cliente VPN verifica antes de confiar num certificado

O seu cliente VPN diz que o certificado não pôde ser verificado, e a caixa de diálogo termina aí. O ficheiro está lá, o servidor está ativo, e o mesmo perfil funcionou noutro portátil no mês passado. Por baixo desse aviso de uma linha, o cliente passou o certificado do par por quatro portões: uma autoridade de certificação que configurou garante o caminho da assinatura, esse caminho chega à autoridade, o nome do par é o que pediu, e o certificado é utilizável agora para este propósito. Encontre o portão que se fechou e a reparação costuma ser um ficheiro; salte esse passo e vai reimportar pacotes toda a tarde.

Leia a caixa de diálogo antes de editar o perfil

Os erros de certificado são formulados pela biblioteca por baixo, não pelo produto VPN que instalou, por isso a cadeia exata é a sua primeira prova. «Não é possível obter o certificado do emitente local» aponta para o caminho ou para a âncora de confiança. «O certificado expirou ou ainda não é válido» aponta para o tempo. «Propósito do certificado não suportado» aponta para o uso estendido da chave. Uma divergência de nome diz-lhe que nome era pretendido. Nenhum dos quatro se repara reinstalando o cliente.

Aumente o nível de registo antes de mudar o que quer que seja. OpenVPN comunica a falha de verificação em torno do aperto de mão quando o executa com --verb 4, e o strongSwan escreve as suas decisões de identidade e de cadeia no registo charon. Depois confirme que certificado está a inspecionar, porque as pessoas testam rotineiramente o ficheiro no disco enquanto o perfil incorpora uma cópia mais antiga. Quando o perfil incorpora blocos PEM, o certificado incorporado é o que está em teste.

Uma autoridade de certificação assina identidades, não permissões

A autoridade detém um nome e uma chave de assinatura. Emite certificados que ligam uma chave pública a esse nome segundo a sua própria política, com uma janela de validade e restrições de uso anexadas. O seu cliente só precisa do certificado da autoridade para reconhecer o emitente; nunca precisa da chave de assinatura, e enviar essa chave aos clientes dar-lhes-ia a capacidade de cunhar qualquer identidade em que a implementação confie.

Confiar numa autoridade torna candidato todo o certificado que assinou, não o par correto. Um certificado de servidor web da mesma AC interna também é candidato. É por isso que existem os portões de nome e propósito, e por isso uma chave de AC comprometida pesa mais do que qualquer servidor isolado: alcança cada identidade que a autoridade alguma vez emitiu. Distribua certificados de cliente por dispositivo, para que um portátil perdido seja uma revogação e não uma regeneração de chaves em toda a implementação.

Reconstrua o caminho que o cliente está a tentar construir

O caminho vai do certificado do par, através de zero ou mais intermédios, até uma raiz no seu armazenamento de confiança. Um intermédio em falta é a falha de cadeia mais comum, e do lado do cliente parece idêntico a uma raiz não fidedigna. Leia primeiro a folha e depois deixe o OpenSSL construir o caminho com o material que pretende enviar.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Um estado de saída zero significa que o caminho foi construído a partir desses ficheiros; uma falha nomeia o certificado que não conseguiu alcançar. Se o openssl verify tiver êxito enquanto o cliente continua a recusar, a diferença está no que o servidor envia realmente ou em que ficheiro de confiança o perfil carrega. No OpenVPN, os intermédios podem viajar com o ficheiro do certificado do servidor ou ser fornecidos em separado com --extra-certs, e um pacote com duas raízes escritas sob o mesmo nome de sujeito enviará um dos seus clientes pelo ramo errado.

Nome e propósito são portões separados

A construção da cadeia nunca pergunta se o nome é seu. O OpenVPN só o verifica quando o perfil define --verify-x509-name, e o velho hábito de comparar apenas o nome comum quebra em certificados cujas identidades vivem em subjectAltName. As implementações IKEv2 comparam a identidade configurada com as entradas SAN ou com o nome distinto, conforme o cliente, e um valor wildcard ou %any desativa silenciosamente a comparação que julgava ter.

A seguir vêm o tempo e o propósito. Um portátil cujo relógio está algumas horas adiantado rejeita um certificado que ainda não é válido, e um intermédio expirado faz falhar o caminho enquanto a folha está válida. As falhas de propósito vêm de um certificado sem serverAuth no uso estendido da chave, ou com um keyUsage que não permite a assinatura do aperto de mão, que o OpenSSL comunica como propósito de certificado não suportado. Reemita a partir do modelo correto; nada nessa mensagem é razão para desativar a verificação.

A revogação só funciona se alguém a configurou

Uma CRL ou uma resposta OCSP não são consultadas automaticamente. Num servidor OpenVPN, os certificados de cliente só são comparados com uma lista quando --crl-verify aponta para uma. A verificação do certificado do servidor do lado do cliente depende da implementação e frequentemente está ausente. O strongSwan precisa do seu plugin de revogação e de uma política antes de olhar para uma CRL de um par.

Isso explica o ticket que acabará por receber: um certificado de cliente revogado continua a ligar-se, e todos concluem que a revogação está avariada. Nada estava a verificar. Publique e atualize a CRL, ou mantenha os certificados de cliente suficientemente efémeros para que uma revogação desatualizada conte pouco tempo, e ensaie o caminho de revogação num certificado de laboratório antes de precisar dele durante um incidente.

Uma ordem de reparação que mantém a verificação ligada

Ordene por sintoma antes de tocar nos ficheiros, porque cada linha da tabela o envia para um objeto diferente.

Percorra a lista de uma só vez: confirme o ficheiro que o perfil carrega, construa o caminho você mesmo, verifique se o servidor envia o intermédio, compare o relógio, leia o SAN, leia o EKU, e depois reconecte e veja a mesma linha de registo desaparecer. Se a um dispositivo não se pode dar nenhuma AC, o pinning é a alternativa honesta, porque o OpenVPN 2.6 aceita --peer-fingerprint e restringe a confiança a uma chave em vez de remover a verificação. RFC 5280 é a referência para o significado de cada um desses campos.