In designing hosted software that interfaces with a client's SQL Server over TCP/IP and we may wish to offer the option of using SSL/TLS. One architecture that seems attractive is where we generate a certificate and then put it into the customer's SQL Server instance. This is an attractive idea because we can take responsibility for managing the certificate.

My current belief is that if we wish the certificate to be trusted, and SQL Server will expect this, then we can not do this.

The reason I believe this, is because:

  1. We can not import into SQL Server a certificate with a FQDN different from the server, ie. with our domain instead of the customer's.
  2. We can not obtain a certificate from a CA with the customer's FQDN.
  3. We can not sign a sub certificate with the customer's FQDN from a root certificate with our FQDN. This defeats the purpose of certificates. Imagine if we could create Google certificates from our own certificates.

Am I correct in my assessment that this architecture is impossible or is there a way that I have overlooked?

1 Answer 1


You can create your own CA first and then supply the CA certificate to the SQL server (your OEM version). Any future certificate that you (as the CA) generate for the customer will then be trusted by the SQL server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .