Dos certificats OpenVPN, un sol nom CCD: què va fallar

Dos certificats de client amb números de sèrie diferents, claus diferents i fins i tot subjectes complets diferents encara poden acabar en un sol fitxer de política, perquè el servidor no mira res d'això. Llegeix un nom del certificat i obre el fitxer de configuració de client corresponent. Si tots dos certificats porten el mateix nom, el segon hereta la política del primer en el moment que es connecta.

La col·lisió es crea en la inscripció i només es descobreix en el moment de connectar, normalment quan un dispositiu rep una adreça o un conjunt de rutes que pertanyen a una altra màquina. Prevenir-ho vol dir acordar quin camp assigna el servidor i després reservar aquest valor abans que se signi res.

Les vostres eines de certificats no us avisaran, perquè la unicitat dins de X.509 i la unicitat d'un nom de política OpenVPN són requisits diferents que apliquen sistemes diferents.

El servidor busca un nom, no una empremta

Amb l'assignació habitual basada en certificats, el servidor pren el nom comú del certificat presentat i busca un fitxer amb aquest nom al seu directori de configuració de clients. Aquest fitxer pot fixar una adreça estàtica, enviar rutes o aplicar marques de tallafocs per client. La cerca és una coincidència de cadena amb un nom de fitxer, així que les majúscules, els espais i la puntuació hi tenen importància.

Alguns desplegaments intercanvien deliberadament l'assignació perquè un nom d'usuari autenticat substitueixi el nom comú, i aleshores el nom d'usuari és el que ha de ser únic. En qualsevol cas, el valor que selecciona la política és el valor que reserveu. Decidiu quin és abans d'emetre res; endevinar després d'una col·lisió costa més que preguntar.

On dues autoritats encaixen en el mateix nom

Una organització que accepta certificats de més d'una autoritat emissora executa dos processos d'inscripció independents que escriuen en un sol espai de noms. Les regles d'unicitat pròpies de cada autoritat s'apliquen dins seu, de manera que totes dues poden emetre legítimament per al mateix nom comú sense que cap noti res estrany.

Els números de sèrie no ajuden. X.509 exigeix que un número de sèrie sigui únic dins l'àmbit del seu emissor, cosa que és una propietat de la comptabilitat d'aquesta autoritat i no una identitat global del dispositiu. La comprovació del subjecte també és una prova diferent de la del nom comú: dos certificats poden compartir un CN però diferir en la unitat organitzativa i, per tant, portar subjectes diferents. Totes aquestes propietats poden complir-se mentre el servidor encara assigna tots dos certificats a un sol nom de fitxer.

La documentació d'OpenSSL CA cobreix el paràmetre unique_subject que regeix l'opinió de la seva pròpia base de dades, i el punt de partida honest és llegir la vostra configuració d'emissió en lloc de suposar que s'aplica un valor per defecte concret d'EasyRSA o d'OpenSSL.

Reserveu el nom efectiu abans de signar

Porteu un registre que assigni un dispositiu al seu registre aprovat i d'allà a un nom de fitxer de política exacte, de manera que un nom s'assigni una vegada i romangui assignat. La reserva ha de ser atòmica, cosa que a la pràctica significa una restricció de base de dades o un bloqueig al voltant del pas d'assignar i després signar, no un full de càlcul que editen dues persones.

Després feu que la comprovació formi part de l'emissió: refuseu signar quan el nom sol·licitat ja existeixi i incloeu en aquesta comprovació totes les autoritats en què confia el servidor, perquè un nom reservat per l'altra autoritat està igualment ocupat. Una sol·licitud rebutjada amb un motiu clar surt més barata que un tiquet sobre un dispositiu que no para de rebre l'adreça estàtica d'una altra màquina.

La renovació reutilitza un nom a propòsit

Reemetre per a un dispositiu existent hauria de produir un número de sèrie nou sota el mateix nom de política, i això és una reutilització legítima i no una col·lisió. El que cal decidir per endavant és el solapament: si els certificats vell i nou poden ser vàlids alhora, i com es retira la credencial antiga.

No recurseu a duplicate-cn per resoldre això. Aquesta opció del servidor regeix les connexions simultànies que presenten el mateix nom; no bloqueja la inscripció, i activar-la no fa que una adreça estàtica compartida sigui segura per a dues màquines alhora. La revocació normalment identifica un certificat per emissor i número de sèrie, de manera que retirar la credencial antiga no ha d'invalidar-ne el reemplaçament sempre que el servidor rebi i apliqui les dades de revocació correctes.

Confirmeu l'assignació amb les eines de la màquina

Abans de lliurar a un dispositiu la seva credencial nova, llegiu el nom del certificat tal com ho farà el servidor i compareu-lo amb el fitxer de política que espereu que es triï.

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

La primera ordre imprimeix els camps del subjecte per separat, cosa que fa visible immediatament una unitat organitzativa esparriosa o un espai duplicat. La segona confirma que existeix un fitxer de política exactament amb aquest nom, i la tercera mostra si el servidor està configurat per permetre diverses sessions amb un sol nom. Executeu les tres sobre un certificat nou abans que surti del pas d'inscripció, mentre un error encara costa una signatura en lloc d'un incident. Guardeu la sortida amb el tiquet perquè la persona següent pugui veure quin nom va rebre realment el servidor.

Acabeu amb una connexió real i compareu l'adreça assignada i les rutes enviades amb el fitxer de política, i no amb el que pensàveu escriure. Si dos dispositius informen de la mateixa adreça estàtica, el registre té una col·lisió que cap inspecció de certificats no revelarà.