Erro de certificado web no Access Server: o pacote CA vazio

Uma página de login web que não carrega enquanto o DNS resolve corretamente não é, normalmente, um problema de DNS. Se o log do serviço mencionar um caminho vazio do pacote de certificados ou uma falha de análise PEM do certificado web e da chave privada, o listener HTTPS não tem material utilizável e nenhuma resolução de nomes ajuda. A reparação está em três chaves de configuração e não exige reemitir um único certificado de cliente VPN.

Para onde as três chaves apontam

O conjunto personalizado de certificados web é descrito por cs.cert, cs.priv_key e cs.ca_bundle. Cada uma guarda um caminho para um arquivo e o serviço web consome as três em conjunto. Um certificado com a chave errada, ou um arquivo de cadeia que na verdade é o certificado folha, falha como um valor vazio.

Estas chaves pertencem à interface web de Admin e de Client. Estão separadas da PKI que emite certificados aos clientes da VPN, então a substituição não obriga a tocar nos perfis, na chave do servidor ou na autoridade de certificação. Reconstruir toda a PKI é o erro mais caro aqui.

Uma distinção poupa tempo: um valor personalizado explicitamente vazio não é o mesmo estado que não ter qualquer substituição. O primeiro entrega ao analisador um caminho vazio, é o que diz a linha de log. O segundo deixa o Access Server com o seu próprio material.

Por que um arquivo existente não é analisado

O analisador lê os blocos etiquetados dentro do arquivo, não o nome do arquivo. Um .crt que contém uma chave privada, uma cadeia escrita como um único bloco, ou um arquivo salvo com a última linha truncada são rejeitados. O RFC 7468 define essas etiquetas legíveis porque são a única coisa que diz ao leitor que tipo de objeto vem a seguir.

Examine os objetos, não as extensões. Em um host Linux, openssl x509 -noout -subject -issuer -in server.pem e openssl pkey -noout -check -in key.pem respondem às duas perguntas que importam, e comparar o módulo ou a chave pública de ambos prova que eles se pertencem. Mantenha a saída da chave privada fora de tickets e logs de conversa.

Um caminho vazio merece a mesma suspeita que um arquivo malformado, porque ambos produzem erros posteriores vagos. Se o log disser que o caminho do pacote está vazio, leia o valor guardado antes de depurar o arquivo.

Voltar ao recurso de reserva de propósito

A CLI do Access Server inclui uma validação que recebe os três caminhos como argumentos e indica se o conjunto é utilizável. Os caminhos abaixo são ilustrativos; substitua-os pelas localizações protegidas no host.

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Leia o resultado antes de tocar no serviço em execução e só depois importe os valores e aplique-os através da operação documentada para a versão instalada. O tutorial oficial da CLI cobre a validação, a importação e o passo de aplicação, e a sua versão importa mais do que qualquer resumo.

Verifique o nome que os usuários realmente digitam

Quando o material personalizado está avariado e ainda existe uma reserva integrada válida, a recuperação documentada é remover as três substituições e deixar o Access Server usar essa reserva. Garanta primeiro o acesso ao console e uma cópia da configuração atual.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Apagar toda a base de dados de configuração não é uma reparação de certificado. Aponte às três chaves, aplique e confirme que a interface web responde. Os arquivos autoassinados no diretório web-ssl são o recurso de reserva, não um espaço de trabalho.

Espere que o navegador mostre um certificado diferente depois de a reserva entrar em vigor. É o resultado correto; verifique-o através do seu processo administrativo de confiança.

A recuperação termina com um login bem-sucedido

A recuperação não termina quando surge um listener TCP. Valide o nome DNS, a identidade do certificado e a cadeia para esse nome, depois carregue as interfaces web de Admin e de Client e conclua um login. Uma verificação de porta não prova nada disso.

O Access Server 3.1 e posteriores podem servir certificados web diferentes por nome de host SNI. Se isso estiver configurado, as chaves padrão e as entradas específicas do nome são conjuntos separados, e testar por endereço IP mostra facilmente um certificado diferente do que os usuários recebem. Corrija e valide o conjunto do nome que falhou e repita o teste de login antes de encerrar o incidente.