1

I work for a big insurance company, they have created a certification authority to generate certificates for their internal webservices. These webservices are accessible from their intranet only and are called by their applications and services only. Does this situation make sense? They certify to themselves that they are the owner of their services. Since they are not a recognized certification authority, they have to embed their CA certificate in all their applications.

It seems to me that using a certificate in this situation just does not make sense, they should just encrypt the communications with HTTPS. If they really want to certify the ownership of their webservices, then they should buy a certificate from a recognized certification authority. The certification authority should be a third party.

Improve this question

3 Answers 3

Reset to default
2

The organization described has implemented a Private CA.

Whenever an organization creates its own local CA without going for a commercial external one, it’s called a private CA.

The certificates are signed with the private key of the organization’s root certificate. This cert is distributed to all devices to allow for verification.

Private CAs are used to issue certificates for an organization’s internal network where encryption of sensitive data is required, and only a limited group of users are involved.

This is an appropriate security control for the use case described, and can be used to enable users to authenticate to internal systems (VPNs), secure internal resources and services (databases, email servers), to secure devops build servers and dev/testing environments, as well as for deployment for IoT devices.

Improve this answer
3

You can’t (easily) “just encrypt the communications with HTTPS”. Most web browsers don’t have an option to encrypt without authenticating, because it’s an enormous security hole.

And there’s nothing wrong with being your own CA in this scenario. When you say ”The certification authority should be a third party”, that’s not right. The CA should be trusted by the user (which in practice means trusted by the creator of the user’s browser software), which requires it to be a third party on the public Internet because you can’t practicably establish a trust relationship with every website. But in a corporate Intranet you can trust your employer, so no third party is needed.

Improve this answer
1
  • I am talking about machine to machine calls, not web applications run in browsers. Is it difficult to enable HTTPS without a certificate in this situation? Technically using your own CA works, but is it meaningful? obviously 2 machines in the internal network are going to trust each other.
    – peveuve
    Mar 21, 2022 at 8:00
-1

Other answers are correct, but I'd like to add a bit on top of them.

Keep in mind that encryption can be easily defeated with a Man-in-the-Middle (MitM) attack.

In the context of HTTPS, this is the primary reason of using a certificate. I am not aware of any way to establish a trusted communication without a third party certifying one end (or even better, both).

Of course, they could also use a self-signed certificate, but having an actual CA brings a lot more flexibility (like replacing the certificate, emitting new ones...).

Last but not least, I don't know that many organization would be willing to deliver you a certificate for a private IP address.

Improve this answer
5
  • I understand now man-in-the-middle attacks are the reason to use certificates. A self-signed certificate will never be trusted, you will have security warnings that we want to avoid. A certificate is delivered for a domain name, not an IP address, so we could use a certificate delivered by a third-party in our private network, as long as the DNS associates the domain name with internal addresses.
    – peveuve
    Mar 21, 2022 at 8:32
  • @peveuve A self-signed certificate can be trusted. With the CA, the CA root (or an intermediary) certificate had to be deployed on all computers in the organization. Then all certificates signed by the root or intermediate will be recognized. A CA root is can be a self-signed certificate itself. Also, the "subject" of the certificate can be a domain indeed, but it can also be an IP, a wildcard...
    – user1532080
    Mar 22, 2022 at 11:17
  • @peveuve I suppose you say a self-signed certificate cannot be trusted because usually, you'll download it when accessing a server over HTTPS, and of course, there could have been an MitM attack. But your organization could have printer posters and put them on every wall with the certificates fingerprint. You could then possibly trust self-signed certificates downloaded over HTTPS. Of course, somebody could have replaced the poster. But somebody could have replaced the organization root CA certificate on your computer too. What happens is you trust what's on your computer.
    – user1532080
    Mar 22, 2022 at 11:21
  • @peveuve Antiviruses commonly install their own certificate on your computer. They effectively perform an MitM attack, "for your own good". And in most cases people don't even know it happened. Anyway, I guess that would make for another question. I just wanted to highlight that, while having a CA makes sense, it's not necessarily for the reasons you think.
    – user1532080
    Mar 22, 2022 at 11:25
  • Ok, I don't know it was possible to deliver a certificate for an IP address; even if it is rare. The rest is still a bit nebulous for me honestly, but I have my answer.
    – peveuve
    Mar 22, 2022 at 14:58

You must log in to answer this question.

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