Pot una cadena de certificats del servidor anul·lar el magatzem de confiança del client?

Un navegador mostra un avís de certificat en un lloc la cadena del qual és completa, i el primer instint és arreglar el servidor. Normalment el servidor presenta exactament el que hauria de presentar. El client decideix quines arrels accepta, i cap disposició de certificats intermedis pot canviar aquesta decisió des de l’altre extrem de la connexió. Aquest límit explica la major part del que sembla un problema de certificat.

La validació s’executa al client, amb les arrels del client

La validació de camí pren els certificats presentats i construeix una cadena fins a una arrel de confiança que el sistema validador ja té. RFC 5280 descriu aquest model, i situa la selecció de l’arrel en la implementació local i no en el servidor. Una aplicació pot afegir-hi la seva pròpia política: una clau fixada, un magatzem de confiança empresarial, o una comprovació d’identitat més estricta. La llista de certificats que envia un servidor és una prova oferta a aquest procés, mai una instrucció adreçada a ell.

Així, una cadena completa demostra que el servidor té les peces. No demostra que el client les acceptarà.

Per veure què envia realment el servidor, executeu openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts i compteu els certificats a la sortida. Una cadena incompleta aquí és una correcció del costat del servidor. Una cadena completa trasllada la qüestió al client i a les seves arrels, on el servidor no té vot.

Què canvia realment la inspecció de TLS

Un aparell d’inspecció acaba la sessió TLS del costat del client i obre una sessió separada cap al servei real. Llavors el client valida el certificat de l’aparell, que ha d’enllaçar amb una arrel en què el client confiï. Per això els dispositius gestionats reben l’arrel d’inspecció mitjançant la gestió de dispositius, i per això un dispositiu personal sense ella mostra un avís.

La disposició és deliberada i local. Res de la cadena del servidor original no pot forçar un navegador no gestionat a acceptar la identitat substituta, i res no impedeix que un dispositiu gestionat ho faci.

La terminació de VPN no és desxifratge d’HTTPS

Una capa VPN transporta paquets entre un client i una passarel·la. Treure-la, o llegir-ne la configuració, no exposa cap càrrega HTTPS a dins.

La sessió TLS continua executant-se entre el navegador i el servidor web, amb les mateixes regles de validació, tret que alguna cosa la terminui explícitament. Confondre les dues capes produeix una petició a l’administrador de la VPN perquè subministri el certificat, quan el certificat en qüestió pertany a un proxy d’inspecció o al lloc mateix. Pregunteu quin component presenta el certificat abans de canviar cap magatzem de confiança.

Fixeu les expectatives en el component que controleu

Si gestioneu l’aplicació i el seu client, definiu alhora la identitat de servei esperada, els emissors acceptats i qualsevol requisit de fixació o autenticació de client. Planifiqueu la renovació i la recuperació perquè un canvi legítim de certificat no esdevingui una interrupció. Si només gestioneu el servidor públic, documenteu quina autenticació exigiu i quins entorns de client suporteu. Enviar una cadena preferida no certifica el dispositiu d’un desconegut.

En equipament gestionat, resoleu la incompatibilitat amb els responsables de l’aplicació i de la xarxa. Desactivar la verificació, afegir una arrel sense explicació o intentar sobreviure a una política d’inspecció no estableix la relació d’igual a igual prevista.

Proveu el resultat en un perfil de client net, no en la màquina on ja s’ha afegit una excepció. Aquesta és l’única comprovació que mostra què experimentarà un dispositiu nou.