0

From an information security perspective, which is best for private (on-premise) micro-services (web services) accessed via HTTPS?

Are there an advantages in using certificates signed by a Third Party instead of Self-Signed certificates in such a scenario?

||improve this question
  • 1
    One drawback for an external authority that I can see is if it gets compromised (an event outside of your control) then an attacker can impersonate one of your servers. If you generate all the certificates you need and throw away the CA then it's going to be harder for an attacker to generate a valid certificate than if it was from an external CA that still exists. – user Oct 14 '19 at 13:46
  • I was thinking of this but I didn't know how to ask "what external checks are made while two private, on-premise, web-services talk to each other via HTTPS".. – Andrei Rînea Oct 14 '19 at 13:47
  • [cont'd] because "going out" can cause security risks – Andrei Rînea Oct 14 '19 at 13:48
  • Typically external events caused by remotely signed certificates are just the CRL checks. If you only generate e.g. 2 certificates for internal use you will never need a CRL. If you have additional servers and don't want to just burn down everything and start over whenever one of them gets compromised you'll need to keep a CRL updated (and need to keep the CA around for that matter). – user Oct 14 '19 at 13:52
1

Here are some disadvantages of using self-signed certs in your scenario:

  1. Some clients out of the box will not work with self-signed certs. You may have to tweak your code to get them working, though this is usually a one-and-done type of tweak.
  2. In order to thwart a MITM attack you would need to make sure that only these specific certs are allowed (which you should do anyway). However, this is preventing a MITM attack from your internal network and if that were to happen you probably have bigger problems than cert authentication between two services.
  3. If you have many services that you want to use self-signed certs for, revocation of a large number of certs could be cumbersome if you ever needed it. Having a root CA (whether internal or external) could make quick revocation much easier in an emergency situation. That being said, you could also just turn off the affected services until you regenerate new certs, which you would have to do anyway with or without a root cert.

My conclusion: If you have an internal root CA I'd use that. Otherwise, self-signed should be fine.

||improve this answer
1

A third option might be to consider using an internal CA that you trust. Remember, signing a certificate is a method of vouching for the authenticity of the host using it. A Defense-in-depth approach would dictate that self-signing not be used, particularly for microservices that might be processing production information. Self-signed essentially means the only control that needs to be compromised is the host using it. This is similar to the idea that 'if it's on my internal network its trustworthy'. The numerous APTs have demonstrated this to be an unwise strategy.

||improve this answer
  • Note that even with an external server attesting to the authenticity of your web host, a compromised web host will still be "valid" even while serving malicious content or harvesting user credentials. Self-signed certificates do not have an additional, external host that can also be compromised. – user Oct 14 '19 at 14:51
0

Using self-signed certificates is always dangerous if you don't pin the certificate based on its fingerprint. Third-party certificates are probably better for your scenario. A third options would be creating your own internal CA as Sean E. M. suggested. However setting up and maintaining an internal CA is not a trivial task.

||improve this answer

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.