Self-Signed certificates are free, but not without cost. In this post you’ll learn all about the dangers of self-signed certificates.
What about applications that are installed on-premise? Our software has a web UI that is used in intranets. We need to secure the communication between clients and server with HTTPS, but the servers are installed locally at our customer’s location. We thought about using self-signed certificates. What could we use instead?
The message is a lie. Self signed certificates are still encrypted and if do have a chain that can be verified. You need to add that certificate into your accepted roots to get rid of the message. It has been all too easy for third party programs installers to do this though. The additional root needs to be distributed and installed with care.
There’s a difference between self-signed certificates and certificates that are issued by your organisation.
The general rule of thumb should be that if the application will be accessed via the internet, use a trusted provider like Let’s Encrypt (free!) and if it’s intranet, generate an organisational certificate. This can be done from a server with the Active Directory Certificate Services role.
If you’re managing your own internal (organisational) certificates, keep access to them restricted and have a comprehensive policy for cycling certificates.
Self-signed certificates should only be used for testing in your own environment(s). If anyone else is going to use the app, follow the general rule of thumb above.