Error de certificat web a l^Access Server: el paquet CA buit

Una pàgina d'inici de sessió web que no carrega mentre el DNS es resol correctament no sol ser un problema de DNS. Si el registre del servei esmenta un camí buit del paquet de certificats o un error d'anàlisi PEM del certificat web i la clau privada, l'oient HTTPS no té material utilitzable i cap resolució de noms no l'ajudarà. La reparació és en tres claus de configuració i no requereix reemetre cap certificat de client de la VPN.

A què apunten realment les tres claus

El conjunt personalitzat de certificats web es descriu amb cs.cert, cs.priv_key i cs.ca_bundle. Cadascuna desa un camí a un fitxer i les tres les consumeix alhora el servei web. Un certificat amb la clau equivocada, o un fitxer de cadena que en realitat és el certificat fulla, falla igual que un valor buit: l'oient no pot construir una cadena que el navegador accepti.

Aquestes claus pertanyen a la interfície web d'Admin i de Client. Són separades de la PKI que emet certificats als clients de la VPN, així que substituir-les no obliga a tocar els perfils de client, la clau del servidor ni l'autoritat de certificació. Considerar una fallada TLS web com a motiu per reconstruir tota la PKI és el gir equivocat més car que hi ha aquí.

Una distinció estalvia temps: un valor personalitzat explícitament buit no és el mateix estat que no tenir cap substitució. El primer dona al parser un camí buit, que és el que diu la línia del registre. El segon deixa l'Access Server amb el seu propi material, i per això alguns amfitrions arrenquen bé després d'una actualització i d'altres no.

Per què un fitxer que existeix encara no es pot analitzar

El parser llegeix els blocs etiquetats dins del fitxer, no el nom del fitxer. Un .crt que conté una clau privada, una cadena escrita com un sol bloc concatenat on s'esperava un certificat, o un fitxer desat amb l'última línia truncada es rebutgen. RFC 7468 defineix aquestes etiquetes llegibles perquè són l'única cosa que diu al lector quin tipus d'objecte segueix.

Examineu els objectes, no les extensions. En un amfitrió Linux, openssl x509 -noout -subject -issuer -in server.pem i openssl pkey -noout -check -in key.pem responen les dues preguntes que importen, i comparar el mòdul o la clau pública dels dos demostra que van junts. Mantingueu la sortida de la clau privada fora dels tiquets i dels registres de xat; la comprovació necessita una empremta, no la clau.

Un camí buit mereix la mateixa sospita que un fitxer malmès, perquè tots dos produeixen errors posteriors vagues. Si el registre diu que el camí del paquet és buit, llegiu el valor desat abans de depurar el fitxer.

Torneu al recurs de reserva a propòsit

La CLI de l'Access Server inclou una comprovació de validació que pren els tres camins com a arguments i informa si el conjunt és utilitzable. Els camins de sota són il·lustratius; substituïu-los per les ubicacions protegides de l'amfitrió:

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

Llegiu el resultat abans de tocar el servei en marxa i només després importeu els valors i apliqueu-los amb l'operació documentada per a la versió instal·lada. El tutorial oficial de la CLI cobreix la validació, la importació a la base de dades de configuració i el pas d'aplicació, i la seva versió importa més que qualsevol resum.

Verifiqueu el nom que els usuaris escriuen realment

Quan el material personalitzat és trencat i encara hi ha un recurs de reserva integrat vàlid, la recuperació documentada és treure les tres substitucions personalitzades i deixar que l'Access Server faci servir aquest recurs. Prepareu primer l'accés a la consola i una còpia de seguretat de la configuració actual, perquè el servei que reiniciareu és el que serveix la interfície d'administració.

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

Esborrar tota la base de dades de configuració no és una reparació de certificat. Apunteu a aquestes tres claus, apliqueu i confirmeu que la interfície web respon. Els fitxers autosignats del directori web-ssl són el recurs de reserva, no un espai de treball: sobreescriure'ls o regenerar'los pot eliminar l'únic material que funcionava.

Espereu que el navegador mostri un certificat diferent després que el recurs de reserva entri en vigor. Aquest és el resultat correcte, i la resposta és verificar-lo amb el vostre procés administratiu de confiança, no ensenyar els usuaris a saltar-se cada avís.

La recuperació no acaba fins a un inici de sessió correcte

La recuperació no s'acaba quan apareix un oient TCP. Valideu el nom DNS, la identitat del certificat i la cadena per a aquest nom, després carregueu les interfícies web d'Admin i de Client i completeu un inici de sessió. Una comprovació de port no demostra res d'això.

L'Access Server 3.1 i posteriors també poden servir certificats web diferents per a cada nom d'amfitrió SNI. Si això està configurat, les claus per defecte i les entrades específiques del nom són conjunts separats, i provar per adreça IP pot mostrar fàcilment un certificat diferent del que reben els usuaris. Repareu i verifiqueu el conjunt del nom que fallava i repetiu la prova d'inici de sessió abans de tancar l'incident.