Is it a good approach to have a master SSL key for all your servers when making the authentication?

I am a Developer, but when you work in a company with two developers and you are the senior one you have to learn a lot of stuffs. I am learning more in depth things about how to secure the servers and network.

Now, I am expanding the servers. Splitting the code and database in three different servers (code, Master DB, Slave DB) and configuring Master-Slave databases.

My questions are:

1. Is it a good approach to have a master SSL key for all your servers?
2. Is is a good approach to use the same SSL key for Master database server and Slave database server?

Any other suggestions are welcome.
Thank You in advance!

Not my forte but I can weigh in with some experience.

Microsoft env: Typically when securing internal services you use an internal certificate authority that you set up, that is only online to create secondary authorities. You use secondary certificate authorities to sign all keys for use in your internal realm. Then whatever machines are on your network need to be told that the master signing key is trusted. So yes, there is a master SSL cert from your primary cert authority.

Linux: If you’re working in a Linux environment you can basically have a trusted key that you generate and manage yourself that you sign other certs with. No need for stand alone cert servers.

If your network is entirely private and properly fire walled (think AWS VPC you configured or private data center) it’s not 100% necessary unless your app handles financial information. If your servers are public cloud machines on the internet it is mandatory for safety of information.

Usually, there will be a secured "master key", for creating a certificate authority: The private key is not kept on any (application, database, ...) server, but instead will be used to sign the certificates of the individual applications and servers.

As every server trusts this "master key", it will trust the signed identities. Each identity will have a different key. The "master key" can sign an unlimited amount of identities - you can sign all of your certificates with it.

Why not use a single key on all servers directly (instead of making the step with the signature)?
Assuming the slave database server gets compromised - assume the attacker got administrative credentials. As this is only the slave, he may now read the database, but not write manipulated data on the master.
So he might try to be a man-in-the-middle in the network (a surprisingly low amount of networks have protection against ARP spoofing) and to get the master's password. As database communications are 'surrounded' TLS nowadays, he cannot easily "forge" the master's identity - except when he knows the master's private key.

When the same private key are used on all servers, this attack is possible - when using trusted certificates it is not (of course the certificate authority's private key must not be stored on any attacker accessible server; better store it encrypted, possibly even offline).