Revogar un cliente Azure Point-to-Site significa engadir a súa pegada á lista de revogados da pasarela. Non significa eliminar a raíz de confianza. A raíz é a autoridade emisora de cada certificado de cliente que teña entregado, así que eliminala é outra operación cun alcance moito maior. A unidade de revogación aquí é un único certificado.

Paso 1: Fixe o certificado ao que se refire

Comece polo rexistro do certificado, non por un nome para mostrar. Azure mostra un nome descritivo que vostede mesmo escribiu, e esa etiqueta non ten por que coincidir co suxeito nin co dispositivo ao que se emitiu.

Outra comprobación antes de revogar: descubra cantos dispositivos o presentan. Se varios portátiles se construíron a partir de copias do mesmo PFX, revogar a pegada bloquéaos todos, e Azure non ten forma de distinguir o perdido do de reposto no caixón.

No cliente, Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, Thumbprint, NotAfter enumera o instalado para ese usuario, e Cert:\LocalMachine\My tamén paga a pena comprobalo porque o cliente VPN pode escoller de calquera dos dous almacéns. Compare a pegada co seu inventario de inscrición. Un certificado renovado ten unha pegada distinta aínda que o suxeito sexa idéntico.

Non necesita a chave privada do cliente nin un PFX protexido con contrasinal para ler a pegada dun certificado público. Calquera procedemento que esixa un dos dous copiouse doutra tarefa.

Paso 2: Engádao á lista de revogados da pasarela

No portal, abra a pasarela de rede virtual, despois a configuración Point-to-site e despois a sección de certificados revogados. Engada un nome descritivo que recoñeza dentro de seis meses e pegue a pegada como unha soa cadea continua sen os espazos.

Comprobe que pasarela está seleccionada antes de gardar, porque unha subscrición con varias pasarelas é exactamente onde isto sae mal. A guía de configuración de certificados de Microsoft indica que, unha vez completada a actualización, o certificado xa non se pode usar para conectar.

Confirme despois o valor almacenado en lugar de fiarse do aviso do portal: az network vnet-gateway show --name gw-p2s --resource-group rg-vpn --query "vpnClientConfiguration.vpnClientRevokedCertificates" mostra o que a pasarela garda realmente.

Paso 3: Verifique ambas as direccións

Probe a denegación co certificado revogado e logo probe que outro certificado baixo a mesma raíz aínda se autentica. Esa segunda proba é a que a xente se salta, e é a que detecta unha eliminación accidental da raíz ou un cambio de política que ninguén mencionou. Use un dispositivo onde poida ver que certificado se presenta. Un cliente con varios certificados pode usar en silencio un que funciona e facer que a súa revogación pareza rota.

Rexiste ambos os resultados no tícket. Unha revogación verificada só na dirección de denegación está medio verificada.

Paso 4: Sesións que xa están activas

O resultado documentado refírese a conexións novas. Non o converta na promesa de que cada túnel existente caerá no segundo en que se garde a lista. Se a retirada inmediata importa, use os controis que a súa configuración despregada ofrece realmente e comprobe a sesión concreta en lugar de supoñer.

Probe iso por separado da autenticación, porque ambas fallan en lugares distintos e deixan probas distintas.

Reversión e os atallos que cómpre evitar

Reverter significa quitar a pegada da lista de revogados e esperar a que remate a mesma actualización. Iso é seguro cando revogou a entrada equivocada e perigoso cando o certificado está realmente comprometido, así que decida primeiro en que caso está. Eliminar a raíz de confianza non é un atallo para un portátil perdido. Eliminar un perfil de VPN local nunha máquina non cambia o que acepta ningunha pasarela.

Se a identidade tamén se autentica nunha segunda pasarela, ambas necesitan o mesmo tratamento. A lista de revogados pertence a unha pasarela, non á subscrición.

Artigos relacionados