Notes.text

How do I password protect my private key file?
Use the -des3 switch on the command: 
openssl genrsa -des3 -out caProtected.key 4096
You can still view the file, but the key is encrypted. To view the unencrypted key use:
openssl rsa -noout -text -in caProtected.key

Can I supply a password on the command line?
get_passwd() {
    local passwd=
    echo -ne "Enter passwd for private key: ? "; read -s passwd
    openssl genpkey -aes-256-cbc -pass pass:$passwd -algorithm RSA -out $PRIV_KEY -pkeyopt rsa_keygen_bits:$PRIV_KEYSIZE
}

How do I view my public key? 
The public key is derived from the private key:
openssl rsa -in ca.key -pubout -out public_key.key

Public key is used to encrypt messages. Private key decodes those messages. The private key can be used for signing - similar but not equivalent to encrypting messages. A hash of the cert is computed and signed with the private key. If the public key can successfully obtain the original hash value from the signature, it proves it was generated by the private key holder.

How do I view my certificate request file (csr)?
openssl req -noout -text -in ca.csr

Generate a root certificate and private key
Install the root on your system.
sudo cp myrootcert.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust
CA - Certificate authority
SSL certificate chains - In order for your browser to trust an SSL certificate, that certificate must be linked to a certificate that your browser already trusts. Web browsers are shipped with a set of certificates that are trusted by default. These are called root certificates. Root certificates are always self-signed. Some root certificates are stored by your operating system and some root certificates are stored by your web browser. Not all web browsers contain the same set of root certificates. This means a trusted website on Google Chrome might not be a trusted website on Microsoft Edge. It all depends on the particular set of root certificates the browser can reference. Some browsers will trust the root certificates stored by the operating system plus their own set of certificates. Other browsers, by default, may only trust the certificate set the browser was shipped with. However, there is usually a browser setting available where you can tell the web browser to trust the root certificates stored in the operating system's certificate store. 

What does it mean for a certificate to be linked to a certificate your browser already trusts? SSL certificates are signed by other 'certificates' further down the chain. You might purchase a certificate from GoDaddy. GoDaddy owns another certificate and private key that they probably purchased from someone who owns a trusted root certificate. GoDaddy's certificate is used to create your certificate and theirs is called an intermediate certificate. When a web browser visits your website, it will see that your SSL certificate is signed by GoDaddy. Then it checks who signed GoDaddy's certificate. It follows the certificate chain until it reaches a trusted root certificate contained in the browser's own certificate store. As long as it can find this root certificate, your website will be trusted. If it cannot find a trusted root, the browser will not trust your certificate. In order for an SSL certificate to be trusted, all the links of the certificate chain must end at a trusted root certificate contained within your browser's certificate store.

So now you're thinking, "I could buy a certificate for my domain, then use that certificate and my private key to create new certificates for other domains and not have to purchase any more certificates". In theory, yes. But GoDaddy and other sellers have already thought of that. The certificate they sell you is marked, CA:False, meaning the certificate cannot be used as an intermediate certificate. When a web browser encounters this flag, it stops traveling down the chain to the root certificate. Instead, it immediately claims that the new certificate you signed with your purchased certficate is not trusted.

When you purchase your SSL certificate, you install the certificate on your web server. You may need to install intermediate certificates as well if they are not already installed on your web server. In addition, you install the private key for your SSL certificate on your web server. You do not install private keys for intermediate certificates. Unless you are creating your own SSL certificate chain, you do not have the private keys for the intermediate certificates. They are closely guarded secrets of the companies that sell SSL certificates. 

Private keys are used to decode encrypted text. Public keys are used to encode text. Your SSL certificate is a file that contains your public key as well as information about your identity, the time period the certificate is valid, and other information. A web browser will extract the public key from your certificate and use the key to encode the information it sends to your website. Your website uses the private key to decode this information. As long as no one else has access to your private key, your website is the only entity that can decode information encoded with your public key. A private key can also be used to encode a hash of your certificate file. 

Tasks -
Command file to create a cert chain
command file to renew a cert - inputs are expired cert and private key
command file to install a root cert on system