What is the danger of hosting your SSL certificate yourself?
Using an SSL certificate for your websites primarily gets you two things:
- Identity proofing that your website is who it says it is
- Stream encryption of the data between the webserver and the client
By doing what you propose, which is normally called self-signing, prevents you from relying on the identity proofing. By using a known trusted CA the client can follow the signature chain from the certificate you present up to a root level trusted CA and gain some confidence that you are who you say you are. (It should be noted that this trust is really more like faith as CA compromises do occur and some CAs take proofing much more seriously than others.)
You will, however, still have the data encryption. So if you don't need the trust aspect, then you should be fine. Personally, I have several web sites and webapps at home that I use self-signed certificates for. Since I'm the only user, I can reasonably verify the certificate manually without the need for a 3rd party to tell me that the computer under my own desk is really the computer under my desk.
I assume that you mean issuing or signing your own certificates, not actually hosting them.
From a pure security (encryption/data confidentiality) point of view, an X.509c3 certificate is an X.509c3 certificate and the offer the same security for the same number of bits. So a 2048-bit cert issued by Verisign is as secure as a 2048-bit cert issued by yourself.
From a trust (identity) point of view - to the average internet user Verisign or another 3rd party may be seen as more trusted. If you are doing this for a close community that already trusts you, though, then this item is also a wash.
From a risk management point of view, you need to decide whether you or a third party have a greater possibility of a screwup and whether the benefits outweigh the costs.
The right way to do this is to run your own private CA. You can then use Active Directory to push the (self-signed) CA's public key to all of the client computers on your network. If you do this right, then no one should see any cert warnings from their browsers.
This is a perfectly reasonable approach for use on an internal network (e.g., an enterprise network), if it is not public-facing. Here are the risks:
Your security is only as good as the security of your private CA operation. If the private key for the private CA is leaked to an attacker, or an attacker breaches the security of the system where the CA's private key is stored, all your clients now become vulnerable to undetectable man-in-the-middle attacks. That would be bad. Similar risks apply if your private CA ever signs an untrusted public key. These are issues that major CAs have to deal with; if you become your own CA, you'll have to deal with them, too.
Your security is only as good as the security of Active Directory. If a system administrator with control over the Active Directory service has his account hacked, then attacks on all your clients again become possible. So make sure your Active Directory service is well secured.
If you have any users who are connecting to your internal web service from a machine you don't administer and that isn't connected via your Active Directory, then they will see cert errors from their browser, because their browser won't have received your private CA's public key through Active Directory. That's bad, because then those users will have no way to verify the authenticity of your internal web service and no way to protect themselves from a man-in-the-middle attack. It is also bad, because it trains those users to ignore cert errors, which may make them vulnerable in the rest of their use of the Internet.
This is a growing risk for many organizations today, given the trend towards "bring-your-own-devices" that many companies are embracing. For instance, many employees want to access internal web services from their own smartphones, iPads, etc., and to save costs, many companies want to let them do so. Those devices won't be managed through your Active Directory and thus will introduce this sort of risk.
All of these risks can be managed through appropriate processes, but you do have to know about the risks and put appropriate processes in place to address them.