SoftEther ServerCertSet: importar a cadeia renovada com vpncmd

O Certbot relata uma renovação bem-sucedida, os ficheiros no disco têm novas datas e os clientes continuam a encontrar a identidade antiga. O SoftEther guarda o certificado SSL do servidor na sua própria configuração ao nível do servidor, por isso um novo ficheiro no disco não altera nada até a folha e a respetiva chave serem importadas. A sequência abaixo cobre uma importação manual, um invólucro que corre após cada renovação e uma verificação que lê o que o listener apresenta realmente. Cada passo deixa provas que pode comparar após a renovação seguinte.

Um ficheiro renovado não altera a identidade do servidor

A emissão e a implementação são eventos separados com modos de falha separados. O cliente ACME escreve ficheiros num diretório de linhagem e registra sucesso; o SoftEther continua a usar o certificado que foi carregado pela última vez na sua configuração. Um estado de saída zero descreve, portanto, os ficheiros e não o serviço, e os dois podem divergir enquanto ninguém olhar. Trate a importação como o passo de implementação e a renovação como a sua entrada.

Essa distinção explica também a confusa meia-falha: o certificado antigo continua a funcionar até ao seu vencimento, por isso nada parece avariado no início. Quando vence, todos os clientes falham ao mesmo tempo, o que parece uma interrupção e não um passo de implementação esquecido. Verificar a identidade apresentada após cada renovação transforma essa surpresa numa observação de rotina.

Escolha o desafio adequado ao listener

O certificado tem de nomear o host que os clientes verificam, por isso use o nome DNS público em vez de uma etiqueta interna ou de um endereço. O HTTP-01 exige que o desafio seja respondido no porto 80 por um instante, o que é um listener temporário e nunca um motivo para mover o porto próprio do SoftEther. O DNS-01 prova o controlo através de um registro e não precisa de qualquer HTTP de entrada.

A renovação sem supervisão significa uma integração DNS automatizada com credenciais limitadas a uma só zona, não um registro TXT escrito à mão a cada dois meses. Um curinga altera o tipo de desafio, não a necessidade dessa automatização. Decida isto antes de existir o primeiro certificado, porque mudar o tipo de desafio mais tarde significa tocar na configuração do cliente e na firewall ao mesmo tempo.

Mantenha os artefactos em ordem enquanto está aqui. A folha e os intermédios chegam como ficheiros separados e como um ficheiro de cadeia combinado, a chave privada volta a estar separada, e a importação precisa da cadeia com a chave correspondente, não de um certificado público sozinho.

Importe a cadeia ao nível do servidor

Faça uma cópia de segurança da configuração do servidor e confirme que ainda alcança a interface de gestão antes de tocar no certificado. Ligue-se como administrador do servidor e não como administrador do Virtual Hub, porque o certificado pertence ao objeto do servidor. Depois carregue a cadeia e a chave por caminho absoluto, a partir de ficheiros que a conta que executa o comando possa ler. Note que os caminhos são absolutos porque o comando os resolve a partir do diretório de trabalho do processo que executou o vpncmd:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

Leia a saída do comando em vez de assumir o sucesso, e depois volte a ler a cadeia em vez de confiar no ficheiro que passou. A fronteira entre compilações que importam um pacote PEM inteiro e compilações que recebem apenas o primeiro certificado não está documentada num único lugar, por isso é a verificação que a resolve para a compilação à sua frente. Conte os certificados que o listener apresenta; uma folha sem intermédios é a assinatura de um importador que consumiu apenas o primeiro bloco.

Mantenha a chave importada legível apenas pela conta que executa o servidor, e mantenha a palavra-passe de gestão fora do histórico da shell. Nesta primeira importação, escreva a palavra-passe no pedido em vez de a passar como argumento do comando. Estes dois hábitos não custam nada e removem a forma mais comum de uma implementação de certificados divulgar algo que devia proteger. Faça-o antes da primeira importação, não depois.

Acople a implementação, não a renovação

Quando a importação manual funcionar, coloque exatamente esses passos num invólucro pequeno e chame-o a partir do cliente ACME após uma renovação bem-sucedida. O Certbot define RENEWED_LINEAGE e RENEWED_DOMAINS para o hook, por isso o invólucro pode atuar sobre um certificado numa máquina que gere vários. Filtre pela linhagem em vez de reagir a cada renovação do host. O invólucro é código de implementação que corre com os privilégios do servidor, por isso reveja-o como qualquer outro script nessa posição.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

Um hook que corre sem supervisão precisa do seu próprio armazém protegido de credenciais e de um sinal de falha que chegue a uma pessoa. Se a emissão tiver sucesso e a importação falhar, tente a importação novamente em vez de pedir outro certificado, porque um segundo pedido esconde o defeito de implementação atrás de um ficheiro novo. A documentação de renovação do Certbot é clara ao afirmar que uma execução que não atualiza nada é um resultado normal, por isso é o hook que distingue os dois casos.

Compare a cadeia apresentada com o ficheiro

Leia o listener, não o disco. Ligue-se ao porto virado aos clientes com o nome de servidor que os clientes usam e compare depois a impressão digital e a cadeia entregue com a linhagem que o hook instalou. Dois comandos cobrem isto, e o primeiro também mostra se os intermédios chegam de todo:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

Depois faça uma nova ligação de cliente, porque as sessões estabelecidas antes da importação foram autenticadas contra a identidade anterior e não provam nada sobre a nova. Se os clientes fixarem a folha antiga, precisam de uma atualização coordenada mesmo quando a cadeia pública é válida, e essa tarefa pertence ao mesmo runbook da renovação. Um proxy inverso à frente do serviço pode apresentar um certificado bom enquanto o listener VPN ainda tem o antigo, e é por isso que a verificação tem de nomear o porto que os clientes realmente alcançam. Anote a impressão digital ao lado da data de renovação, para que a comparação seguinte seja uma verificação e não um ato de memória.