Manteña a súa CA raíz de VPN fóra de liña e aínda así emita certificados

A súa VPN responde conexións ás 3 da madrugada mentres a máquina que asina os seus certificados está apagada nun caixón. Un cliente que valida o certificado do servidor nunca contacta coa súa CA, así que a CA non precisa ser accesible para ningunha conexión. A parte que require planificación é o día en que hai que emitir, renovar ou revogar un certificado mentres a clave raíz permanece baixo chave.

Que valida realmente unha conexión

Cando o cliente OpenVPN se conecta, percorre a cadea de sinaturas desde o certificado folla do servidor ata un certificado de CA no que xa confía, comproba a xanela de validez e, se o perfil o indica, consulta unha lista de revogación. Nunca busca a súa CA raíz. O servidor fai a imaxe especular para os certificados de cliente. No momento da conexión só están presentes o certificado folla, o intermedio e o paquete de confianza que distribuíu antes.

O que realmente falla é unha de tres cousas: a clave de sinatura non está dispoñible na emisión, unha lista de revogación quedou obsoleta ou o paquete de confianza do cliente é máis antigo que a cadea que presenta o servidor. A primeira é un problema de proceso; as outras dúas son problemas de distribución. Ningunha delas esixe que a clave raíz estea en liña, e un servizo VPN xestionado que esixe un certificado privado para a autenticación do túnel só traslada a autoridade de sinatura ao provedor. Azure punto a sitio funciona ao revés: cárgase un certificado raíz e os certificados asinados baixo el considéranse de confianza, así que pregunte quen asina, quen valida e como se retira un certificado antes de tempo.

Construa a raíz nun host que nunca recibe un enderezo

Unha raíz fóra de liña úsase poucas veces: para asinar o certificado da CA intermedia e, máis adiante, para renovalo ou revogalo. Todo o demais ocorre un nivel máis abaixo. Faga o traballo da raíz nunha máquina mantida fóra da rede, a ser posible desde un sistema vivo, e anote quen estaba na sala. Os comandos supoñen OpenSSL 1.1.1 ou posterior, porque -addext non está dispoñible en compilacións antigas.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

Cree a intermedia no host de sinatura e leve só a súa solicitude á máquina fóra de liña. A raíz asina esa solicitude cunha lonxitude de ruta cero, de modo que a CA intermedia pode asinar certificados de punto final pero non pode crear outra CA por baixo. Esa única extensión impide que un host de sinatura comprometido acuñe unha autoridade equivalente á raíz. Use ECDSA só se todos os clientes executan OpenVPN 2.4 ou posterior; de non ser así, xere claves RSA e manteña o fluxo idéntico.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext contén basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign e authorityKeyIdentifier=keyid:always. Devolva a clave raíz á súa caixa forte antes de reconectar o host de sinatura. Se a raíz debe poder revogar a intermedia, asínea con openssl ca -config root.cnf -extensions intermediate_ca contra un index.txt de nivel raíz en lugar de openssl x509 -req, para que o número de serie quede rexistrado; despois envía a lista raíz resultante dentro do perfil do cliente, onde un crl-verify baseado en ficheiro a le ao arrincar. Envíe aos clientes un paquete cos dous certificados de CA; un certificado folla por si só non se validará contra a raíz.

Emita follas desde a intermedia, cunha base de datos

Asinar con openssl x509 -req funciona ata que necesite revogar, porque nada rexistra o número de serie. Use openssl ca desde o primeiro certificado para que o número de serie, a caducidade e o estado de revogación vivan nunha soa base de datos. Cree os ficheiros da base de datos unha vez e despois apunte alí a configuración:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

A liña de uso de clave supón unha clave ECDSA; engada keyEncipherment para RSA. Dea a cada cliente o seu propio nome común, porque OpenVPN identifica unha conexión por ese campo, e dous portátiles que comparten CN=vpn-client non se poden distinguir nos rexistros, nas regras de client-config-dir nin en ningún envío por usuario, e perde a atribución que fai defendible unha decisión de revogación. Emita e valide un certificado folla así:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

Manteña a clave de sinatura detrás dunha fronteira de política en lugar de copiala ao host de VPN: un servizo pequeno que autentica a solicitude, comproba o nome común contra unha lista de permitidos e devolve só o certificado. Rexistre cada número de serie; o rexistro é a única ligazón entre un certificado e a persoa que o solicitou.

Publique a revogación sen espertar a raíz

Os certificados de cliente revógaos a intermedia, nunca a raíz. A lista raíz só importa cando se queima unha intermedia. Apunte o servidor á lista intermedia con crl-verify. Unha CRL baseada en ficheiro cárgase ao iniciar o servizo, así que recárguea despois de cada rexeración; a forma de directorio le o estado no momento da conexión e custa un ficheiro por número de serie.

Revogue e rexere con dous comandos da mesma base de datos:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

Despois vixíe o reloxo. Unha CRL leva un campo de próxima actualización, e cando esa data pasa, un par que valida rexeita a lista en lugar de ignoralo. Rexerar mensualmente con default_crl_days = 30 deixa marxe; rexerar anualmente non. Unhas vidas de folla máis curtas son o control máis fiable, porque a revogación só se aplica onde se consulta a lista.

Probe a cadea e despois escriba a cerimonia

Reproduza catro fallos antes de confiar no deseño. Valide a cadea con openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Conéctese cun certificado de cliente caducado e confirme que o servidor o rexeita. Revogue un cliente de proba, recargue e confirme que a lista fai efecto. Adiante un día o reloxo dun host, porque un reloxo incorrecto pode emitir e rexeitar certificados que parecen válidos noutro lugar.

Unha raíz fóra de liña só é un control se existe o papeleo: dúas persoas nomeadas para a cerimonia, un rexistro de cada número de serie asinado, unha copia de seguridade cifrada gardada aparte da máquina e unha proba de restauración nun host illado. Asine unha intermedia de reposto durante a mesma cerimonia para que un host de sinatura morto non o obrigue a desbloquear a raíz á medianoite.

Antes de dalo por terminado, confirme cinco cousas: a clave raíz non está nun host en rede, a clave intermedia só vive no host de sinatura, o paquete do cliente leva os dous certificados de CA, a CRL ten unha próxima actualización futura e alguén posúe unha entrada de axenda para cada caducidade da cadea. Se falta unha, a configuración que parece fóra de liña só está indocumentada.