What is the danger of hosting your SSL certificate yourself?

Question

I have Active Directory Certificate Services on my server, which makes it possible for me to deliver an SSL certificate for the websites hosted on the same server.

I know that normally, I need to acquire a certificate from a known certification authority. But I have my reasons¹ for not doing it. That's not the point.

The question is, what could be (if any) the security risk of hosting the certificate yourself, instead of using the services of a known authority?

---

^{¹ The reasons being that (1) I'm a geek and it's fun to create your own certificates, that (2) I want to test Certificate Services, and that (3) I don't care about browsers complaining about the fact that they don't know about me, because I will be the only one to use HTTPS.}

Answer 1

Using an SSL certificate for your websites primarily gets you two things:

1. Identity proofing that your website is who it says it is
2. 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.

Answer 2

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.

Answer 3

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.

Answer 4

Hosting your own certificate is certainly not a problem.

I guess you mean issuing your own certificate (whether self-signed or via your own CA). You would of course have to protect its private key, but that's the case for any server certificate. If you're using your own CA, its private key doesn't even have to hosted on any server in principle.

Whether you choose to use your own CA (or a self-signed cert) instead of a commercial CA certainly isn't a security risk (it might actually improve the trust you have in that server). However, as I was saying in this related answer, the choice of CA always has to be considered from the user's point of view. As a service provider it only matters because you want the certificate of your service to be trusted by its user.

The advantage of the commercial CAs here is that they're embedded in most browsers by default, which means that the users don't need extra settings to trust your own CA. It's just the easy route because users who don't know anything about certificates don't have to ask questions (which is not great, but convenience wins...)

Answer 5

Assuming this is for use only on your private network:

You can also run your own local CA. Then you generate certificate signing requests and sign them with the computer you set up as your CA. Then you give all your computers on the network the CA certificate so they trust your CA. This way you can issue your own certs for your own use and you will not get that annoying warning by your browser.

http://www.g-loaded.eu/2005/11/10/be-your-own-ca/

Answer 6

One security issue is that you can't revoke a self-signed certificate if it is compromised.

In your specific scenario, though, you control all the clients as well as the server, so this is not going to be a problem.

And of course, since you're doing this to have geeky fun, you're very likely to go the whole hog and set up a private CA, as others have suggested: in which case you will be able to revoke.

Answer 7

I don't care about browsers complaining about the fact that they don't know about me, because I will be the only one to use HTTPS.

The security risk (assuming your CA cert is not installed on the clients) is that you're now open to man-in-the-middle attacks. Someone can pretend to be the server, tunnel all communications to the actual server, and the client will have no idea it's talking to the wrong server. In other words, you have practically no security. There's a reason the browser complains. If security is not an issue then you have no problem :-)

If you point your browser at your bank's web site and it presented a self signed certificate (or any unverifiable certificate) would you type in your credentials? Bad idea.

Having some trusted root certificate is the way clients verify the servers are who they claim they are which is a critical component of a public key system (assuming the parties can not exchange the public keys through some secure means.)

Note that you can issue your own certs that still have a chain of trust to a known CA, not every cert you use needs to be issued by a known CA, all you need is a chain of trust to that CA. So you're basically acting as an "intermediate" CA. As others have noted, you can also have your own "root" CA and issue certs signed by that. The key though is to have some way of pushing that root cert to the clients, then the browser will not warn and you will have the security you desire...