Instalação inicial do servidor WiKID

Visão geral

Configurar o servidor de autenticação WiKID envolve gerar chaves assimétricas, criar uma CA intermediária, emitir um certificado para o servidor, instalar o certificado assinado e gerar certificados para clientes locais (por exemplo, serviços que usam “localhost”). Depois disso, você pode adicionar domínios, clientes de rede e usuários.

Este documento amplia a documentação básica, fornece heurísticas, procedimentos para recuperação e teste, e checklists para funções diferentes: administrador de sistema, operador de segurança e equipe de suporte.

Importante: não perca o passphrase criado para proteger a chave privada do servidor — ele nunca é armazenado e não há recuperação.

Intenção principal e variantes relacionadas

Intenção primária: configurar a cadeia de certificados do servidor WiKID. Variantes: gerar CSR, instalar CA intermediária, criar certificado localhost, reiniciar wAuth, solucionar problemas de instalação, práticas recomendadas de segurança.

Antes de começar — pré-requisitos

• Acesso root ao servidor WiKID.
• Acesso à interface de administração web do servidor WiKID (conta administrativa).
• Um email válido para receber o certificado assinado.
• Navegador com capacidade de copiar/colar texto sem conversão de formato (use um editor de texto simples quando necessário).
• Entendimento básico de PKI: uma linha: “PKI = chaves assimétricas (pública/privada) + certificados que ligam identidade à chave pública.”.

Nota: se estiver em um ambiente regulado (GDPR, LGPD), consulte a seção de privacidade mais adiante.

Página inicial de instalação

A configuração do servidor de autenticação WiKID é rápida: crie uma CA intermediária, instale-a, gere um certificado para localhost e habilite módulos de protocolo. Após isso, adicione domínios, clientes de rede e usuários.

Figura 3 - Página inicial de administração

Configurando a cadeia de certificados

O sistema WiKID usa certificação interna de forma crítica para duas funções principais:

• Cada servidor de autenticação atua também como uma autoridade certificadora intermediária.
• Cada servidor usa certificados para identificar e autorizar clientes de rede.

Isso significa que você precisa gerar um certificado e uma chave antes que o servidor esteja totalmente funcional. O procedimento é feito pela interface administrativa web do servidor. Acesse a aba chamada ‘Criar CA Intermediária’ (ou equivalente) para iniciar o processo de geração.

Passo 1: Gerar a CA Intermediária

O primeiro passo é gerar as chaves pública/privada que identificarão o servidor e servirão para criptografia assimétrica via SSL/TLS. O servidor já inclui um certificado da CA corporativa WiKID; você gera suas próprias chaves e um CSR (Certificate Signing Request).

Figura 4 - Tela de criação da autoridade certificadora intermediária

Este formulário coleta os dados necessários para gerar um CSR. Todos os campos são obrigatórios.

Campos e orientações práticas:

• Administrador da CA Intermediária (email): email de contato para envio do certificado assinado. Use um endereço funcional e monitorado.
• Nome de domínio totalmente qualificado do servidor (FQDN): nome DNS público/registrado do servidor. Clientes SSL esperam que este nome corresponda ao nome usado na conexão.
• Unidade organizacional: departamento ou divisão — usado apenas para identificação.
• Nome da organização: nome legal da empresa operadora.
• Localidade: cidade.
• Estado: estado/província por extenso (evite abreviações).
• Código do país: código ISO de duas letras (por exemplo, BR para Brasil, PT para Portugal, US para Estados Unidos).
• Passphrase: senha que protegerá a chave privada no arquivo PKCS#12. Você usará essa passphrase sempre que iniciar o servidor. Não existe recuperação: escolha uma senha forte e memorável e faça backup seguro offline.

Depois de preencher o formulário, selecione ‘Gerar’. O servidor criará as chaves e exibirá o CSR em base64 DER.

Figura 5 - O CSR

Copie todo o texto do CSR (incluindo as linhas —–BEGIN CERTIFICATE REQUEST—– e —–END CERTIFICATE REQUEST—–) para a área de transferência.

Passo 2: Submeter o CSR para assinatura

