Autofirmar certificados de clientes y distribuirlos, ¿es el siguiente un buen procedimiento?

Tengo un caso a mano como sigue:

1. Hay varios clientes en Internet (es decir, en un canal que no es de confianza), inicialmente en cientos pero creciendo en número.
2. Hay un servidor que realiza el procesamiento relacionado con estos clientes. Esta relación se establece antes de esto en otro lugar, digamos un portal web.
3. Los clientes deben poder conectarse al servidor a través de un software (no operado por humanos, por ejemplo, no un navegador) a través de Internet para cargar el material de manera que el canal esté cifrado y el servidor sepa qué cliente está conectado. .
4. No debe haber un problema que los clientes puedan afirmar que no han solicitado el material cuando se ha realizado una conexión y el material se ha transmitido. Como una edición relacionada con la pregunta de Thomas sobre no recibir material cuando lo hicieron: si tuviera que usar una contraseña simple aquí, ¿correría el peligro de que la contraseña se filtre más fácilmente que el certificado y otra persona que la use para obtener el material para ¿ser transferido? Sin embargo, he pensado en mitigar esta situación utilizando este "id de secuencia" (consulte el punto 6 en la siguiente lista), que probablemente ayude con o sin certificados.
5. El cliente nunca acepta conexiones entrantes. Solo los inicia a este conocido servidor.
6. Los que operan a los clientes generalmente no tienen sus propios certificados emitidos por alguna autoridad de certificación.
7. El programa procesador del servidor tiene un certificado emitido por una autoridad de certificación (por ejemplo, Thawte).

Pregunta: ¿Cuál sería una buena manera de lograr esto de manera segura y mantenible?

Por lo que sé, no hay ningún software PKI que pueda usar. He planeado lo siguiente:

1. Deje que los clientes descarguen el software de transferencia, por ejemplo, desde el portal. El portal puede incluir un archivo de configuración con un ID de cliente de algún tipo (y, digamos, una contraseña de un solo uso, ver punto 4).
2. Cuando el cliente instala el software de transferencia en el servidor, genera un certificado autofirmado con el ID de cliente en el CN. Por ejemplo, makecert -r -n "CN=SomeClientId" -pe -ss my .
3. Este software envía la huella digital del certificado generado al servidor junto con la identificación del cliente y usa una contraseña de un solo uso que obtuvo en otro lugar (ver punto 1).
4. El servidor almacena la huella digital junto con la ID del cliente.
5. Ahora, cuando el software de transferencia se conecta al servidor, puede verificar a qué cliente pertenece mediante la huella digital transmitida y el canal está protegido.
6. Para mayor seguridad, el servidor mantiene un número de secuencia que debe coincidir con el de un cliente de transferencia respectivo. Si se desincronizan, se sospecha una infracción y, como mínimo, el cliente necesita ir al portal para restablecer el contador y restablecer el software de transferencia (por ejemplo, establecer 0 en el archivo de configuración).

¿Esto parece un arreglo de sonido? ¿Habría uno mejor? Parece que si el acceso de cierto cliente necesita ser denegado, todo lo que se necesita es establecer una marca en la base de datos del servidor para indicar que una cierta huella digital ya no está permitida. Mientras navegaba por SE, encontré Cómo distribuir el cliente ¿Certificados sin exponer la clave privada? . Tomando el ejemplo de la respuesta de Thomas Pornin's , veo que podría alterar este proceso para que al generar el certificado. En cuanto a un ejemplo:

1. Cree el archivo someclient.inf con los parámetros apropiados (en Windows, de lo contrario, en otros sistemas operativos, por ejemplo, utilizando openssl).
2. Haga certreq -new someclient.inf request.csr para crear el archivo de solicitud.
3. Envíe el csr al servidor usando la contraseña de un solo uso.
4. El servidor recibe un archivo csr y crea el certificado, guarda la huella digital y devuelve el certificado.
5. El cliente instala opcionalmente el certificado con certreq -accept someclient.cer .

Otra pregunta: ¿Esto aportaría beneficios adicionales más allá del procedimiento que describí inicialmente (y es este un procedimiento sólido)?

Preguntas adicionales: No tengo claro cómo debería hacer la firma el servidor. ¿Cuál programa? ¿Con qué parámetros? Pero quizás estas deberían ser otras preguntas si este procedimiento es utilizable.

Como nota: podría ser que no tenga acceso a todo el software en la línea de comandos o al escribir el código se complique en el extremo del cliente, así que quizás deba recurrir a algo como a BouncyCastle .