TLS setup for apache and postfix mail

They are different ways to encode Abstract Syntax Notation 1 (ASN.1) formatted data, which is the format x509 certificates are defined in, in machine readable ways.

As mentioned above the public key is what is sent to the CA to be signed. The CA verifies the details of your public key and verify you have rights to it (could be by verifying an email with your private key, while they are talking to you over the phone) Once that is verified they will themselves sign your public key with their public key. This signed p*ublic key is what becomes your server's or your domain's public certificate.

People can now trust your server, because your server's public key has been signed by this CA, which they can verify, by checking the signature of the certificate authority.

In the /etc/pki/tls/openssl.cnf file there are some CA config lines:

####################################################################
[ ca ]
default_ca      = CA_default            # The default ca section

####################################################################
[ CA_default ]

dir             = /etc/pki/CA           # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several certs with same subject.
new_certs_dir   = $dir/newcerts         # default place for new certs.

certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number
crlnumber       = $dir/crlnumber        # the current crl number
                                        # must be commented out to leave a V1 CRL
crl             = $dir/crl.pem          # The current CRL
private_key     = $dir/private/cakey.pem# The private key

x509_extensions = usr_cert              # The extensions to add to the cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt        = ca_default            # Subject Name options
cert_opt        = ca_default            # Certificate field options

My host did NOT have a CA directory. ? Is that because I dont' intend to be a CA?

You need to tell your server, where the set of root certificates reside. These are the CA root servers, and should be listed in /etc/ssl/certs

If your openssl isn't set up to automatically use an installed set of root certificates (e.g. in /etc/ssl/certs for non-RHEL systems), then you can use -CApath or -CAfile to specify the CA.

My Almalinux server has /etc/ssl/certs symlinked to /etc/pki/tls/certs. However, nothing else in /etc/ssl including no openssl.cnf file Rather, that was in /etc/pki/tls/openssl.conf

specified with the -config option. See OPENSSL_CONF env. variable to see which file is being used.

There are How-to Guides availabe on https://www.openssl.org/docs/ that I read. Also use man crypto, available on Linux.

Some useful commands dealing with certs are part of openssl. See man openssl for a complete list, but here are some most useful examples:

• openssl command [command options] [command args]

• openssl s_client -connect zintis.net:80 -showcerts
• openssl s_client -connect zintis.net:80 -showcerts
• openssl s_client -connect zintis.net:443 -showcerts

• openssl s_client -connect acme.server.com:443
• openssl s_client -connect acme.server.com:443 -brief
• echo | openssl s_client -connect acme.server.com:443 -brief
• echo | openssl s_client -connect acme.server.com:443 -brief
• echo | openssl s_client -connect www.zintis.net:443 -brief

echo | openssl s_client -connect redhat.com:443 2>/dev/null | openssl x509 -noout -dates This will take the output of the -connect command and check out the x509 exiration dates. This is a common technique, where you use the s_client to connect to a SSL/TLS server, download the cert, then analyze it with openssl x509 or other openssl commands.

• openssl s_client -connect acme.server.com:443 -tls1
• openssl s_client -connect acme.server.com:443 -dtls1

• openssl s_client -connect acme.server.com:443 -cipher DHE-RSA-AES256-SHA

Generate two files, 1) a private-key file that will be used to generate a CSR and later, to secure and verify connections using my certificate, and 2) a Certificate Signing Request (CSR) file, that is used to order my SSL certificate from my CA, and later used by web clients to encrypt their messages that only I can decypher (because only I have my private key.)

• openssl req -new -newkey rsa:2048 -nodes -keyout acme.com.key -out acme.com.csr
• openssl req -new -newkey rsa:2048 -nodes -keyout acme.com.key -out acme.com.csr

• openssl req -new -key vm2.zintis.ops.key -out vm2.zintis.ops.csr

To create a self-signed PEM file:

• openssl req -new -newkey rsa:2048 -nodes -x509 -days 3650 -keyout key.pem -out cert.pem

From microfocus.com:

By default openssl will generate a prime 1024 or 2048 bits in length. You can increase the length of the DH prime, using this command: less - openssl genpkey -genparam -algorithm DH -out dhparam4096 -pkeyopt dh_paramgen_prime_len:4096 Note, that genpkey --genparam supercedes the older dhparam command.

Then you can add this to your nginx.conf file, in the server block:

• ssl_dhparam /etc/pki/tls/certs/dhparam4096

Often you combine your certificate, with the signing authority certificate, and the root certificate. They should be in that order, i.e.:

