I have a PowerShell script that creates a root key, root pem, and root cert: (Some boilplate code and checks are hidden from the code below)

1. Generating an encrypted private key
2. Creating a private .pem file
3. Creating a private CA .crt file

openssl genrsa -des3 -passout pass:$RootPass -out $root_key $key_bit_len
openssl req -x509 -new -nodes -key $root_key -sha256 -days $Duration -out $root_cert -passin pass:$RootPass -subj $subj_info_private
openssl req -x509 -new -nodes -key $root_key -sha512 -days $Duration -out $root_pem -passin pass:$RootPass -subj $subj_info_private

This is then used to to sign a server certificate by:

1. Making a server key file
2. Creating a Cert Signing Request File
3. Creating a server Certificate .crt file
4. Converting the .crt to .pfx

openssl genrsa -out $server_key $key_bit_len
openssl req -new -key $server_key -out $server_csr -subj $subj_info_public
openssl x509 -req -in $server_csr -CA $root_pem -CAkey $root_key -CAcreateserial -out $server_cert -days $Duration -sha512 -extfile $ext_file -extensions 'req_ext' -passin pass:$RootPass
openssl pkcs12 -export -inkey $server_key -in $server_cert -passout pass:$PFXExportPass -name $PersonalCommonName -out $server_pfx

Now on my server, I can install the root certificate into the trusted root CA store and the server (personal) certificate in the personal store.

For this server to communicate securely with a client, does the client have to have the same root certificate installed? Or is there something I'm not understanding, like making a client key as shown on mariaDB website. I'm trying to understand the technicalities of SSL certificates to know if I need to distribute a private keyprivate CA certificate to various clients (In my case EC2 instances that communicate with the central server) or if there are other options.

CodePudding user response：

Certificates are used to authenticate a site, i.e. to make sure that one is actually talking to the expected server and not some man in the middle.

In order to verify a certificate one needs to be sure among others that the certificate is issued for the site visited (i.e. the domain in the URL) and that it is issued by a trusted CA. If the check for a trusted CA would not be done than a man in the middle could just issue a fake certificate for the site by its own CA.

The trusted CA must be known to the client up-front, i.e. the server can not simply send it within the TLS handshake since the TLS handshake is not trusted. If the client would simply trust a CA send inside a TLS handshake then a man in the middle attacker could provide its own CA there.

If the certificates was issued by a public CA the usually the client already knows and trusts this CA. If you use your own CA instead you somehow need to put this CA into the clients trust store before the TLS connection can be established and the certificate properly verified.