Al diseñar software alojado que interactúa con el servidor SQL de un cliente a través de TCP / IP y podemos ofrecer la opción de usar SSL / TLS. Una arquitectura que parece atractiva es donde generamos un certificado y luego lo colocamos en la instancia de SQL Server del cliente. Esta es una idea atractiva porque podemos asumir la responsabilidad de administrar el certificado.
Mi creencia actual es que si deseamos que el certificado sea de confianza y que SQL Server espere esto, no podemos hacerlo.
La razón por la que creo esto, es porque:
- No podemos importar en SQL Server un certificado con un FQDN diferente del servidor, es decir. con nuestro dominio en lugar de la del cliente.
- No podemos obtener un certificado de una CA con el FQDN del cliente.
- No podemos firmar un certificado secundario con el FQDN del cliente desde un certificado de raíz con nuestro FQDN. Esto derrota el propósito de certificados Imagina si pudiéramos crear certificados de Google. de nuestros propios certificados.
¿Tengo razón en mi evaluación de que esta arquitectura es imposible o hay una manera que he pasado por alto?