1. Primary certificate - www.zintis.net.crt
2. Intermediate Certificate - godaddy.com.crt
3. Root Certificate - TrustedRoot.crt

This can be done simnply using cat one.crt two.crt three.crt >> bundled.crt

The bundled.crt file should look something like this:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

1. (optional) Remove the password from the Private Key by following the steps listed below:
2. openssl rsa -in server.key -out nopassword.key

Note: Enter the pass phrase of the Private Key.

1. Combine the private key, public certificate and any 3rd party intermediate certificate files:
2. cat nopassword.key > server.pem
3. cat server.crt >> server.pem

Note: Repeat this step as needed for third-party certificate chain files, bundles, etc: cat intermediate.crt >> server.pem

You should already have a private key from the openssl req command. Chmod to 400 as root, so that it is safe, and take a backup as well. Without your key the certificate is useless.

• openssl x509 -in 4abe36dee147d6a4.crt -text -noout
• openssl x509 -in 4abe36dee147d6a4.crt -text -noout
• openssl x509 -in 4abe36dee147d6a4.crt -text -noout

• openssl rsa -in acme.com.key -check
• openssl rsa -in acme.com.key -check
• openssl rsa -in acme.com.key -check

Here is one-liner to verify a certificate chain: openssl verify -verbose -x509_strict -CAfile ca.pem -CApath nosuchdir cert_chain

(You can verify the CSR and see the data filled in when it was generated)

• openssl req -text -in acme.com.key -noout -verify
• openssl req -text -in acme.com.key -noout -verify

• openssl x509 -noout -modulus -in acme.com.crt | openssl md5
• openssl x509 -noout -modulus -in acme.com.crt | openssl md5
• openssl rsa -noout -modulus -in acme.com.key | openssl md5
• openssl rsa -noout -modulus -in acme.com.key | openssl md5

• openssl x509 -in email-ca-bundle.pem -text -noout
• openssl x509 -in tls-ca-bundle.pem -text -noout
• openssl x509 -in gd_bundle-g2-g1.crt -text -noout

These files were in /etc/pki/ca-trust/ and subdirectories. Use the command openssl x509 -in 4abe36dee147d6a4.crt -text -noout

