SECLEVEL=0 cura o síntoma, non o certificado

Unha conexión de OpenVPN falla, alguén atopa unha corrección dunha liña que engade SECLEVEL=0 e o túnel sobe. O que cambiou non foi o certificado nin o conxunto de cifrados; moveuse un limiar de aceptación en toda a biblioteca, e todo o que o proceso fai despois herda a nova fronteira. Paga a pena entendelo antes de que a mesma liña se copie en cada perfil da contorna.

Determine que biblioteca e que política están en vigor

SECLEVEL é un concepto de OpenSSL, así que a primeira pregunta é se a súa compilación usa OpenSSL. OpenVPN pode ligarse con máis dunha biblioteca criptográfica, e un axuste que se aplica a unha delas non ten sentido para as outras. Pregunte ao binario con que se construíu e despois pregunte á biblioteca que versión e configuración cargou:

openvpn --version | head -3
openssl version -a

Lea a saída da versión con atención, porque as distribucións parchean os valores predeterminados. Algunhas inclúen unha configuración do sistema que eleva o nivel mínimo por riba do predeterminado de upstream, e por iso o mesmo perfil compórtase de forma distinta en dúas máquinas con paquetes OpenVPN idénticos. A política efectiva é a que cargou o proceso en execución, non a do manual de upstream.

Despois separe as dúas capas que a xente confunde. OpenVPN ten os seus propios controis TLS, incluído un axuste de perfil de certificado e listas explícitas de cifrados, e estes sitúanse por riba do que impón a biblioteca. Baixar o nivel da biblioteca non cambia que cifrados enumera a súa configuración de OpenVPN, e estreitar a lista de OpenVPN non eleva o limiar da biblioteca. Saber que capa o rexeitou é o que impide que a corrección sexa unha conxectura.

Separe as tres cousas que poden rexeitarse

O primeiro candidato é material de identidade: un certificado cuxa chave é demasiado pequena ou cuxo algoritmo de sinatura a política xa non acepta. O segundo é un parámetro de intercambio de chaves, como un grupo que a política considera demasiado feble. O terceiro é un conxunto de cifrados que a política exclúe. Os tres poden producir un fallo de handshake, e só o texto do erro e a etapa de negociación os distingue.

Ningún deses tres é o cifrado da canle de datos. OpenVPN negocia o cifrado do túnel por separado do handshake TLS, así que unha conexión que ten éxito tras un cambio de nivel de seguridade non di nada sobre que cifrado protexe os seus datos. Se a pregunta que expón en realidade é sobre a confidencialidade dos datos, está mirando o dial equivocado.

Baixar o nivel amplía a aceptación das tres entradas á vez. Ese é o punto que a xente pasa por alto: a corrección que admite un certificado antigo tamén admite un grupo feble e un conxunto que quizais non pretendía permitir. Un só erro provocou o cambio, e o cambio é máis amplo que o erro. Esa asimetría é a razón pola que unha excepción acoutada é mellor que un valor predeterminado para toda a contorna.

Cambie a entrada, non o limiar

Conserve o erro exacto antes de tocar a configuración, incluída a etapa que o informou e o obxecto que nomeou. Un problema de certificado resólvese substituíndo o certificado por algo que a política actual acepte, o que normalmente significa reemitilo na autoridade en lugar de reinstalar o mesmo ficheiro.

Se a entrada rexeitada pertence a un par que vostede non controla, a conversa é co propietario dese par sobre material de substitución admitido. Baixar o seu propio limiar para acomodar un sistema que ninguén mantén traslada o custo deles a todos os que se conectan despois.

Onde o servidor aplica a política, comprobe se un axuste a nivel de OpenVPN é a causa real antes de culpar a biblioteca. Un perfil de certificado que esixe unha clase máis estrita da que o certificado despregado pode satisfacer fallará sexa cal sexa o nivel de seguridade, e eliminar ese perfil é un cambio máis estreito que desactivar as comprobacións da biblioteca.

Se debe baixalo, acóuteo e documénteo

Ás veces unha excepción de compatibilidade aprobada é a resposta correcta, sobre todo para un par antigo cun plan de retirada datado. Acóutea ao servizo que a necesita en lugar de a todo o servidor: un ficheiro de configuración por servizo ou unha configuración OpenSSL dedicada ten un raio de impacto menor que unha exportación no perfil global.

Anote catro cousas coa excepción: o axuste exacto, o propietario que a aprobou, os clientes afectados e a condición baixo a cal se retira. Unha excepción sen condición de retirada é un debilitamento permanente cunha xustificación temporal anexa.

A reversión debería ser un só paso que xa probou. Conserve a configuración anterior, aplique o cambio, confirme que o servizo arrinca e saiba exactamente que ficheiro restaurar se a seguinte conexión se comporta de forma distinta do esperado.

Verifique a identidade e a protección despois

Unha conexión correcta só demostra que as condicións revisadas a admitiron. Confirme que a verificación do nome de servidor e do par segue facendo o seu traballo, que o certificado en uso é o que pretendía despregar e que a canle de datos negociada coincide coa política que cre ter.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

A referencia dos niveis de seguridade de OpenSSL é explícita en que o marco aplica límites a chaves, sinaturas, grupos e conxuntos á vez, e en que o nivel cero permite todo o que comproba a función de retorno. Ese é o alcance do que cambiou, e é a frase que hai que citar cando alguén pregunta se a corrección era estreita.

O traspaso que sobrevive a unha auditoría di que política rexeitou que entrada, que se cambiou e que segue aceptándose como resultado. «Funciona con SECLEVEL=0» é unha observación sobre unha conexión, non unha avaliación de seguridade do despregamento.