1

For an intranet server I use a self-signed certificate which I want to trust system-wide. I added the certificate exception to Firefox, but this is not possible in Chrome, console applications, IDEs, ...

This is why I want the certificate to be trusted system-wide. As I understood it, the recommended way is to install it as root CA: https://blogs.technet.microsoft.com/sbs/2008/05/08/installing-a-self-signed-certificate-as-a-trusted-root-ca-in-windows-vista/

As I also understood it, this means that whoever controls the self-signed certificate now controls a root authority which can sign forged certificates for any site on my machine. Is this true and if yes, how can I prevent this? I just want to have a single intranet server self-signed, not potentially all services I use.

What is the recommended way to deal with intranet TLS here?

  • “What is the recommended way to deal with intranet TLS here?” – Don’t use self-signed certificates directly? There’s no way this is going to work otherwise. – Daniel B Sep 25 at 8:25
  • Note that "don't use self-signed certificates" does not actually imply "only use public WebPKI CA issued certificates". – grawity Sep 25 at 8:29
3

If the server is under your control:

  1. Create an actual root CA (e.g. with easy-rsa or Xca or Windows Server CA role).
  2. Replace the self-signed server certificate with one issued by your custom CA.
  3. Make sure the certificate you just issued is actually marked as a "leaf" / "end-entity" certificate. Look for the "X.509v3 Basic Constraints" extension – it must be present and say "CA: FALSE".
  4. Install the custom CA's root certificate into your computer.
  5. Safely store the CA private key so that it's only accessible whenever you need to issue a new cert.

As the server's certificate contains "Basic Constraints: CA: FALSE", it will not be able to issue new certificates using just its own key.

(The reason you need the CA to be separate is because directly installing the server's self-signed certificate into the "Trusted CA" folder may cause the system to ignore Basic Constraints – after all, it's installed as an authority. Separation avoids this problem, because you can safeguard the root CA keys.)

As a bonus feature, you won't need to re-trust the server certificate when it expires or when its name changes – just use the same root CA to issue a new cert.

  • Thanks for the in-depth explanation of the process - very helpful. However, we now have changed the problem of trusting the server certificate for all my services to trusting the self-created root CA for all my services. In my specific usecase, this might actually be helpful though as I could just throw away the root CA private key for good - leaving no possibility of someone creating a forged certificate for e.g. google.com – PhilLab Sep 25 at 11:08
  • Yes, that is the whole point – you no longer need to trust the application server (from which the private key might be stolen); you can keep the root CA key offline, whether on a flash drive or a smartcard. – grawity Sep 25 at 11:11
  • yes you are right. But its still problematic for a use case where multiple persons want to trust this one certificate: they have no way of making sure that the very same mechanism used to "whitelist" this one connection is not used to create certificates for their banking. So they would have to trust me that I threw the private key away for good – PhilLab Sep 25 at 11:14
  • Well, yes. That’s how PKI works. There is no way around that. – Daniel B Sep 26 at 7:14
  • There is – quite a few PKI-based systems also allow accepting specific certificates (e.g. by fingerprint or SPKI-hash) instead of full PKI validation. It's just that Windows system-wide does not. – grawity Sep 26 at 7:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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