zintis@zintis.net /etc/pki/tls/certs[1034]:
$ openssl x509  -in 4abe36dee147d6a4.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 5385802535271913124 (0x4abe36dee147d6a4)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
        Validity
            Not Before: Apr 27 17:21:29 2021 GMT
            Not After : May 29 17:21:29 2022 GMT
        Subject: OU = Domain Control Validated, CN = zintis.net
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:a9:3e:6a:26:5b:f3:eb:89:ed:f9:c7:c9:ee:48:
                    a0:62:bc:7a:bc:33:a4:2f:c3:74:e4:43:cf:37:6a:
                    52:c9:b0:66:e7:90:9c:a2:b1:3a:4b:13:1a:79:3b:
                    10:4c:d4:0e:e6:64:a5:20:8c:a6:18:a8:fb:ec:c2:
                    2a:4e:38:cd:43:dc:79:34:d0:01:40:b8:d9:2a:4f:
                    e5:a1:7f:9d:04:f0:79:22:e2:f2:2d:be:47:5b:29:
                    ff:2d:14:a4:db:a3:35:d1:de:08:40:d4:4a:03:e6:
                    0d:c9:ff:d4:fa:df:d0:7d:1a:f8:48:ee:4e:c5:90:
                    9e:43:c7:32:33:e5:6b:61:d3:87:b0:30:3f:e1:a2:
                    8f:24:f1:58:bc:d2:74:96:a8:8b:6c:0d:e9:2e:1f:
                    af:2f:36:70:a4:40:aa:ab:c3:d6:ca:b2:98:2c:d7:
                    5e:94:aa:99:0f:e7:80:9c:a3:45:e4:dc:21:20:49:
                    e8:c5:58:3b:c4:40:7f:bf:0f:0e:c7:f0:b4:52:5e:
                    7b:50:45:2c:0d:5b:ff:ff:d1:08:a1:8d:31:63:3e:
                    b3:ec:4c:12:76:aa:8a:c4:2a:a9:b6:1f:c2:67:4a:
                    ae:8d:5b:0c:24:3c:d4:af:b0:86:16:90:55:f3:da:
                    b3:00:79:0c:5f:dd:31:c2:ed:75:85:67:d6:9e:eb:
                    4e:5b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.godaddy.com/gdig2s1-2903.crl

            X509v3 Certificate Policies: 
                Policy: 2.16.840.1.114413.1.7.23.1
                  CPS: http://certificates.godaddy.com/repository/
                Policy: 2.23.140.1.2.1

            Authority Information Access: 
                OCSP - URI:http://ocsp.godaddy.com/
                CA Issuers - URI:http://certificates.godaddy.com/repository/gdig2.crt

            X509v3 Authority Key Identifier: 
                keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE

            X509v3 Subject Alternative Name: 
                DNS:zintis.net, DNS:www.zintis.net
            X509v3 Subject Key Identifier: 
                F3:93:BD:51:40:11:25:73:C6:EA:6F:40:F3:AE:0C:B1:DA:8C:20:02
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 29:79:BE:F0:9E:39:39:21:F0:56:73:9F:63:A5:77:E5:
                                BE:57:7D:9C:60:0A:F8:F9:4D:5D:26:5C:25:5D:C7:84
                    Timestamp : Apr 27 17:21:30.636 2021 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:55:A8:71:9A:2F:A1:36:90:FB:A7:32:C1:
                                14:E8:65:E9:F8:2A:24:EB:C2:2F:35:E9:61:35:E3:B6:
                                C2:35:CA:80:02:21:00:9C:D3:92:A8:FD:0F:E9:D5:28:
                                A5:DC:A6:88:D3:25:0E:0F:EC:91:B2:DB:16:88:20:DC:
                                F7:7A:61:75:9B:41:3C
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 22:45:45:07:59:55:24:56:96:3F:A1:2F:F1:F7:6D:86:
                                E0:23:26:63:AD:C0:4B:7F:5D:C6:83:5C:6E:E2:0F:02
                    Timestamp : Apr 27 17:21:30.672 2021 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:B0:DD:1F:38:52:2D:E9:4B:CB:80:50:
                                ED:C0:B2:1A:81:C4:89:4A:5C:69:1D:29:39:95:3E:E9:
                                FC:9E:6D:CE:B1:02:21:00:D3:95:28:F9:A7:28:53:E5:
                                00:62:76:F2:DD:AF:75:F2:98:A6:F1:2B:C9:4A:55:B4:
                                FD:FE:25:A5:B1:6D:A9:F5
    Signature Algorithm: sha256WithRSAEncryption
         77:d7:88:94:30:ac:22:c4:3a:c2:6f:d8:c3:97:a6:64:45:4e:
         ee:7c:a8:c6:63:75:a5:d8:d2:2a:f0:de:ad:c7:86:8f:6a:d8:
         2e:50:df:e6:38:f8:b6:86:04:f2:4a:05:81:a5:1c:c7:39:79:
         95:81:e9:e2:8b:83:f4:dc:7f:06:a7:67:04:b0:3d:2a:9e:8d:
         f6:9b:59:01:ff:35:47:a9:98:13:4a:71:c1:59:bc:2d:61:2c:
         e3:80:ed:01:e1:02:3b:3c:cd:80:12:20:79:75:18:8c:c8:02:
         b0:aa:19:f8:9d:48:91:dd:d5:e6:c8:54:67:e6:59:a8:f0:d0:
         1a:99:a1:64:7c:8d:69:ca:33:87:73:1f:6d:07:c4:02:f9:21:
         18:74:33:f3:c4:58:ab:6b:b9:7d:28:54:e1:e0:f4:67:21:a8:
         50:e0:3b:4f:22:a7:63:3c:db:e8:77:dc:1f:09:c8:95:b9:09:
         e8:ba:18:eb:92:a3:9f:8e:55:38:85:c9:af:a5:d9:75:02:c6:
         a6:61:92:31:10:31:6d:b6:3a:88:01:a2:b8:5a:78:5e:9f:18:
         f4:1b:67:82:6f:01:5d:bc:01:4a:26:be:2d:32:37:50:e7:7a:
         44:90:db:60:c6:69:a1:eb:5b:9f:5b:0f:b9:27:76:80:e0:d0:
         ae:8a:a9:c1
  

• openssl genrsa -out acme.com.key 2048 This generates your private key in the current directory, in a file named "acme.com.key". It uses the RSA algorithm, and generates a key of 2048 bits. It will be in a pem format.

From ca.godaddy.com again. This time for apache server.

Set your mail server settings, and set enable_installer to enable the setup wizard: (this for if your postfix and dovecot is all on the same server)

