Nebula necesita tres archivos: CA, certificado de host y clave de host

Si le das a alguien un directorio de Nebula, normalmente copiará todo, incluido el archivo que nunca debería salir de tu estación de trabajo. La confusión es comprensible, porque los tres archivos del bloque PKI de un host se parecen y dos de ellos son certificados. Cada uno responde a una pregunta distinta, y solo dos pertenecen al nodo. Clasifícalos por función antes de copiar nada.

Tres archivos, tres trabajos distintos

El certificado de CA es un ancla de confianza: le dice a un host en qué autoridades confiar cuando otro host presenta su identidad. El certificado de host es la credencial propia del nodo, firmada por esa autoridad. La clave de host es la mitad privada correspondiente, y pertenece exactamente a una máquina. Un nodo con el certificado de CA y su propio par puede unirse a la overlay y demostrar quién es. Un nodo con la clave de otra persona también puede hacerse pasar por ella, y ese es el fallo que esta disposición existe para evitar.

Copiar un directorio de host que funciona a una segunda máquina no es, por tanto, un atajo. Es una identidad duplicada con un resultado previsible.

La clave de firma nunca viaja

La clave de firma de la CA no forma parte de ninguna configuración de host. Crea identidades nuevas, y quien la tiene puede emitir un certificado para cualquier dirección de la overlay y cualquier grupo. Los pares solo necesitan el certificado de CA público para verificar firmas, así que la mitad privada no tiene ningún papel en un cliente. Guárdala en la máquina donde se emiten los certificados y trata una copia accidental como un incidente, no como una comodidad.

Si varias personas necesitan emitir certificados, dales un proceso en lugar de una copia de la clave. Una clave de firma compartida en un portátil es una autoridad que nadie puede auditar ni revocar.

Qué hay dentro de un certificado de host

Un certificado de host vincula a una clave mucho más que un nombre de archivo. Lleva la dirección del nodo en la overlay, su nombre y su pertenencia a un grupo, todo firmado para que un par pueda decidir si lo acepta. Por eso cambiar el nombre de un host significa emitir un certificado nuevo y no editar una línea de configuración.

nebula-cert print -path host.crt muestra lo que se emitió realmente. Léelo antes de suponer que el certificado lleva la dirección que pretendías.

Recargar no siempre basta

Algunos ajustes de PKI se recargan con una señal, y otros no. Un certificado cuya dirección en la overlay ha cambiado es el caso clásico que exige reiniciar el proceso en lugar de recargarlo.

Confirma qué rutas abrió realmente el proceso en ejecución, no solo qué rutas nombra el archivo de configuración. Luego cambia una credencial, verifica la conectividad y los registros, y solo entonces toca la siguiente. Una recarga que parece funcionar mientras el certificado antiguo permanece en memoria produce una discrepancia que parece un problema de enrutamiento. Reiniciar es barato; depurar una identidad que la mitad de la overlay todavía ve a la antigua no lo es.

Eliminar una identidad exige una lista de bloqueo

Sustituir una credencial perdida o expuesta tiene dos mitades. El certificado nuevo restaura el acceso, y la identidad antigua debe dejar de ser aceptada. Son operaciones separadas, y hacer solo la primera deja válida la credencial comprometida.

La lista de bloqueo es un archivo que distribuyes a los hosts, no algo que un lighthouse envíe por su cuenta. Planifica cómo llega a cada nodo, incluidos los que hoy están desconectados, y anota qué huellas has bloqueado. Rota la clave en la máquina emisora y guarda los datos del certificado nuevo con el registro del host. Una revocación que solo existe en la máquina que editaste no es una revocación.