Image may be NSFW.
Clik here to view.
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
- Created a Root CA .pvk and .cert
- Installed the CA root .cert on my local machine under “Trusted Root Certification Authorities”
- Installed the CA root .cert on my development hosting server under “Trusted Root Certification Authorities”
Certificate for My Site
- Generated another certificate from the root .cert and .pvk
- Imported the new certificate as a .pfx file on the hosting server
- 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?
Image may be NSFW.
Clik here to view.
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).
Check more discussion of this question.
