4

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?

Improve this question
3
  • “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
    Commented Sep 25, 2019 at 8:25
  • Note that "don't use self-signed certificates" does not actually imply "only use public WebPKI CA issued certificates".
    – grawity_u1686
    Commented Sep 25, 2019 at 8:29
  • Self-signed certificates should never be used, as they have no Chain of Trust and are therefore insecure and pointless; the recommended way is to create a self-signed CA, using that CA to sign the certificate as covered in @grawity_u1686's answer (please see this for more info)
    – JW0914
    Commented May 16 at 9:31

2 Answers 2

Reset to default
4

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.

Improve this answer
5
  • 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
    Commented Sep 25, 2019 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_u1686
    Commented Sep 25, 2019 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
    Commented Sep 25, 2019 at 11:14
  • Well, yes. That’s how PKI works. There is no way around that.
    – Daniel B
    Commented Sep 26, 2019 at 7:14
  • 2
    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_u1686
    Commented Sep 26, 2019 at 7:15
-1

Well, a certificate actually can have "key usage" property which restricts what can it be used for. So I guess you just need make sure that the self-signed certificate doesn't have "Certificate Signing" allowed key usage, or something like that. This way perhaps it could be "safe" to add it to trusted roots in Windows? If I'm mistaken, then someone correct me please.

And do you have to any other conclusion?

Improve this answer
3
  • Self-signed certificates should never be used, as they have no Chain of Trust and are therefore insecure; the recommended way is to create a self-signed CA, using that CA to sign the certificate (please see this for more info)
    – JW0914
    Commented May 16 at 9:35
  • @Ramhound Self-signed certs lack Chain of Trust and are inherently insecure since a user is unlikely to realize it's been replaced, opening the door to a MITM attack. It takes at most an extra 120s to generate a self-signed CA, using it to sign the cert - only two extra commands are required, and I cover them here. Provided the CA has been imported into the CA keystore, the cert will always be trusted (even the D.o.D requires installing its root CAs & ICAs manually to access systems)
    – JW0914
    Commented May 17 at 20:27
  • @Ramhound Self-signed CAs/ICAs are trustworthy because their private key is encrypted - they are not the same as a self-signed cert that is used for web servers/VPNs, email encryption, or a cert for digitally signing files and code. This Chain of Trust link explains why self-signed certs are inherently insecure, whether in a closed, isolated network or anywhere else - they lack Chain of Trust. It's not the certificate itself that's insecure, it's insecure because there's no way to verify the cert since it lacks Chain of Trust
    – JW0914
    Commented May 17 at 21:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .