Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm currently using a self signed certificate for in-house development purposes and want to make sure I am aware of any real security risks.

Here's how I set things up.

Root Certificate

  1. Created a Root CA .pvk and .cert
  2. Installed the CA root .cert on my local machine under "Trusted Root Certification Authorities"
  3. Installed the CA root .cert on my development hosting server under "Trusted Root Certification Authorities"

Certificate for My Site

  1. Generated another certificate from the root .cert and .pvk
  2. Imported the new certificate as a .pfx file on the hosting server
  3. Setup the hosting server to use the new cert for my site in IIS

Other than the private key for the root certificate, are there any other pieces of data that pose a security risk if someone were to get a hold of them?

share|improve this question
    
This is not really about "self-signed certificate risks", but rather about the risks associated with creating your own CA. –  Bruno Jan 12 '12 at 18:28
    
That's a question for security.SE –  Hubert Kario Feb 2 '12 at 8:51

2 Answers 2

up vote 2 down vote accepted

Your site certificate (+ private key) should be treated like any site certificate. If someone was to get hold of the private key, they would be able to impersonate your website. There is little difference in the way you would have to trust the hosting service for a certificate issued by a commercial CA.

The risks here are mitigated by the fact that, since you've created your own CA, few people will trust that CA by default. It's a risk that's effectively limited to those who've opted in to trust your CA.

The same applies to the CA private key. Someone who gets hold of its private key could issue any certificate.

The biggest problems comes from the fact that user interfaces tend to treat all trusted CAs equally (unless EV certs), or very similarly if the user doesn't pay attention. As a result, if an attacker (a) had your CA's private key and (b) knew a user who trusts this CA cert to target, they could create a certificate valid for any website they want.

Your risk assessment should take into account who will opt in to trust this in-house CA. Commercial CAs tend to have strict policies regarding the protection of their private keys (typically, non-extractible storage on smart-cards or similar): this is often a requirement to be approved for inclusion in most browsers.

More specifically about "other pieces of information". It may be important, when designing a CA, to have a policy regarding what attributes and how Subject DNs are structured for example. I have known some CAs that made a point never to disclose the user's identity explicitly in the certificate (which is usually public and often visible during the handshake to an eavesdropper), so the Subject DN was just an internal ID, known to the CA (and possibly tied up to an actual name between the service and the CA by an encrypted back channel or similar mechanism).

share|improve this answer
    
That's close to the detail I was looking for. So the private key of the site certificate (not the CA) resides on the webserver that is using the certificate, thus if the webserver were compromised, someone could potentially get the private key and generate a new certificate, or would they have to have the CA private key to do this? –  bingles Jan 12 '12 at 22:22
    
@user20489, someone who gets hold of the server's certificate private key could impersonate the server. They wouldn't be able to impersonate the CA itself, though (so they wouldn't be able to issue new certs). You could potentially implement a CRL/OCSP mechanism to be able to revoke certificates for which the private keys have been compromised. This is quite demanding and can be overkill for a test/dev CA, but may be worth it if this CA really gets used officially within your institution. –  Bruno Jan 12 '12 at 22:31
    
Thanks that helps. –  bingles Jan 12 '12 at 22:43

An in-house self-signed cert is not a risk as long as people are aware it's a self-signed cert. The biggest risk they pose is for clients.

For instance, when you distribute to a client and make the initial connection you'll want to make sure they verify that it's valid, but other than that the only benefit to using a 3rd party provider is you don't have to worry about an attacker pretending to be your server, but that means you would have been hacked to begin with and have a lot of other issues as well.

So, the biggest security risk is not informing people it's a self-signed cert and to verify it's location. At least, in my opinion. Also, they are not managed by a CA, so you can't issue certificate revocations and would have to actually remake the key if things were compromised-- but for an in house system, I really wouldn't be worried about this.

share|improve this answer
    
You wrote the answer I was trying to finish, and phrased it better to boot. +1 –  Jeff Albert Jan 12 '12 at 18:16
1  
Also, lots of clients will refuse to install your root certificate because they don't trust you to not be compromised. The major CAs have had a rough track record in the last few years, but most people still trust them more. –  Chris S Jan 12 '12 at 18:16
    
Thanks for the input. This is actually for development purposes in which the webserver is only accessible on our intranet, so the only "clients" choosing the trust the CA will be in-house developers. I'm mostly just wanting to have as thorough of an understanding as I can. –  bingles Jan 12 '12 at 22:19

protected by Iain Feb 2 '12 at 8:57

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.