Error de certificado web en Access Server: el paquete CA vacío

Una página de inicio de sesión web que no carga mientras el DNS resuelve correctamente no suele ser un problema de DNS. Si el registro del servicio menciona una ruta vacía del paquete de certificados o un fallo de análisis PEM del certificado web y la clave privada, el listener HTTPS no tiene material utilizable y ninguna resolución de nombres ayudará. La reparación está en tres claves de configuración y no exige reemitir ni un solo certificado de cliente de la VPN.

A qué apuntan realmente las tres claves

El conjunto personalizado de certificados web se describe con cs.cert, cs.priv_key y cs.ca_bundle. Cada una guarda una ruta a un archivo y las tres las consume juntas el servicio web. Un certificado con la clave equivocada, o un archivo de cadena que en realidad es el certificado hoja, falla igual que un valor vacío: el listener no puede construir una cadena que el navegador acepte.

Estas claves pertenecen a la interfaz web de Admin y de Client. Están separadas de la PKI que emite certificados a los clientes de la VPN, así que sustituirlas no obliga a tocar los perfiles de cliente, la clave del servidor ni la autoridad de certificación. Tratar un fallo TLS web como motivo para reconstruir toda la PKI es el giro equivocado más caro que hay aquí.

Una distinción ahorra tiempo: un valor personalizado explícitamente vacío no es el mismo estado que no tener ninguna sustitución. El primero entrega al analizador una ruta vacía, que es lo que dice la línea del registro. El segundo deja Access Server con su propio material, y por eso algunos hosts arrancan bien tras una actualización y otros no.

Por qué un archivo que existe aún no se analiza

El analizador lee los bloques etiquetados dentro del archivo, no el nombre del archivo. Un .crt que contiene una clave privada, una cadena escrita como un solo bloque concatenado donde se esperaba un certificado, o un archivo guardado con la última línea truncada se rechazan. RFC 7468 define esas etiquetas legibles porque son lo único que dice al lector qué tipo de objeto sigue.

Examine los objetos, no las extensiones. En un host Linux, openssl x509 -noout -subject -issuer -in server.pem y openssl pkey -noout -check -in key.pem responden a las dos preguntas que importan, y comparar el módulo o la clave pública de ambos demuestra que van juntos. Mantenga la salida de la clave privada fuera de los tickets y de los registros de chat; la comprobación necesita una huella, no la clave.

Una ruta vacía merece la misma sospecha que un archivo mal formado, porque ambas producen errores posteriores vagos. Si el registro dice que la ruta del paquete está vacía, lea el valor guardado antes de depurar el archivo.

Volver al respaldo a propósito

La CLI de Access Server incluye una comprobación que toma las tres rutas como argumentos e informa si el conjunto es utilizable. Las rutas de abajo son ilustrativas; sustitúyalas por las ubicaciones protegidas del host:

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

Lea el resultado antes de tocar el servicio en marcha y solo después importe los valores y aplíquelos con la operación documentada para la versión instalada. El tutorial oficial de la CLI cubre la validación, la importación a la base de datos de configuración y el paso de aplicación, y su versión importa más que cualquier resumen.

Verifique el nombre que los usuarios escriben

Cuando el material personalizado está roto y todavía hay un respaldo integrado válido, la recuperación documentada es quitar las tres sustituciones personalizadas y dejar que Access Server use ese respaldo. Prepare primero el acceso a la consola y una copia de la configuración actual, porque el servicio que va a reiniciar es el que sirve la interfaz de administración.

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

Borrar toda la base de datos de configuración no es una reparación de certificado. Apunte a esas tres claves, aplique y confirme que la interfaz web responde. Los archivos autofirmados del directorio web-ssl son el recurso de respaldo, no un espacio de trabajo: sobrescribirlos o regenerarlos puede eliminar el único material que funcionaba.

Espere que el navegador muestre un certificado distinto después de que el respaldo surta efecto. Ese es el resultado correcto, y la respuesta es verificarlo con su proceso administrativo de confianza, no enseñar a los usuarios a saltarse cada advertencia.

La recuperación termina con un inicio de sesión correcto

La recuperación no termina cuando aparece un listener TCP. Valide el nombre DNS, la identidad del certificado y la cadena para ese nombre, luego cargue las interfaces web de Admin y de Client y complete un inicio de sesión. Una comprobación de puerto no demuestra nada de eso.

Access Server 3.1 y posteriores también pueden servir certificados web distintos por nombre de host SNI. Si eso está configurado, las claves predeterminadas y las entradas específicas del nombre son conjuntos separados, y probar por dirección IP muestra fácilmente un certificado distinto del que reciben los usuarios. Corrija y verifique el conjunto del nombre que fallaba, y repita la prueba de inicio de sesión antes de cerrar el incidente.