1

Self signed cert is always looked down as a test-only certificate. But as per understating, using it for production is perfectly fine if used for the right reason. I am trying to provide some guidelines to my customers about that to use what. E.g.:

  1. Authentication: Not ok to use self-signed as the Brower will not trust the "self" issuer. So, for service-to-service or service-to-client authentication is not ok to use self-signed. Unless there is a pre thumbprint/CN whitelisting process before verifying. Lot of people do these, e.g. Azure where I upload the management cert public key, which is used to authenticate their API.
  2. Signing: No ok, as there is no trust with the issuer. Unless there is a pre thumbprint whitelisting process before verifying. Unless there is a pre thumbprint/CN whitelisting process before verifying.
  3. Encryption: Perfectly OK to use self-signed as there no chain trust required. In case of an attack, the MIM cert will simply not decrypt, no other impact.

I would like some thoughts/recommendations/guidelines from the community to ensure my recommendations are in the right direction.

Thanks.

Improve this question

3 Answers 3

Reset to default
2

Encryption: Perfectly OK to use self-signed as there no chain trust required. In case of an attack, the MIM cert will simply not decrypt, no other impact.

That is not correct. Trust needs to be established for encryption using a public keys, but it is on the other end. The encryptor needs to trust the encryption certificate, since otherwise he would be encrypting his sensitive data for some stranger to decrypt and read.

I think that your categorisation is the wrong take on the matter. The important question that you need to answer, if you want to use a self signed certificate (or even a non-publically trusted PKI) is: How will I be able to make my communication partners trust my certificate?

This could be done via a company policy (for company internal TLS certificates), via direct communication (for securing messages with a very small group of people) or it cold even be unneccesary since you control both ends of the communication (e.g. an app you wrote which communicates with a server you run).

There are more scenarios than the ones that I have listed, but not that many. If you ever have to rely on some unknown user having to actively do something, than you really should not use self signed certificates.

Improve this answer
2

The difference between a self-signed certificate and one that isn't is whether the client's computer automatically trusts your certificate. So then, any situation in which that doesn't matter, you can use either option.

The CA system has some major issues, but for most cases we're pretty much forced to use it; for instance, a browser will display a large error page if you try to visit an HTTPS site with an untrusted certificate. If you control the clients (e.g. this is an internal website for your company), you can install your own CA, but with the advent of Let's Encrypt, there's not much of an argument to be made for not using a certificate that has been signed by a well-known authority.

Improve this answer
4
  • 1
    Well my customer is big enterprise, which 20000+ certs in use. Creating CA signed certs costs money, but a quick look tells me 60% of the certs are not used for SSL auth, or any form of auth which cannot do a thumbprint whitelisting. So the argument is, use self-signed for these 60% and save money.
    – Bhaskar
    Jul 28, 2017 at 20:28
  • 3
    @Bhaskar If your customer is a big enterprise with that much certs, they can create their own CA and intermediate authorities to sign the certificates. In that case there is no need to use self signed certificates
    – Mr. E
    Jul 28, 2017 at 20:57
  • Let's Encrypt covers only a small subset of cert needs in enterprises (only HTTPS). Once private names are used -- LE is not an option at all. As the result, you may need to find arguments to use Let's Encrypt and not opposite.
    – Crypt32
    Jul 29, 2017 at 8:11
  • @Mr.E, i am trying to understand the guideline and the principal, and not what an enterprise can do. If an enterprise can take up the self-sign route, its so much simpler for each of their LOB app team to handle certs.
    – Bhaskar
    Jul 30, 2017 at 1:03
1

Self-signed certificates are never ok unless you have a way to verify the ownership through a different and secure channel

The three usages you mention (Authentication, signing and encryption) are in fact three properties that come together. The owner of the certificate can sign a document because the public key verifies that it was signed with the private key, which proves (In a certain way authenticates) that he is who he says. At the same time the public key gives a secure way to transmit sensitive data that only the owner of the private key should be able to decrypt

As you can see none of this is possible if you can't verify the ownership of the certificate, and therefore trust the certificate

The main applications that use self-signed certificate "without risks" are GPG and ssh connections. The reason is because GPG certificates are verified through other channels (You should never trust a certificate sent via email without checking the fingerprint with the owner). In the case of ssh, it's supposed to transmit the certificate through secure channels like a pendrive (Best case scenario) or in the case of cloud computers you implicitly trust that the cloud owner won't modify your certificate or install a different one

Improve this answer

You must log in to answer this question.

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