Reputation: 1173
I have an application which exposes multiple WCF services (each a distinct facade for different client applications). Right now I'm managing a distinct certificate (created from our internal certificate server) per service (and I do this for multiple environments, e.g. dev, qa, staging, prod).
MSDN seems to suggest that this certificate is not only used for encrypting communications but also to "authenticate the service to clients", suggesting distinct certificates should be used so that one service is distinguished from another, even on the same server. However, I feel like I could "cheat" and use the same certificate (at least per environment) on all of the services -- essentially an application-level certificate. It would still ensure the services are from the proper application.
So how much of a "cheat" is this? Am I bending the rules too far? Obviously, it's my application and my services, so I'm free to do what I want -- but I want to keep from coloring too far outside the lines.
Upvotes: 1
Views: 802
Reputation: 1601
If you are not using the certificate for client certificate authentication or digital signing / verification and are only use the certificate for SSL encryption on the server side only, it is fine to use the same cert.
The clients would less certificates to 'trust' in their respective truststore/certificate stores.
However, if your security requirements call for more than server side SSL only, then it is best to use distinct certificates so servers can not impersonate each other.
I would recommend having a certificate for production and another that can be shared for your test, qa and dev environments. You can also use a self signed certificate for the non prod servers.
Upvotes: 1