#+BEGIN_SRC python /etc/webapps/roundcubemail/config/config.inc.php $config['db_dsnw'] = 'mysql://roundcube:****@localhost/roundcubemail'; $config['default_host'] = 'tls://localhost'; // IMAP host $config['smtp_server'] = 'tls://localhost'; $config['smtp_port'] = 587; $config['des_key'] = 'some_{awesomelongsemirandomstring}'; $config['enable_installer'] = true;

#+END_SRC

From the above, it appears that muy certificate (a.k.a. public key) is stored in

• /etc/ssl/certs/vm2.zintis.ops.crt

And my private key is stored in :

• /etc/ssl/private/vm2.zintis.ops.key

See also /usr/share/ca-certificates

For postfix authentication for SMTP should enable SMTP-AUTH .

sudo postconf -e 'smtpd_sasl_type = dovecot'
sudo postconf -e 'smtpd_sasl_path = private/auth'
sudo postconf -e 'smtpd_sasl_local_domain ='
sudo postconf -e 'smtpd_sasl_security_options = noanonymous'
sudo postconf -e 'broken_sasl_auth_clients = yes'
sudo postconf -e 'smtpd_sasl_auth_enable = yes'
sudo postconf -e 'smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination'

And for main.cf (for postfix)

sudo postconf -e 'smtp_tls_security_level = may'
sudo postconf -e 'smtpd_tls_security_level = may'
sudo postconf -e 'smtp_tls_note_starttls_offer = yes'
sudo postconf -e 'smtpd_tls_loglevel = 1'
sudo postconf -e 'smtpd_tls_received_header = yes'

Note that the above can be entered in the main.cf config file rather than one at a time from the command line. (I think)

I tried running a dnf upgrade on my lab vms and got this error.

root@vm3~[1000] $
dnf upgrade -y
Last metadata expiration check: 6:08:52 ago on Thu 02 Dec 2021 11:27:22 AM EST.
Dependencies resolved.
===========================================================================================================================================================
 Package                                 Architecture                   Version                                       Repository                      Size
===========================================================================================================================================================
Upgrading:
 ca-certificates                         noarch                         2021.2.50-80.0.el8_4                          baseos                         390 k

Transaction Summary
===========================================================================================================================================================
Upgrade  1 Package

Total size: 390 k
Downloading Packages:
[SKIPPED] ca-certificates-2021.2.50-80.0.el8_4.noarch.rpm: Already downloaded                                                                             
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                   1/1 
  Running scriptlet: ca-certificates-2021.2.50-80.0.el8_4.noarch                                                                                       1/2 
  Upgrading        : ca-certificates-2021.2.50-80.0.el8_4.noarch                                                                                       1/2 
Error unpacking rpm package ca-certificates-2021.2.50-80.0.el8_4.noarch
  Verifying        : ca-certificates-2021.2.50-80.0.el8_4.noarch                                                                                       1/2 
  Verifying        : ca-certificates-2019.2.32-80.0.el8_1.noarch                                                                                       2/2 

Failed:
  ca-certificates-2019.2.32-80.0.el8_1.noarch                                  ca-certificates-2021.2.50-80.0.el8_4.noarch                                 

Error: Transaction failed

Particularly, the ca-certificates upgrades failed. Same error message when trying to specifically upgrade the ca-certificates:

sudo dnf upgrade ca-certificates
[sudo] password for zintis: 
Last metadata expiration check: 0:59:07 ago on Thu 02 Dec 2021 11:42:14 AM EST.
Dependencies resolved.
===========================================================================================================================================================
 Package                                 Architecture                   Version                                       Repository                      Size
===========================================================================================================================================================
Upgrading:
 ca-certificates                         noarch                         2021.2.50-80.0.el8_4                          baseos                         390 k

Transaction Summary
===========================================================================================================================================================
Upgrade  1 Package

Total size: 390 k
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] ca-certificates-2021.2.50-80.0.el8_4.noarch.rpm: Already downloaded                                                                             
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                   1/1 
  Running scriptlet: ca-certificates-2021.2.50-80.0.el8_4.noarch                                                                                       1/2 
  Upgrading        : ca-certificates-2021.2.50-80.0.el8_4.noarch                                                                                       1/2 
Error unpacking rpm package ca-certificates-2021.2.50-80.0.el8_4.noarch
  Verifying        : ca-certificates-2021.2.50-80.0.el8_4.noarch                                                                                       1/2 
  Verifying        : ca-certificates-2019.2.32-80.0.el8_1.noarch                                                                                       2/2 

Failed:
  ca-certificates-2019.2.32-80.0.el8_1.noarch                                  ca-certificates-2021.2.50-80.0.el8_4.noarch                                 

