Is there a concept of trusting an SSL/TLS certificate to identify a single website but not to act as a CA for other certificates?

Question

I regularly find myself dealing with poor certificates within my intranet (or on temporary servers without a properly-signed cert). I haven't run across an approach that lets me save the certificate of a single website (including its CN) in a browser without also trusting it as a certifying authority for other websites. Is this conceptually possible, or is that outside the design of the PKI system?

Edit to clarify: Let's say I'm working on some local server, megaserver. I access it via https://megaserver in the browser. It has a self-signed certificate. In order to safely access this server for the time being, I add its certificate to my CA store in my browser. Someone steals that certificate, creates a new certificate for https://www.google.com, signs it with the megaserver certificates, and attacks me man-in-the-middle style. My browser accepts the Google certificate because it's signed by a trusted CA cert on my system. Is this hypothetical scenario possible?

Answer 1

Yes.

From RFC 5280:

4.2.1.9. Basic Constraints

The basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate.

It then goes on to say:

If the basic constraints extension is not present in a version 3 certificate, or the extension is present but the cA boolean is not asserted, then the certified public key MUST NOT be used to verify certificate signatures.

verify certificate signatures effectively means act as a CA.

Therefore, if your self-signed certificate doesn't have the Basic Constraint CA set to true, it cannot be used to sign subordinate certificates.

Are you sure all these self-signed certificates have this flag set to true? If so, you really need to have a word with whoever is generating them and point them in the direction of some free online PKI training resources.

---

Stealing a certificate is not a risk - after all, certificates are public knowledge. Stealing the associated private key however is, and renders your certificate useless. This age long problem (within the PKI world) of securing the private key has resulted in the development of Hardware Security Modules to keep the private key from falling into the wrong hands. I doubt you want to go to that much expense for your intranet's self-signed certificate though.

A better approach is to ensure that you manage who logs onto the devices that create these certificates. Systems that use OpenSSL, GnuTLS, Java etc can password protect the private key. Windows encrypts the private key, but once an administrator has logged onto this Windows machine, the private key is effectively there for the taking.

Answer 2

Q: I add its certificate to my CA store in my browser. Someone steals that certificate, creates a new certificate for https://www.google.com

You adding to the certificate store Public key of self established local CA. The only owner of CA's private key can sign someone's certificate (as you said for https://www.google.com), so stealing CA public key from your browser is useless since it isn't a secret and can't be used for signing others certificates.

Q: My browser accepts the Google certificate because it's signed by a trusted CA cert on my system. Is this hypothetical scenario possible?

You trusting your browser that in turn trust to particular scope of CAs. If you added to your browser your local CA as trusted to the certificate store then you automatically trusting to all certificates signed by this local CA.

This way IT department who managing your local CA may issue and sign fake certificate for google.com and your browser will trust it, but... Here is two technical detail that you need to know.

When you connecting to some https domain directly, web server reply with public certificate that carry information who signed this certificate and browser looking in its certificate store for CA who signed this web server's certificate, so you may think that it would be a hard job for the guys who attempting to fake google.com who should setup fake copy of google.com as its own web server and override DNS record that would point to the fake web site pretending to be google.com

But in reality it could be done relatively easy. While it sounds like impossible(or hard to do that), I should inform you that it no to hard to do that and this actually is a common practice with many companies to watch/intercept https traffic for various reasons(filtering, monitoring and logging) by employing transparent(or with authorization) http Proxy.

If you added local CA to the certificate store then if your company using http proxy, this proxy may generate on the fly fake certificates for any https connections and feed it to your browser and your browser will trust (as I described previously) to such fake certificates. Proxy on its side may decrypt such connections since its own private keys for all issued certificates for the purpose of filtering, monitoring, logging and in case if connection bypassed proxy's filter, proxy will ask targeted real site as a client itself, then re-incrypt reply and return to original destination (or it may decide to play fake timeout connection if some rules requiring that).

What I may advise you if you won't to be a subject of https filtering - setup some virtual machine (VirtualBox for example) with OS you comfortable on and add there your local CA while keep host machine non infected with local CA.
Another solution, - you may use different profiles in your browser (Firefox good on this), one for work that will hold your local CA certificate and another one private profile that doesn't include local CA. This way you(actually browser) may quickly spot events if your https traffic is filtered via proxy.