Emisión de certificados SSL para paquetes de software de automatización de dispositivos sin nombres de dominio

Creo que hay dos opciones aquí:

1. Certificado del lado del servidor: en este caso, debe obtener un certificado en su servidor. El nombre de host en lugar de la dirección IP es una necesidad y es muy preferible a través de Internet y le ahorrará a sus clientes un montón de problemas en el futuro. Hay un campo 'altSubject ...' en el certificado donde se puede ingresar una dirección IP y todavía se validará. Ahora, el cliente solo necesita cualquier cliente SSL y su certificado emitido por una CA de confianza para el cliente SSL funcionará.
2. Certificado del lado del cliente: usted puede ser el CA y emitir sus propios certificados a todos sus clientes y siempre que su servidor web establezca la validez del certificado de cliente entrante, esto prueba la identidad y la confidencialidad del transporte. Por supuesto, estos también pueden ser emitidos por CA. Este enfoque sería ligeramente preferible en su escenario, ya que podría revocar certificados que no pagan por su software y aún quieren usarlo :)

Su problema está en el lado del cliente. En una conexión SSL, el cliente debe usar la clave pública del servidor y, por lo tanto, debe asegurarse de que conoce la clave correcta ; el objetivo de un atacante sería inducir al cliente a utilizar una clave pública falsa. SSL define que el servidor envía su clave pública como parte de una cadena de certificados, que el cliente luego valida (el proceso complejo de verificación de firmas, fechas, estado de revocación y muchas extensiones). Pero un certificado válido no enseña mucho al cliente como a sí mismo; el cliente debe asegurarse de que conoce el certificado del servidor . Por lo tanto, el cliente debe buscar la "identidad esperada del servidor" en el certificado (válido).

Entonces tienes dos facetas importantes para el tema:

• El certificado del servidor debe ser válido contra un conjunto dado de anclajes de confianza (también conocidos como "certificados raíz") en los que el cliente confía en a priori .

• El certificado del servidor debe contener su identidad de manera que convenza al cliente.

En el contexto web habitual, el cliente es un navegador web, y el proveedor del navegador (o proveedor del sistema operativo) ya le ha proporcionado un gran conjunto de "CA raíz predeterminada". La coincidencia de identidad se describe en RFC 2818 : ya que el cliente intenta conectarse a una URL que incluye un nombre de host , el cliente buscará el mismo nombre de host en un par de lugares en el certificado (la parte CN del nombre del sujeto y en la extensión del Asunto Alt Name). Esto es donde los "nombres de dominio" tienen un impacto: el nombre que el cliente busca en el certificado es también el nombre que el cliente usa contra el DNS para saber dónde En realidad conectar.

Si controla el código del cliente y del servidor , puede elegir el mecanismo que desee. El cliente podría "conocer" la clave pública del servidor a priori (codificada en el código, o mediante un archivo de configuración local), e ignorar por completo el certificado del servidor. El cliente puede validar el certificado con respecto a cualquier conjunto de CA que considere adecuado, no necesariamente la misma CA que las que se incluyen en los navegadores web. Puede mantener el suyo propio: si eso es solo para sus servidores, CA emitirá un par de certificados por año como máximo, por lo que puede usar una tecnología bastante cruda (querrá mantenerla en un lugar seguro, pero puede usar software barato y procedimientos manuales; consulte, por ejemplo, EJBCA o incluso OpenSSL ). Y, por último, pero no menos importante, no es necesario buscar la identidad del servidor en los mismos lugares que lo que exige el RFC 2818. Por lo tanto, no existe un requisito estricto para jugar con nombres de dominio .

Si no controla el código del cliente (por ejemplo, el cliente es un navegador web o algún código de biblioteca existente que insiste en usar las mismas reglas que los navegadores web, es decir, RFC 2818), entonces Necesita, por definición, cumplir con los usos de la Web: enlace con nombres de dominio, certificados de una CA "reconocida" (una en la que confía el sistema cliente).

Un certificado SSL proporciona la autenticidad de un nombre común , que en el mundo de HTTPS es el nombre de dominio. Esencialmente, el navegador verifica un certificado basado en la validación del certificado y la comparación del nombre común con el dominio actual. Por lo tanto, para www.example.com , el certificado debe tener un nombre común que coincida con www.example.com . Es posible que esto no sea una coincidencia directa, ya que hay certificados de comodín de subdominio disponibles que coincidirán con *.example.com . Sin embargo, un certificado generado para foobar.com nunca podrá coincidir con barfoo.com , o viceversa. Tenga en cuenta que la implementación es estrictamente dentro del navegador.

Sin embargo, en una implementación de cliente personalizada, puede imponer el nombre común de la forma que considere más adecuada. Puede ser el nombre real de una persona, un GUID, una dirección IP, etc. De hecho, los datos almacenados en el campo del nombre común no son importantes, pero la aplicación de esos datos contra una identidad real sí lo es. La razón por la que se usa un nombre de dominio es porque un dominio puede representar una variedad de direcciones IP. Los registros DNS para un host en particular pueden tener un registro A (dirección IPv4), un registro AAAA (dirección IPv6), un registro MX (servidor de correo), etc. De hecho, puede tener más de uno A de registro, con el fin de equilibrar la carga en varios hosts físicos. Además, las direcciones IP pueden ser dinámicas y se reasignan con frecuencia. Esto significa que un sitio único no siempre puede ser identificado por su dirección IP. Generar y mantener certificados SSL para todas las direcciones IP asociadas con su dominio sería engorroso y requeriría que vuelva a emitir nuevos certificados si la dirección IP cambia. Esto dista mucho de ser ideal, por lo que tener un solo certificado SSL para autenticar el dominio es una mejor solución.

Lo que no entiendo es por qué no tendría sus servidores asociados con un nombre de dominio. La emisión manual de certificados SSL a direcciones IP será dolorosa, y será mucho más difícil conseguir que una CA notable los firme por usted. También le pediré que envíe actualizaciones de productos si alguna vez cambian las IP de su servidor, en lugar de solo modificar el registro de DNS usted mismo. Si sus clientes necesitan acceder a su servidor desde un dispositivo nuevo, tendrán que escribir su IP y enviarla, en lugar de simplemente memorizar un nombre de dominio fácil. Además, puede recoger dominios por casi nada, tan solo $ 10 / año en algunos casos.