Error: Transaction failed

I found this article on access.redhat.com that worked verbatim for me. I ran this as root using sudo -i

1. move existing certs to a new backup directory, cert.bak

cd /root
mkdir -p cert.bak

# move certificates into the backup directory just created.
rpm -Vv ca-certificates | awk '$1!="........." && $2!="d" {system("mv -v " $NF " /root/cert.bak")}'

You should see output similar to this:

renamed '/etc/pki/ca-trust/README' -> '/root/cert.bak/README'
renamed '/etc/pki/ca-trust/ca-legacy.conf' -> '/root/cert.bak/ca-legacy.conf'
renamed '/etc/pki/ca-trust/extracted/README' -> '/root/cert.bak/README'
renamed '/etc/pki/ca-trust/extracted/edk2/README' -> '/root/cert.bak/README'
renamed '/etc/pki/ca-trust/extracted/java/README' -> '/root/cert.bak/README'
renamed '/etc/pki/ca-trust/extracted/openssl/README' -> '/root/cert.bak/README'
renamed '/etc/pki/ca-trust/extracted/pem/README' -> '/root/cert.bak/README'
renamed '/etc/pki/ca-trust/source/README' -> '/root/cert.bak/README'
renamed '/etc/ssl/certs' -> '/root/cert.bak/certs'
root@vm2~[1004] $

1. reinstall ca-certificates (check if update exists, then run update, then run reinstall, all in one line:

   dnf check-update ca-certificates; (($?==100)) && yum update ca-certificates || yum reinstall ca-certificates
   

   You should see output similar to this:

   Last metadata expiration check: 6:09:39 ago on Thu 02 Dec 2021 11:27:22 AM EST.
   
   ca-certificates.noarch               2021.2.50-80.0.el8_4                baseos
   Last metadata expiration check: 6:09:40 ago on Thu 02 Dec 2021 11:27:22 AM EST.
   Dependencies resolved.
   =================================================================================
    Package              Architecture     Version               Repository   Size
   =================================================================================
   Upgrading:
    ca-certificates      noarch        v  2021.2.50-80.0.el8_4  baseos       390 k
   
   Transaction Summary
   =================================================================================
   Upgrade  1 Package
   
   Total download size: 390 k
   Is this ok [y/N]: y
   Downloading Packages:
   ca-certificates-2021.2.50-80.0.el8_4.noarch.rpm        1.5 MB/s | 390 kB     00:00    
   ----------------------------------------------------------------------------------
   Total                                                  645 kB/s | 390 kB     00:00     
   Running transaction check
   Transaction check succeeded.
   Running transaction test
   Transaction test succeeded.
   Running transaction
     Preparing        :                                                          1/1 
     Running scriptlet: ca-certificates-2021.2.50-80.0.el8_4.noarch              1/2 
     Upgrading        : ca-certificates-2021.2.50-80.0.el8_4.noarch              1/2 
     Running scriptlet: ca-certificates-2021.2.50-80.0.el8_4.noarch              1/2 
     Cleanup          : ca-certificates-2019.2.32-80.0.el8_1.noarch              2/2 
     Running scriptlet: ca-certificates-2021.2.50-80.0.el8_4.noarch              2/2 
     Running scriptlet: ca-certificates-2019.2.32-80.0.el8_1.noarch              2/2 
     Verifying        : ca-certificates-2021.2.50-80.0.el8_4.noarch              1/2 
     Verifying        : ca-certificates-2019.2.32-80.0.el8_1.noarch              2/2 
   
   Upgraded:
     ca-certificates-2021.2.50-80.0.el8_4.noarch                                                                                                              
   
   Complete!
   
   

2. Check that only these two files are found in directories
   • /etc/pki/ca-trust/source
   • /etc/pki/ca-trust/source/anchors

   find /etc/pki/ca-trust/source{,/anchors} -maxdepth 1 -not -type d -exec ls -1 {} +
   

   You should see only these two files:

   /etc/pki/ca-trust/source/ca-bundle.legacy.crt
   /etc/pki/ca-trust/source/README
   

   If you see other files, move them to the backup directory manually.

3. Ensure the /usr/share/pki/ca-trust-source/ and /usr/share/pki/ca-trust-source/ directories together contain no more than the following 2 files:
   • /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
   • /usr/share/pki/ca-trust-source/README

1. update your certificate authority trust with this single command:

   update-ca-trust extract
   

   This command gave no output, but confirm that the command ran with no errors. You can read about it using man update-ca-trust

2. Run the dnf upgrade -y command again. This time it should work.