I have an app that is distributed as a Docker image (SpringBoot web application). Encryption of traffic and user data is essential, so I would like to enable SSL support by default. Some people find it difficult to generate their own certificates and java keystores. Therefore, I thought about generating my own self-signed certificate and including it inside the Docker container. The encryption aspect is crucial, and the "trust" part can be disregarded. The image will be available publicly to everyone. I think it is easy to use - just run container, open the browser and confrm "certificate exception", the traffic will be encrypted. Are theyre any cons of doing it this way?
The encryption aspect is crucial, and the "trust" part can be disregarded.
This is unfortunately a common misunderstanding: The server certificate is only to prove the identity and says nothing about the "trust" into the server itself, i.e. if the server is malicious, vulnerable, ... The server certificate is instead to ensure that one is actually connected to the expected server and not to some man in the middle attacker.
Without properly validating the certificate (i.e. not blindly skipping the warning caused by a self-signed certificate) an attacker can compromise the connection with a man in the middle attack: encryption is still done but not end-to-end with the intended server but instead encrypted between client and attacker and then again from attacker to server, so that the attacker can read and manipulate the traffic. This obviously undermines the integrity and confidentiality intended by the encryption.
Some people find it difficult to generate their own certificates and java keystores.
Most of these less technical users are likely also unable to grasp the impact of blindly trusting a self-signed certificate. Insofar shipping with a pre-created self-signed certificate and offering users just to use this is not a good idea.