Thinking about the security warnings a user would normally see for self signed certificates and the fairly common practice of setting up client/ employee machines so they never see the warning when presented with a self signed cert.
Fundamentally this means installing the Public Key for the self signed certificates on the clients. This, to me doesn’t sound like a good idea.
To understand the chain of trust between a client, a server and a Certificate Authority (CA) its important to note that Transport Layer Security (TLS) is the protocol used by HTTPS and together they ensure confidentiality, integrity and authenticity of the traffic. Part of this is achieved with an important cryptographic primitive used in TLS to sign and verify certificates. This primitive uses asymmetric public private key encryption and a hashing algorithm. The client uses the public key from the trusted CA certificate to validate the CA’s digital signature on the certificate it was given by the server, this verification is given by;
SIGNsk(m) = s <-> VERIFYpk(m, s) = Yes or No
sk = secret key
pk = public key
m = message ( the certificate)
s = signature
The digital signature is an encrypted hash value of the contents of the certificate. So the client needs to compare the hash value of the digital signature and the hash value of the contents of the certificate. So it uses the CA’s public key to decrypt the digital signature and it now has that hash value. Then it computes the hash value of the certificates contents and if the two hash values match the client can be confident that the CA did sign it and that the information in the certificate has not been changed.
So moving onto where and how these certificates appear, normally https traffic between a client browser and a server is encrypted and looks like jumbled bits to anyone monitoring the traffic. When an encrypted channel is negotiated between a client browser and a web server where a symmetric session key is generated and shared using asymmetric encryption the server has to prove they are who they say they are. To do this the server sends its certificate which specifies its domain name and its public key and has been signed with the private key of a trusted Certificate Authority (CA) to the client. Among other checks such as date and time, expiration and domain name matches the client looks in it certificate store, which is a local folder in the OS for the corresponding public key of the CA that signed the certificate and uses it to confirm the the information in the certificate is authentic by verifying the certificate was signed by the CA and the hash values match.
These trusted CA certificates which contain the Public Key for a CA normally come hard coded in the browser when it is installed or updated and or as part of the OS. For example on a Mac these CA certificates are managed by the Keychain Access App and on windows they are managed by the keychain store but in both instances Chrome comes with its own set of baked in trusted CA certificates. It’s important to note that regardless of where they came from these certificates are stored in a folder, locally on the machine or device and are totally trusted.
If you have personnel generating non unique self signed certificates where each certificate has been signed with the same private key and the corresponding public key installed on all clients anybody with that private key can sign any certificate and it will be totally trusted by by any client that has the corresponding public key.
I’m thinking this totally breaks the idea of chain of trust. Imagine an enterprise environ with multiple admins/ network guys/ gals running around generating certificates and installing the public key on clients, that could be diabolical with personnel turnover and the oft used example of disgruntled employees/ insider threats.
Reference
Comer, Douglas E. Internetworking with TCP/IP Principles, Protocols and Architecture, 6th Edition, 2014