Um portátil da empresa é roubado no comboio. O suporte técnico desativa a conta do Active Directory do colaborador, o dispositivo desaparece do registo de ativos e todos assumem que o risco foi eliminado. Dois dias depois, o portátil ainda aparece no SSID corporativo porque o seu suplicante 802.1X possui um certificado de cliente que não expirou e ninguém o revogou.
Essa é a lacuna que o processo de uma lista de revogação de certificados visa colmatar. A expiração do certificado define o limite máximo de confiança, enquanto a revogação interrompe essa confiança mais cedo quando uma chave é comprometida, um dispositivo é perdido ou um utilizador sai da organização. Para um administrador de rede WiFi empresarial, a questão crucial não é se os certificados existem. É saber se o RADIUS e os controlos de rede associados tomam conhecimento de um certificado revogado rapidamente e se falham de forma segura.
O Acesso WiFi Que Recusava Desaparecer
Uma implementação de WiFi baseada em certificados parece frequentemente segura a partir do exterior. O cliente utiliza EAP-TLS, o serviço RADIUS valida a cadeia de certificados e as palavras-passe partilhadas não são transmitidas entre os colaboradores. Mas esse design ainda depende de um ciclo de vida funcional. Emitir um certificado é apenas o início. Também deve saber quem é o seu proprietário, quando expira e o que acontece se o dispositivo ou a chave privada já não forem confiáveis.
No exemplo do computador portátil roubado, a remoção da conta do Active Directory pode impedir a autenticação futura no diretório, mas não invalida necessariamente um certificado já instalado no dispositivo. Se o serviço de WiFi confiar no certificado com base apenas na sua cadeia e datas de validade, o portátil pode continuar a apresentar credenciais aparentemente válidas. A notAfter date do certificado indica que este permanece dentro do seu tempo de vida programado. Não indica se a organização emissora ainda deseja confiar nele.
Regra prática: Trate a expiração do certificado e a revogação do certificado como controlos separados. A expiração é uma gestão planeada do ciclo de vida. A revogação é o travão de emergência.
O modelo PKI do setor público do Reino Unido torna essa distinção explícita. Uma Lista de Revogação de Certificados, ou CRL, é uma lista assinada de números de série de certificados revogados antes da expiração, que indica às partes confiantes que esses certificados já não devem ser considerados fidedignos. As orientações de infraestrutura de chaves públicas do Reino Unido também identificam as CRLs como um dos métodos comuns de revogação e esperam que os clientes verifiquem se um certificado apresentado aparece na lista da CA emissora.
Isto é importante no WiFi porque as decisões de autenticação ocorrem na periferia da rede, frequentemente através de múltiplos controladores, pontos de acesso, servidores RADIUS e armazenamentos de validação em cache. Uma atualização manual da CRL pode deixar uma lacuna de segurança, enquanto uma política de falha de segurança mal concebida pode criar uma interrupção se o ponto de distribuição da CRL ficar indisponível.
O modelo mental de funcionamento é simples: a CA emite e assina as informações de estado, a parte confiante verifica-as e a rede recusa um certificado que tenha sido revogado. O resto deste guia analisa como funciona esse processo, onde o CRL e o OCSP diferem, e como os controlos de acesso baseados em diretório podem eliminar grande parte do estrangulamento da revogação manual.
O que é Realmente um Certificado de Lista de Revogação
Em linguagem simples, uma Lista de Revogação de Certificados é um aviso oficial de "não confiar mais nestes certificados" emitido por uma autoridade de certificação. Identifica os certificados pelos seus números de série, e não por um nome amigável de dispositivo ou pelo endereço de e-mail de um funcionário. Um cliente que encontre o número de série do certificado apresentado na lista relevante deve rejeitá-lo, mesmo que a data de expiração do certificado ainda esteja no futuro.
A definição do Reino Unido é formal. Descreve uma CRL como uma lista assinada de números de série de certificados revogados antes da expiração, pelo que as partes dependentes já não devem confiar nesses certificados. A assinatura é importante porque um servidor RADIUS ou outro validador deve confirmar que a lista veio do emissor esperado e não foi alterada em trânsito. Uma lista de bloqueio em texto simples mantida por um administrador não oferece essa garantia criptográfica.
Três partes tornam o processo útil:
- A autoridade de certificação: A CA, ou um emissor de CRL autorizado, cria a lista e assina-a utilizando uma chave privada associada à hierarquia de confiança emissora.
- A parte dependente: Um servidor RADIUS, suplicante, controlador, sistema operativo ou ferramenta administrativa transfere a lista, valida a sua assinatura e informações de validade, e depois pesquisa o número de série do certificado.
- O titular do certificado: A pessoa, dispositivo ou serviço cujo certificado foi revogado. O seu número de série permanece na lista para que os validadores o possam identificar como não confiável.
Uma CRL não é normalmente um certificado no mesmo sentido que um certificado de utilizador ou de dispositivo. É um artefacto PKI assinado que transporta informações do emissor, validade e publicação. Por vezes, as pessoas utilizam "certificado de lista de revogação" como abreviatura para o mecanismo de revogação de certificados, mas o objeto operacional que está a ser verificado é a CRL assinada.
A entidade consumidora não costuma pedir à CA para explicar por que razão um utilizador deve ser recusado. Segue as informações de revogação do certificado, recupera a CRL atual do emissor, verifica a CRL e valida o número de série. Se houver uma correspondência, o certificado é revogado. Se não houver, o resultado ainda está limitado pela frescura da CRL e pela própria cache da entidade consumidora.
Esse último ponto causa muitos incidentes. Um certificado pode estar ausente de uma lista antiga em cache e presente numa mais recente. A decisão da rede depende, portanto, tanto do que a CA publicou como de quando o autenticador o obteve pela última vez.
Como Funciona uma CRL nos Bastidores
O ciclo de vida de uma CRL segue uma cadeia de eventos previsível. Primeiro, a CA gera uma lista base de acordo com a sua política de certificados. Assina a lista, adiciona campos de publicação e validade, e disponibiliza-a através de um ponto de distribuição. Os certificados emitidos referem-se commumente a esses locais através da extensão de Pontos de Distribuição de CRL, permitindo que um validador descubra onde reside a informação do estado.
Quando um administrador revoga um certificado de dispositivo, a CA regista o seu número de série e as informações do motivo. O certificado não aparecerá necessariamente na cache de todas as entidades consumidoras de imediato. A próxima CRL publicada deve conter a entrada, e cada servidor RADIUS ou controlador deve obter uma cópia atualizada antes de poder tomar a decisão correta.
Alguns ambientes de PKI também utilizam CRLs delta. Uma delta contém alterações desde uma CRL base, o que pode reduzir o trabalho de transferência e processamento quando a lista completa é grande. Essa eficiência não elimina a necessidade de gerir a lista base, validar assinaturas, monitorizar a frescura ou garantir que todos os componentes de rede compreendem o modelo de publicação escolhido.
A janela de frescura
As políticas do Reino Unido fornecem pontos de referência úteis para pensar sobre a propagação. A declaração de práticas de CVCA do governo do Reino Unido exige que as CRLs sejam emitidas, no máximo, a cada 90 dias, e exige que um certificado revogado apareça na CRL relevante no prazo de 72 horas após a revogação. Esses limites estão descritos na UK national certificate policy.
Outras políticas do Reino Unido utilizam diferentes expetativas de serviço. O HM Land Registry afirma que a sua lista de revogação para certificados revogados e suspensos deve ser atualizada pelo menos uma vez por dia, enquanto a declaração de práticas de certificação da Universidade de York estabelece uma latência máxima de 10 dias entre a revogação e a emissão da CRL. Estes exemplos, incluindo o ponto de publicação da HMPO Country Signing Certificate Authority, mostram por que razão um administrador deve ler a política real da CA emissora em vez de assumir que todas as CRL se comportam da mesma forma.
No momento da autenticação, o servidor RADIUS verifica o número de série do certificado em relação à sua CRL disponível localmente. Também verifica se a CRL está dentro do seu período de validade, se a assinatura se liga ao emissor esperado e se o ponto de distribuição pode ser alcançado quando uma atualização é devida. O servidor armazena então o resultado em cache de acordo com a sua implementação e com o valor de nextUpdate da CRL.
Isto produz uma equação de risco prática sem a necessidade de matemática complicada: a latência de revogação inclui o tempo de publicação da CA, o atraso de distribuição, a duração da cache e a frequência de autenticação. Uma política pode publicar rapidamente, mas uma cache RADIUS desligada ou desatualizada ainda pode atrasar a aplicação.
CRL vs OCSP e Por Que Razão Isto Importa no WiFi
A CRL e o OCSP resolvem o mesmo problema básico de formas diferentes. Uma CRL fornece ao validador um lote assinado de números de série revogados. O OCSP pergunta a um respondente autorizado o estado de um único certificado no momento em que está a ser verificado.
Para um administrador de WiFi empresarial, a escolha afeta mais do que a elegância da PKI. Altera a forma como um controlador se comporta numa WAN congestionada, o que a infraestrutura da CA tem de processar e se uma tentativa de autenticação pode ser concluída quando um respondente ou ponto de distribuição está inacessível.
| Critério | CRL | OCSP |
|---|---|---|
| Atualização | Periódica. Um certificado recentemente revogado aguarda pela publicação e pela atualização do cliente. | A consulta por certificado pode fornecer um estado mais atualizado quando o respondente está acessível. |
| Carga na infraestrutura | Os clientes descarregam e processam uma lista, o que pode ser eficiente para verificações repetidas num parque gerido, mas pode gerar tráfego de distribuição. | O respondente processa pedidos de estado individuais, o que evita o descarregamento da lista completa, mas aumenta o volume de pedidos. |
| Privacidade | A parte confiante obtém uma lista e não necessita de revelar cada verificação de certificado à CA. | Uma consulta direta pode revelar ao respondente qual o certificado que está a ser verificado. |
| Modo de falha | Uma CRL inacessível ou expirada pode impedir a validação fiável do estado. As caches locais podem continuar a funcionar até ao limite do seu período de atualização. | Um respondente inacessível afeta a consulta de estado individual, sendo que o comportamento configurado de soft-fail ou hard-fail determina o resultado no WiFi. |
Um controlador que serve um grande campus pode preferir uma CRL armazenada localmente em cache porque pode verificar muitos números de série de certificados sem enviar um pedido separado para cada autenticação. Esse modelo funciona bem quando os pontos de distribuição estão acessíveis, as atualizações são monitorizadas e a política RADIUS lida deliberadamente com uma lista expirada.
O OCSP pode adequar-se a um design em que o operador precisa de uma resposta por certificado e aceita a dependência de um respondente. Pode reduzir a necessidade de transferir uma lista completa, mas introduz uma dependência de rede em tempo real durante a autenticação. O Stapling pode mover a interação do respondente para outro local em alguns protocolos, mas o design de WiFi ainda necessita de uma resposta clara para dados de estado indisponíveis ou desatualizados.
As orientações do Reino Unido são úteis aqui porque não apresentam a CRL como o único método. A política do Reino Unido descreve as CRLs como um dos mecanismos comuns de revogação, enquanto as orientações do sector da justiça as tratam como um mecanismo offline primário e destacam os requisitos de disponibilidade para os serviços de revogação na declaração de divulgação de PKI.
Para dispositivos 802.1X geridos, a CRL é normalmente prática para validação periódica em lote, especialmente quando a infraestrutura possui uma distribuição interna fiável. O OCSP é preferível onde uma maior frescura do estado é essencial e a disponibilidade do responder é projetada em conformidade. As redes de alta garantia podem executar ambos, mas apenas se o comportamento de fallback for documentado e testado em vez de ser assumido.
Revogação na Prática numa Rede Purple WiFi
A diferença operacional surge quando o acesso WiFi está associado a um diretório de identidades em tempo real, em vez de uma lista de certificados mantida manualmente. Uma integração de diretório pode tornar o estado atual da conta do utilizador parte da decisão de autenticação, pelo que a desativação de uma conta se torna um evento de controlo de acesso, em vez de um pedido que alguém deve traduzir mais tarde numa revogação de CA.
Um fluxo típico assemelha-se a isto:
- O diretório regista o estado da identidade. Uma conta é criada, alterada, suspensa ou desativada no Active Directory, Entra ID ou Google Workspace.
- O serviço de identidade WiFi recebe a alteração. O serviço mapeia o estado do diretório para a política de autenticação da organização.
- A próxima autenticação é avaliada em relação a esse estado. Uma identidade desativada deixa de cumprir a regra de acesso, mesmo que uma credencial emitida anteriormente ainda esteja dentro do período de validade do seu certificado.
- A rede recusa o acesso. A decisão de RADIUS impede que uma nova sessão 802.1X seja autorizada sob a identidade inativa.
Esse modelo aborda uma fraqueza nas operações exclusivas de CRL. Uma CRL depende da publicação da CA, pontos de distribuição, atualizações de cache e verificações da entidade consumidora. A aplicação orientada por diretório torna o sistema de identidade a fonte operacional da verdade para o estado da conta, reduzindo a necessidade de um administrador encontrar todos os números de série de certificados associados a um utilizador que está a sair.
Distinção operacional: Uma CRL responde se um certificado está revogado. A autenticação baseada em diretório pode responder se a identidade está atualmente autorizada a utilizar a rede.
A Purple fornece controlos geridos de RADIUS e de WiFi empresarial baseado em certificados com integrações de diretórios, tais como Microsoft Entra ID e Google Workspace. A sua oferta de RADIUS-as-a-Service é relevante onde uma organização pretende ligar o estado da identidade à autenticação 802.1X sem manter ela própria todos os componentes locais de RADIUS e de revogação.
Isto não faz com que o trabalho de ciclo de vida de PKI desapareça. Os certificados ainda necessitam de emissão, renovação, gestão de cadeia de confiança e verificações de revogação onde a arquitetura o exigir. No entanto, remove um gargalo manual do processo de desativação (offboarding). O service desk pode desativar a identidade através do fluxo de trabalho do diretório estabelecido, enquanto a camada de autenticação de rede aplica esse estado na próxima decisão de acesso.
Melhores Práticas Operacionais para WiFi Empresarial
Um design de revogação fiável combina controlos criptográficos com uma disciplina operacional normal. Comece pelo tempo de vida do certificado. Para dispositivos WiFi geridos, um tempo de vida do certificado de 12 a 24 meses é uma referência operacional comum nas orientações de implementação fornecidas, mas a escolha correta depende da propriedade do dispositivo, da capacidade de renovação e dos danos que uma chave privada exposta poderia causar. Os certificados de patrocinadores de convidados devem, geralmente, ter tempos de vida mais curtos porque o seu contexto de acesso muda com maior frequência.
Integre a renovação no ciclo de vida dos dispositivos
Utilize SCEP, uma plataforma MDM ou outro caminho de inscrição automatizado para renovar certificados antes de expirarem. A renovação manual funciona durante um projeto-piloto e torna-se frágil numa infraestrutura distribuída. Teste a renovação em computadores portáteis suspensos, dispositivos remotos, dispositivos reinstalados e dispositivos que não se tenham ligado recentemente à rede corporativa.
Monitorize os pontos de distribuição de CRL a partir dos mesmos caminhos de rede utilizados pelo RADIUS e pelos controladores. Verifique a acessibilidade, a validade da assinatura, a identidade do emissor e o nextUpdate, e não apenas se um pedido web devolve conteúdo. Uma CRL acessível mas expirada continua a ser um controlo de revogação falhado.
Mantenha o lado do RADIUS limpo
Os certificados do servidor RADIUS precisam de validade atual, de uma cadeia de emissão fidedigna e de um processo de renovação que não dependa de uma janela de manutenção de última hora. Reveja os repositórios de confiança nos servidores, controladores e clientes geridos para que um certificado de CA antigo não crie decisões inconsistentes entre sites.
Documente o manual de revogação na linguagem que um engenheiro de piquete possa seguir:
- Identifique a credencial: Registe o utilizador, o dispositivo, o número de série do certificado e a CA emissora.
- Desative a identidade: Aplique a ação de desvinculação aprovada no diretório ou nos recursos humanos.
- Revogue quando necessário: Atualize o estado da CA e confirme a publicação.
- Atualize as partes dependentes: Force ou agende a obtenção da CRL onde for suportado.
- Teste a recusa: Tente a autenticação com a credencial afetada e preserve o resultado.
Alinhe os gatilhos de RH com as alterações de diretório. Se o suporte técnico tiver de aguardar por um pedido de PKI separado, a rede pode continuar a confiar numa identidade que a organização já marcou como inativa. O aprovisionamento e a renovação automatizados reduzem esse desfasamento, enquanto um caminho manual documentado continua a ser importante para dispositivos roubados e suspeitas de comprometimento de chaves.
Para o acesso de funcionários sem palavra-passe, analise a forma como estes controlos se enquadram numa implementação WPA-Enterprise, incluindo o registo de certificados, a validação de RADIUS e a gestão de processos de saída (offboarding).
Resolução de Problemas Comuns de Revogação
A maioria dos incidentes de CRL enquadra-se em três categorias: o validador tem informações antigas, não consegue encontrar o ponto de publicação correto ou o armazenamento de revogação tornou-se difícil de operar. Diagnostique o caminho de decisão em vez de começar por emitir novamente os certificados.
Uma cache local desatualizada
Um servidor ou controlador RADIUS pode ainda reter uma CRL que antecede a revogação. Confirme os campos thisUpdate e nextUpdate da CRL, valide a sua assinatura em relação à CA emissora e inspecione a cópia em cache no autenticador. Compare o número de série apresentado pelo cliente com as entradas na CRL recém-publicada.
A correção imediata consiste em forçar uma atualização da CRL, caso a plataforma o suporte, e depois repetir um teste de autenticação com o certificado afetado. Se a cache continuar a devolver dados antigos, inspecione o comportamento do proxy, o caching do ponto de distribuição e a política de atualização do validador.
Um ponto de distribuição em falta
Leia as extensões CDP e AIA do certificado emitido. O CDP indica à entidade dependente onde encontrar informações de revogação, enquanto o AIA pode ajudá-la a identificar as informações do emissor necessárias para a validação da cadeia. Confirme se o URL está correto, acessível a partir da rede RADIUS e a servir uma CRL assinada pelo emissor esperado.
Se o modelo da CA contiver a localização incorreta, corrija o modelo e emita certificados de substituição. Atualizar apenas o dispositivo final não irá reparar os certificados que já contêm um ponto de distribuição inutilizável.
Um repositório de revogação inacessível
As entradas antigas podem complicar a administração e aumentar o trabalho de processamento. Elimine as entradas apenas ao abrigo da política de retenção da CA e apenas após terem sido considerados o tempo de vida do certificado relevante e os requisitos de auditoria. Nunca remova um número de série apenas porque o ticket do incidente está fechado.
Os exemplos de políticas do Reino Unido mostram por que a "frescura" deve ser definida localmente. Algumas autoridades do Reino Unido exigem atualizações diárias, enquanto a política nacional de CVCA exige a publicação no prazo de 72 horas para um certificado revogado e define um período máximo de emissão de 90 dias. Trate isso como bases de política, e não como permissão para aceitar dados empresariais desatualizados.
Uma ferramenta de análise de certificados pode ajudar a inspecionar os detalhes do emissor, validade, CDP e cadeia. O verificador de certificados SSL da Purple é uma opção para examinar a integridade do certificado, enquanto a aplicação baseada em diretório pode evitar depender unicamente de uma atualização de CRL atrasada para a desativação de utilizadores.
Juntar Tudo Esta Semana
Transforme a revogação em tarefas atribuídas em vez de um parágrafo de política. Coloque estas ações na próxima janela de alteração e atribua a cada uma um proprietário designado.
- Equipa de PKI, audite os caminhos dos certificados: Inventarie cada modelo de certificado de cliente WiFi, CA emissora, CDP e relação de confiança RADIUS. Confirme que cada ponto de distribuição está acessível a partir de todos os locais de autenticação.
- Equipas de PKI e de endpoints, definam uma validade defensável: Reduza os certificados de cliente WiFi para 12 meses ou menos onde o processo de renovação de dispositivos o possa suportar. Uma validade mais curta reduz a dependência de revogações de emergência, mas apenas se a renovação for automatizada e testada.
- Equipa de endpoints, automatize a renovação: Utilize MDM ou SCEP para registar e renovar certificados sem intervenção do utilizador. Teste o processo após a reinstalação de um dispositivo, um longo período offline e uma alteração de utilizador.
- Service desk e equipa de identidade, associem a desativação à negação de acesso: Garanta que o estado inativo no fluxo de RH ou de service desk se reflete diretamente no controlo de diretório utilizado pela autenticação WiFi. Verifique se uma identidade desativada não consegue estabelecer uma nova sessão 802.1X.
- Equipa de rede, monitorize as dependências de revogação: Crie alertas para pontos de distribuição indisponíveis, CRLs expiradas, assinaturas inválidas e falhas nas verificações de estado. Subscreva as notificações de alteração da CA para que uma alteração de publicação não prejudique a autenticação sem ser notada.
Meça dois resultados durante o período de revisão seguinte. Primeiro, registe a latência entre um evento de desativação de diretório e a terminação ou recusa de uma nova sessão WiFi. Segundo, meça quantas autenticações RADIUS concluíram uma verificação de CRL com sucesso, em vez de continuarem por um caminho de falha simples (soft-fail). Essas medidas indicam-lhe se o design funciona sob pressão, e não apenas se os certificados parecem corretos numa folha de cálculo.
Se a sua equipa pretende reduzir a administração manual de PKI mantendo o WiFi empresarial baseado em identidade, a Purple pode fornecer autenticação gerida de nível de certificado, decisões de acesso ligadas ao diretório e serviços RADIUS que suportam a verificação de revogação. Visite a Purple para avaliar como a sua abordagem se pode enquadrar no seu fluxo de trabalho de desativação de WiFi e ciclo de vida de certificados.
