Dous certificados OpenVPN, un só nome CCD: que fallou

Dous certificados de cliente con números de serie distintos, claves distintas e mesmo suxeitos completos distintos aínda poden acabar nun único ficheiro de política, porque o servidor non mira nada diso. Le un nome do certificado e abre o ficheiro de configuración de cliente correspondente. Se ambos os certificados levan o mesmo nome, o segundo herda a política do primeiro no momento en que se conecta.

A colisión créase na inscrición e só se descobre ao conectar, normalmente cando un dispositivo recibe un enderezo ou un conxunto de rutas que pertencen a outra máquina. Prevenilo significa acordar que campo asigna o servidor e logo reservar ese valor antes de que se asine nada.

As súas ferramentas de certificados non lle avisarán, porque a unicidade dentro de X.509 e a unicidade dun nome de política OpenVPN son requisitos distintos que aplican sistemas distintos.

O servidor busca un nome, non unha pegada

Coa asignación habitual baseada en certificados, o servidor toma o nome común do certificado presentado e busca un ficheiro con ese nome no seu directorio de configuración de clientes. Ese ficheiro pode fixar un enderezo estático, enviar rutas ou aplicar marcas de devasas por cliente. A busca é unha coincidencia de cadea cun nome de ficheiro, así que as maiúsculas, os espazos e a puntuación importan.

Algunhas implementacións intercambian deliberadamente a asignación para que un nome de usuario autenticado substitúa o nome común, e entón o nome de usuario é o que debe ser único. En calquera caso, o valor que selecciona a política é o valor que vostede reserva. Decida cal é antes de emitir nada; adiviñar tras unha colisión custa máis que preguntar.

Onde dúas autoridades coinciden no mesmo nome

Unha organización que acepta certificados de máis dunha autoridade emisora executa dous procesos de inscrición independentes que escriben nun mesmo espazo de nomes. As regras de unicidade propias de cada autoridade aplícanse dentro dela, de modo que ambas poden emitir lexitimamente para o mesmo nome común sen que ningunha note nada raro.

Os números de serie non axudan. X.509 esixe que un número de serie sexa único dentro do ámbito do seu emisor, o cal é unha propiedade da contabilidade desa autoridade e non unha identidade global do dispositivo. A comprobación do suxeito tamén é unha proba distinta da do nome común: dous certificados poden compartir un CN pero diferir na unidade organizativa e, por tanto, levar suxeitos distintos. Todas esas propiedades poden cumprirse mentres o servidor segue asignando ambos os certificados a un só nome de ficheiro.

A documentación de OpenSSL CA cobre o axuste unique_subject que rexe a opinión da súa propia base de datos, e o punto de partida honesto é ler a súa configuración de emisión en lugar de supoñer que se aplica algún valor predeterminado concreto de EasyRSA ou OpenSSL.

Reserve o nome efectivo antes de asinar

Manteña un rexistro que asigne un dispositivo ao seu rexistro aprobado e de aí a un nome de ficheiro de política exacto, de modo que un nome se asigne unha vez e siga asignado. A reserva debe ser atómica, o que na práctica significa unha restrición de base de datos ou un bloqueo arredor do paso de asignar e logo asinar, non unha folla de cálculo que editan dúas persoas.

Despois faga que a comprobación forme parte da emisión: rexeite asinar cando o nome solicitado xa exista e inclúa nesa comprobación a todas as autoridades nas que confía o servidor, porque un nome reservado pola outra autoridade está igual de ocupado. Unha solicitude rexeitada cun motivo claro sae máis barata que un tícket sobre un dispositivo que non deixa de recibir o enderezo estático doutro.

A renovación reutiliza un nome a propósito

Reemitir para un dispositivo existente debería producir un número de serie novo baixo o mesmo nome de política, e iso é unha reutilización lexítima e non unha colisión. O que hai que decidir de antemán é o solapamento: se os certificados vello e novo poden ser válidos á vez, e como se retira a credencial antiga.

Non recorra a duplicate-cn para resolver isto. Esa opción do servidor rexe as conexións simultáneas que presentan o mesmo nome; non bloquea a inscrición, e activala non fai que un enderezo estático compartido sexa seguro para dúas máquinas á vez. A revogación normalmente identifica un certificado por emisor e número de serie, así que retirar a credencial antiga non ten por que invalidar o seu substituto sempre que o servidor reciba e aplique os datos de revogación correctos.

Confirme a asignación coas ferramentas da máquina

Antes de entregar a un dispositivo a súa nova credencial, lea o nome do certificado tal como o fará o servidor e logo compáreo co ficheiro de política que espera que se seleccione.

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

O primeiro comando imprime os campos do suxeito por separado, o que fai visibles de inmediato unha unidade organizativa perdida ou un espazo duplicado. O segundo confirma que existe un ficheiro de política exactamente con ese nome, e o terceiro mostra se o servidor está configurado para permitir varias sesións cun mesmo nome. Execute os tres sobre un certificado novo antes de que saia do paso de inscrición, mentres un erro aínda custa unha sinatura en lugar dun incidente. Garde a saída co tícket para que a seguinte persoa vexa que nome recibiu realmente o servidor.

Remate cunha conexión real e compare o enderezo asignado e as rutas empurradas co ficheiro de política, e non co que pensaba escribir. Se dous dispositivos informan do mesmo enderezo estático, o rexistro ten unha colisión que ningunha inspección de certificados revelará xamais.