Clique no link indicado pela interface (por exemplo, para https://www/wikidsystems.com/wikid/newcertreq.jsp) que abre a página de submissão do CSR da CA WiKID.

Figura 6 - Tela de submissão do CSR

Cole o texto do CSR (incluindo as linhas —–) no campo apropriado e envie para processamento. Você receberá um número de solicitação para acompanhamento. A administração da CA processará o pedido e enviará o certificado por email para o endereço fornecido no passo 1.

Nota operativa: o processo normalmente leva menos de um dia útil, dependendo da fila administrativa.

Figura 8 – Bloco de certificado recebido por email

Importante: o certificado por si só é inútil sem a chave privada gerada no passo 1. Quando copiar o certificado do email, cole como texto simples (plain text). Alguns clientes de email podem converter o conteúdo para UTF-8 com marcas invisíveis — use um editor simples para verificar.

Passo 3: Instalar o certificado

Após receber o certificado, volte à aba ‘Instalar CA Intermediária’ na interface de gerenciamento de certificados do servidor e selecione ‘Instalar’.

Figura 9 – Tela de instalação do certificado

Cole o texto do certificado (PEM) no campo indicado e informe a passphrase criada no passo 1 para desbloquear a chave privada. Se houver um erro, verifique:

• Se a passphrase foi digitada corretamente.
• Se você colou o certificado em texto sem formatação.

Se a passphrase tiver sido perdida, não é possível recuperar a chave privada — será necessário reiniciar o processo a partir do passo 1.

Passo 4: Gerar um certificado para localhost

Todos os serviços que comunicam diretamente com o servidor de autenticação exigem um certificado válido emitido pelo CA intermediária do servidor. Para serviços locais — os módulos de protocolo que rodam no próprio servidor — crie um certificado que seja assinado pela CA intermediária e cujo FQDN seja exatamente ‘localhost’.

Alguns protocolos (por exemplo, RADIUS na versão Enterprise, LDAP, wAuth) não tratam diretamente de autenticação por certificado em seu padrão. O WiKID fornece módulos de protocolo que convertem essas comunicações em canais seguros que dependem do certificado. Portanto, mesmo que o protocolo em si não tenha suporte a certificados, o módulo local exigirá um certificado válido.

A interface de geração de certificados permite especificar ‘localhost’ como FQDN para serviços locais. Preencha o formulário e gere o certificado.

Figura 10 – Tela de geração de certificado

Campos mais comuns e o que significam:

• Nome do cliente (FQDN): nome DNS que será usado quando um cliente conectar; para serviços locais, use ‘localhost’.
• Nome da organização: nome da empresa operadora do cliente.
• Localidade: cidade.
• Estado: estado/província por extenso.
• Código do País: código ISO de duas letras.
• Passphrase do PKCS#12 do cliente: senha que protegerá o arquivo PKCS#12 do cliente.
• Repita a passphrase do cliente: verificação.
• Passphrase do keystore do servidor: a passphrase da CA intermediária criada no passo 1.

Selecione ‘Gerar’ e o sistema exibirá a localização do certificado gerado. Se o certificado for para serviços localhost, ele já estará instalado nos locais apropriados.

Figura 11 – Tela de entrega do PKCS12

Passo 5: Reiniciar o serviço wAuth

Faça login no servidor de autenticação como root e execute:

wikidctl restart

Isso encerrará os serviços de autenticação WiKID. Você será solicitado a informar a passphrase wAuth (aquela criada no passo 1 para a CA intermediária). Ao fornecer a passphrase correta, o servidor iniciará usando o novo certificado para autenticação de clientes.

Se preferir evitar digitar a passphrase a cada reinício, é possível criar um arquivo chamado /etc/WiKID/security contendo uma linha como:

WAUTH_PASSPHRASE=yourpassprase

Nota de segurança: armazenar a passphrase em texto claro tem implicações de risco — só faça isso quando estiver sob controles físicos e de acesso adequados.

Checklist rápido (resumo de execução)

• Gerar CA intermediária (preencher formulário e copiar CSR).
• Submeter CSR para a CA WiKID e registrar o número de solicitação.
• Receber o certificado por email e validar o PEM.
• Instalar o certificado na interface com a passphrase correta.
• Gerar certificado para ‘localhost’ (se necessário) e confirmar instalação.
• Reiniciar o processo wAuth com a passphrase.
• Validar conectividade de clientes e serviços locais.

Playbook operacional detalhado (SOP)

1. Preparação

   • Confirme acesso root e acesso administrativo à interface web.
   • Verifique o FQDN do servidor e configure DNS reverso quando aplicável.

2. Gerar CA Intermediária

   • Preencha o formulário com dados válidos. Use email monitorado.
   • Anote o passphrase em cofre de senhas corporativo seguro.
   • Copie o CSR para um arquivo .csr local (texto simples).

3. Submeter CSR

   • Acesse a URL da CA e cole o CSR.
   • Anote o número de solicitação e guarde o email de confirmação.

4. Receber e instalar certificado

   • Ao enviar o PEM, salve uma cópia local no servidor em /etc/WiKID/certs/ (permissões 600).
   • No painel, cole o PEM e insira a passphrase do passo 2.

5. Gerar certificado localhost

   • Gere e confirme instalação automática para serviços locais.

6. Reiniciar e validar

   • Execute wikidctl restart, forneça passphrase.
   • Teste conexões LDAP, RADIUS (se aplicável), e wAuth.

7. Verificação final

   • Verifique logs em /var/log/WiKID (ou o local de log específico) para erros.
   • Valide certificados com openssl quando necessário.

Runbook de incidentes — perda da passphrase da CA intermediária

Sintoma: Ao reiniciar, o servidor não inicia os serviços e retorna erro de passphrase inválida ou faltante.

Ações imediatas:

1. Verifique backups: procure cópias da chave PKCS#12 exportada e do passphrase em cofres de senhas aprovados.
2. Se não houver cópia, comece o processo de recuperação: gerar uma nova CA intermediária seguindo Passo 1 — isso gera uma nova chave privada, e você deverá re-assinar todos os certificados que dependiam da CA antiga (clientes e serviços locais).
3. Atualize qualquer cliente que confie exclusivamente na CA antiga para confiar na nova CA (pode exigir reconfiguração de clientes RADIUS/LDAP/serviços).
4. Notifique stakeholders: período de indisponibilidade pode ocorrer até que todos os serviços sejam reassinados.

Mitigações futuras:

• Armazenar passphrases em um cofres de senhas corporativo com controle de acesso.
• Procedimento de backup da chave privada (criptografada) e do certificado com controle de acesso.

Testes e critérios de aceitação

Critérios de aceitação (mínimos):

• O servidor inicia com sucesso após reinício usando a nova CA intermediária.
• Serviços locais que usam ‘localhost’ estabelecem TLS sem erros de certificado.
• Clientes de rede configurados com o novo certificado podem autenticar com sucesso.
• Logs não apresentam erros críticos relacionados a certificados ou passphrases.

Casos de teste recomendados:

1. Teste de inicialização: reinicie e confirme que wikidctl finaliza e inicia sem interface de erro.
2. Teste LDAP: autentique um usuário via LDAP local e verifique a troca de certificados.
3. Teste RADIUS (se aplicável): verifique que o gateway RADIUS com módulo WiKID autentique corretamente.
4. Teste de validação do certificado: utilize openssl s_client -connect host:port e verifique o certificado apresentado.

Modelos de preenchimento (template) para CSR

Use este checklist ao preencher o CSR:

• Email do administrador: [email protected]
• FQDN do servidor: auth.dominio.com
• Unidade organizacional: Segurança da Informação
• Nome da organização: Empresa Exemplo SA
• Localidade: São Paulo
• Estado: São Paulo
• Código do país: BR
• Passphrase: (salvar no cofre de senhas corporativo)

Heurísticas e mental models

• Mental model de cadeia de confiança: Root CA (corporativa) confia na CA intermediária (seu servidor), que emite certificados para servidores e serviços locais.
• Heurística de rotação: rotacione certificados e chaves em ciclos planejados (por exemplo, 1–3 anos para certificados, 1 ano para chaves muito críticas) e tenha procedimento de atualização coordenado.
• Princípio do menor privilégio: limitar acesso à pasta de chaves privadas e ao arquivo /etc/WiKID/security.

Quando este procedimento falha (contraexemplos)

• Se o CSR contiver um FQDN que não corresponde ao nome usado pelos clientes para conectar, os clientes SSL apresentarão alerta de nome inválido.
• Se o passphrase for perdido e nenhum backup existir, é necessário recriar a CA; isso exige reemissão de certificados para todos os clientes.
• Em ambientes com políticas de segurança rígidas, armazenar passphrase em /etc/WiKID/security pode violar conformidade.

Alternativas e variações

• Uso de uma CA interna corporativa em vez da CA WiKID: submeta o CSR a sua CA interna seguindo o mesmo fluxo, mas observe políticas de confiança dos clientes.
• Automatização: em ambientes DevOps, use scripts seguros e cofres (HashiCorp Vault, Azure Key Vault) para gerenciar passphrases e distribuição de PKCS#12.

Segurança: endurecimento e melhores práticas

• Proteja arquivos de chave privada com permissões restritas (chmod 600) e propriedade root.
• Use cofres de segredos aprovados para armazenar passphrases; evite arquivos em texto claro.
• Monitore logs de autenticação e de serviço para detectar tentativas de uso indevido de certificados.
• Documente e teste procedimentos de rotação e recuperação periodicamente.

Privacidade e conformidade (GDPR / LGPD) — notas operacionais

• Os certificados e CSRs em si não transportam dados pessoais sensíveis por padrão. Contudo, campos como email ou nomes podem conter informações identificáveis. Trate esses dados conforme políticas de privacidade da empresa.
• Se o processo envolver usuários finais (ex.: emails de notificação), garanta que o fluxo de dados esteja autorizado e documentado.

Checklist por função

Administrador de Sistema

• Gerar CA intermediária.
• Guardar passphrase em cofre seguro.
• Instalar certificado recebido.
• Configurar /etc/WiKID/security se aplicável.

Operador de Segurança

• Validar permissões de arquivos de chaves.
• Configurar monitoramento e alertas.
• Testar rotação de certificados em ambiente controlado.

Suporte Técnico

• Validar conectividade de clientes.
• Executar openssl s_client para diagnóstico.
• Reexecutar geração se o passphrase estiver perdido (com coordenação).

Snippets e comandos úteis

• Reiniciar serviços WiKID (mantido do documento original):

wikidctl restart

• Exemplo: verificar certificado via openssl (ajuste host:port conforme serviço):

openssl s_client -connect auth.dominio.com:443 -showcerts

• Para conferir o conteúdo de um arquivo PEM localmente:

openssl x509 -in certificado.pem -text -noout

Fluxo decisório (Mermaid) — devo recriar a CA?

flowchart TD
  A[Recebe erro de passphrase ao iniciar?] -->|Não| B[Continuar operação]
  A -->|Sim| C[Existe backup do passphrase/PKCS12?]
  C -->|Sim| D[Restaurar de backup e reiniciar]
  C -->|Não| E[Recriar CA intermediária]
  E --> F[Reemitir certificados para clientes]
  F --> G[Atualizar clientes e verificar]
  D --> G

Critérios de aceitação e testes finais

• O servidor reinicia sem solicitar passphrase que não esteja disponível.
• Serviços locais que usam ‘localhost’ aceitam conexões TLS sem erros de nome ou validade do certificado.
• Testes de autenticação (LDAP/RADIUS/wAuth) passam em ambiente de validação antes de migrar para produção.

Migração e notas de compatibilidade

• Ao migrar de uma CA antiga para uma nova, planeje uma janela de manutenção para reemitir e distribuir certificados.
• Alguns clientes legados podem exigir configuração manual para confiar na nova CA; prepare instruções de distribuição para administradores desses clientes.

Galeria de casos extremos e mitigação rápida

• Certificado corrompido ao colar do email: use um editor de texto simples para remover marcas de formatação e reenviar o PEM.
• Cliente rejeita conexão por erro de nome: verifique o FQDN do certificado e o DNS usado pelo cliente.
• Serviços que não aceitam PKCS#12: converta o PKCS#12 para PEM com openssl para compatibilidade.

Resumo final

Configurar a CA intermediária e os certificados no servidor WiKID é um processo linear: gerar chaves e CSR, submeter para assinatura, instalar o certificado, gerar certificado para ‘localhost’ e reiniciar o serviço. Proteja passphrases em cofres seguros, verifique permissões de arquivos e execute testes de aceitação antes de considerar o serviço pronto para produção.

Importante: perda do passphrase exige recriação da CA e reemissão de certificados; tenha um plano de recuperação e backups sob controle de acesso.

1-linha de glossário

PKCS#12 — formato que embala chave privada e certificado em um único arquivo protegido por senha.