Erro de certificado web en Access Server: o paquete CA baleiro

Unha páxina de inicio de sesión web que non carga mentres o DNS resolve correctamente adoita non ser un problema de DNS. Se o rexistro do servizo menciona unha ruta baleira do paquete de certificados ou un fallo de análise PEM do certificado web e da clave privada, o oínte HTTPS non ten material utilizábel e ningunha resolución de nomes axudará. A reparación está en tres claves de configuración e non require reemitir ningún certificado de cliente da VPN.

A que apuntan realmente as tres claves

O conxunto personalizado de certificados web descríbese con cs.cert, cs.priv_key e cs.ca_bundle. Cada unha garda unha ruta a un ficheiro e as tres consúmeas xuntas o servizo web. Un certificado coa clave equivocada, ou un ficheiro de cadea que en realidade é o certificado folla, falla igual que un valor baleiro: o oínte non pode construír unha cadea que o navegador acepte.

Estas claves pertencen ás interfaces web de Admin e Client. Están separadas da PKI que emite certificados aos clientes da VPN, así que substituílas non obriga a tocar os perfís de cliente, a clave do servidor nin a autoridade de certificación. Tratar un fallo TLS web como motivo para reconstruír toda a PKI é o erro máis caro posíbel aquí.

Unha distinción aforra tempo: un valor personalizado explicitamente baleiro non é o mesmo estado que non ter ningunha substitución. O primeiro entrega ao analizador unha ruta baleira, que é o que di a liña do rexistro. O segundo deixa Access Server co seu propio material, e por iso algúns servidores arrincan ben tras unha actualización e outros non.

Por que un ficheiro que existe aínda non se analiza

O analizador le os bloques etiquetados dentro do ficheiro, non o nome do ficheiro. Un .crt que contén unha clave privada, unha cadea escrita como un só bloque concatenado onde se esperaba un certificado, ou un ficheiro gardado coa última liña truncada rexéitanse. RFC 7468 define esas etiquetas lexíbeis porque son o único que lle di ao lector que tipo de obxecto segue.

Examine os obxectos, non as extensións. Nun servidor Linux, openssl x509 -noout -subject -issuer -in server.pem e openssl pkey -noout -check -in key.pem responden as dúas preguntas que importan, e comparar o módulo ou a clave pública de ambos demostra que van xuntos. Manteña a saída da clave privada fóra dos tíckets e dos rexistros de chat; a comprobación necesita unha impresión dixital, non a clave.

Unha ruta baleira merece a mesma sospeita que un ficheiro mal formado, porque ambas producen erros posteriores vagos. Se o rexistro di que a ruta do paquete está baleira, lea o valor gardado antes de depurar o ficheiro.

Volver á reserva a propósito

A CLI de Access Server inclúe unha comprobación que toma as tres rutas como argumentos e informa se o conxunto é utilizábel. As rutas de abaixo son ilustrativas; substitúaa polas localizacións protexidas do servidor:

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

Lea o resultado antes de tocar o servizo en marcha e só despois importe os valores e aplíqueos coa operación documentada para a versión instalada. O titorial oficial da CLI cobre a validación, a importación na base de datos de configuración e o paso de aplicación, e a súa versión importa máis ca calquera resumo.

Comprobe o nome que os usuarios escriben

Cando o material personalizado está roto e aínda hai unha reserva integrada válida, a recuperación documentada é quitar as tres substitucións personalizadas e deixar que Access Server use esa reserva. Prepare primeiro o acceso á consola e unha copia da configuración actual, porque o servizo que vai reiniciar é o que serve a interface 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 a base de datos de configuración non é unha reparación de certificado. Apunte a esas tres claves, aplique e confirme que a interface web responde. Os ficheiros autosinados do directorio web-ssl son o recurso de reserva, non un espazo de traballo: sobrescribilos ou rexeneralos pode eliminar o único material que funcionaba.

Espere que o navegador mostre un certificado distinto despois de que a reserva entre en vigor. Ese é o resultado correcto, e a resposta é verificalo co seu proceso administrativo de confianza, non ensinar os usuarios a saltar cada aviso.

A recuperación remata cun inicio de sesión correcto

A recuperación non remata cando aparece un oínte TCP. Valide o nome DNS, a identidade do certificado e a cadea para ese nome, despois cargue as interfaces web de Admin e de Client e complete un inicio de sesión. Unha comprobación de porto non demostra nada diso.

Access Server 3.1 e posteriores tamén poden servir certificados web distintos por nome de servidor SNI. Se iso está configurado, as claves predeterminadas e as entradas específicas do nome son conxuntos separados, e probar por enderezo IP mostra facilmente un certificado distinto do que reciben os usuarios. Corrixa e verifique o conxunto do nome que fallaba e repita a proba de inicio de sesión antes de pechar o incidente.