Postfix Transport Layer Security Protocol (TLS)

The "Transport Layer Security Protocol" evolved from SSL can use encryption technology to protect the privacy of TCP communication (information leakage) and integrity (whether data is tampered with during transmission ). RFC 3207 specifies an extended mechanism called starttls for SMTP. Its main purpose is to ensure the privacy of point-to-point communication and ensure that your emails are not sent to the wrong place. For example, avoid shipping parcels to illegal systems disguised as recipient places. Another useful application is to combine with SASL to prevent the plain password from flowing through the network in plain text.
One of the notable advantages of TLS is that the two systems can be reliably identified and secured without prior arrangement, even "powerful Verification" can be achieved-if the user's Mua is supported. With the client certificate, the mail server can be sure that the client that comes in online is indeed the identity claimed by the other party. "Client certificate" is an identifier signed by cryptographic technology. It can be used for replacement or with SASL verification, but additional management control is required, because you have to generate a dedicated certificate for each client and install these certificates one by one on each client. However, if you only need to use TLS to encrypt and verify data, it is quite easy to set.
There is a very important concept to remember: TLS is not used to protect mail content. When the client and server communicate with each other through TLS, everything (including the email itself) is indeed encoded into a ciphertext. However, TLS can protect communication between the two systems only. After the server receives the email, it may still store it in plain text. When the Server delivers the email to the next stop or the recipient downloads the email from the server, the content of the email may still flow through the network in plain text. In other words, unless you are sure that the entire process from the starting point to the end point is encrypted, you cannot protect the whole site from being leaked. To achieve point-to-point privacy, you need a client solution, such as PGP or S/MIME.

Postfix and TLS

Postfix supports TLS. It is provided by a set of patch files written by Lutz janicke. This set of patch files can be obtained from the add-on software link on the Postfix homepage. If you use the pre-compiled Postfix package that is included with the platform, make sure that this version does contain the TLS patch.
In addition to the TLS support for Postfix, you must create and set the TLS Certificate. You need a public key and a private key ). The public key is a certificate that represents the server's identity. You must apply to a Certificate Authority (CA). After they have obtained an application from you, they will sign a public key for you with their own digital signatures. As long as the client is willing to trust the CA signature, it will indirectly trust the system as evidenced by the CA's issued public key-your server. In addition to your own certificate, you must also obtain the CA Public Key (the CA that issued the certificate to you ).
It is important for the buyer to prove the identity of the seller for electronic transactions. Therefore, it is indeed necessary for network traders to spend money to obtain the CA signature. However, for secure communication, it is not absolutely necessary to determine whether the server's public key comes from a trusted ca. This means that you can assume the role of a CA and issue a certificate to yourself. When the client Mua connects to your TLS server, if you do not know the CA certificate you are using, Mua usually provides an opportunity for users, let the user decide whether to trust the CA and whether to include the CA certificate in the approval list.

TLS Certificate
Postfix TLS patch requires the OpenSSL function library. The OpenSSL package comes with a set of command line tools for managing certificates. You can use these tools to create certificates. For Postfix, all certificates must be in PEM format. The default output format of OpenSSL is PEM, so you can generate a certificate available for Postfix without any conversion. The default installation directory of OpenSSL is/usr/local/SSL. The command line tool required for managing certificates is OpenSSL.

Self-built authentication center
The server certificate must be signed by the CA. You can pay for it and ask a trusted CA to sign it for you. However, you do not need to spend the money for the purposes of confidentiality. The OpenSSL package provides a script that allows you to open your own Ca and sign your own certificate. In the OpenSSL installation directory, type the following command:
Misc/CA. pl-newca
Then answer all the questions. the/democa/directory generates all the files required to open the CA, including the "CA digital signature" (also known as "Root Certificate") that can be used to sign the certificate ")

TLS Certificate Overview
TLS uses public key encryption technology to enable private communication between clients and servers. In addition, TLS can ensure that no one can tamper with the information during transmission, or impersonate a party, because the agreement itself allows the communication parties to authenticate each other's identities. However, again, the benefits of TLS are limited to the two ends of TLS. TLS cannot guarantee what happened before the data is transmitted and what will be processed after the data is transmitted to the destination.
The principle of public key encryption technology is to use a pair of complementary keys, one of which can be disclosed to everyone, known as the "Public Key", while the other ygie key can only be owned by individuals and cannot be leaked, therefore, it is called "Private Key" or "key ". Data encrypted by the Public Key can only be decrypted by the private key, and vice versa. With this feature, the public key can be used to allow others to transmit private data to you, and you can use a private key to prove your identity. When someone else wants to transmit confidential data to you, the other party can use the public key you provided in advance to encrypt the data, because only your own private key can be used for decryption, you are not afraid of confidential data leakage (unless you disclose your private key ). How does the private key prove its identity? You can use your own private key to encrypt a copy of data (this action is called "signature"). If the other party can use your public key to unbind it, it means that the data must come from you, it cannot be someone else (unless you disclose your key to someone else ). Therefore, your key can be viewed as your personal digital signature. In general, you should try to deploy the public key as much as possible, and the key must be protected at no cost.
When you receive a public key from someone else, how can you believe that the owner of the public key is indeed the one claimed by the other party? In fact, when the public key is distributed, an identifier representing the owner of the public key is usually the Host Name of the server. The party receiving the public key can identify whether the public key owner is the current online object by verifying that the identifier matches the host name identified by DNS.
A ca digital signature is called a certificate. Ca is usually a third-party organization trusted by both parties. Theoretically, the Ca proves that the identity of the public key owner has been investigated and confirmed by the ca. The person who obtains the public key can believe that the public key actually belongs to the declared owner. In other words, the credit basis of the certificate comes from your trust in the CA. It is worth noting that Ca only guarantees the identity of the certificate owner, rather than its credit.
In the encrypted communication process, the public/private key is only used in the initial stage of online, so that both parties can determine the identity of the other party and negotiate a random session key and the actual communication content, this session key is used for encryption and decryption. A session key is used only for one communication. After the communication is completed, the session key can be lost.
Let's take a look at how the client and server communicate secretly. First, the client comes online to the server and requests for private communication. For the web server, the client uses the HTTPS command; For the SMTP server, the client issues the starttls command.
If the server agrees to the request, a certificate signed by the CA is returned, which contains the digital signature of the CA and an identifier representing the server. The client checks whether the server identifier meets expectations and whether the digital signature of the CA is in the approval list. If both checks pass, the client and the server can easily start session key negotiation to determine which encryption algorithm will be used for subsequent communication content, and generate a session key that is only used for this communication. Then, the session key generated by the Protocol can be used to communicate with the algorithm secretly.

Generate server certificate
The first step to generate a server certificate is to use the OpenSSL tool to generate a pair of public and private keys for the server, and then generate a "Certificate Signing Request" (CSR ), the CSR and the Public Key are handed over to the CA for signing. Public key certificates signed by the CA can be widely distributed, but the private key must be kept with caution. In fact, many application systems add and seal the private key to a special file. before accessing the private key, you must provide the password (passphrase) before decryption, this method of storing private keys is called "sealed ". However, Postfix needs to be able to directly access the private key and cannot be sealed, because the access to the private key takes place at runtime, and you cannot provide a password in real time.
The OpenSSL package provides a set of scripts to help you generate public and private keys and CSR. However, the keys they generate are "sealed". Therefore, you must directly use the OpenSSL command to generate a public/private key:
OpenSSL req-New-nodes-keyout mailken. pem-out mailreq. pem-days 365
The-New Option for OpenSSL indicates that you want to generate a public/private key and a CSR. The-nodes option indicates that the private key file is not encrypted, and the-keyout and-out indicate the name of the private key file and the CSR file respectively. Last,-days 365 indicates that the validity period of the certificate is one year.
If you use a third-party ca, follow the CA's instructions and submit your CSR to ask them to sign. If you assume the role of a ca, you can use the following command to issue a certificate:
OpenSSL ca-out mail_signed_cert.pem-lnfiles mailreq. pem
The mail_signed_cert.pem file generated by this step is the certificate issued by the CA.
You may want to copy all the certificate files used by Postfix/TLS to a convenient location. If you follow the preceding steps, run the following command to copy the Certificate file to the Postfix configuration directory:
CP/usr/local/SSL/mailkey. PEM/etc/Postfix
CP/usr/local/SSL/mail_signet_cert.pem/etc/Postfix
The mailkey. pem file contains the server key. mail_signed_cert.pem is a public certificate signed by the CA. Because Postfix cannot use a sealed private key file, you should use the strictest permission mode to protect the private key file:
Chown root/etc/Postfix/mailkey. pem
Chmod 400/etc/Postfix/mailkey. pem
The above command grants the ownership of the private key file to the root account, and only the root account can read the file.

Install CA certificate
Postfix/TLS server must be able to access the CA's public certificate (that is, the so-called "Root Certificate "), this includes the CA signed by your server and each CA that issues a certificate to your users. Of course, if both parties use the same CA, you only need to install a root certificate.
If your server certificate is issued to you by yourself, copy the cacert. pem file generated by the previous ca. pl script to the Postfix configuration directory:
CP/usr/local/SSL/democa/cacert. PEM/etc/Postfix
If your server or any client certificate is issued by a third-party ca, you must try to obtain the root certificate of these Ca (in PEM format); for CA that you do not trust, naturally, there is no need to obtain their root certificate. Set all the collected root certificates to the/etc/Postfix/cacert. pem file.
There are two ways to install the new CA root certificate to the Postfix/TLS system. The first method is to centralize all root certificates in one file and point the smtpd_tls_cafile parameter to this file. You only need to attach the New Root Certificate to the end of the existing file. For example, if the original CA root certificate is stored in/etc/Postfix/cacert. in the PEM file, while the root certificate of the new CA is stored in newca. in the PEM file, the following command can include the new root certificate in the approval list:
CP/etc/Postfix/cacert. PEM/etc/Postfix/cacert. pem. Old
Cat newca. pem>/etc/Postfix/cacert. pem
Another method is to set the root certificate of each CA to individual files under a dedicated directory and direct the smtpd_tls_capath parameter to this directory. In the future, whenever you need to install a new CA root certificate, you just need to store the new certificate file in this directory, and then execute an OpenSSL c_rehash command.
This method makes maintenance easier when you have many CA root certificates to process. However, if your Postfix is run in the chroot environment, you also need to copy the New Root Certificate file to the corresponding directory in the chroot environment, and then run Postfix reload to make the new certificate valid.

Set Postfix/TLS
Postfix TLS patch introduces a set of parameters about the TLS operating environment. This section only lists the key parameters required for the basic configuration. For the complete TLS parameter description, see the sample configuration file attached to the TLS patch.
Smtpd_use_tls
Start TLS support. If this parameter is not set or set to no, the Postfix runs in the same way as if there is no TLS patch. For example:
Smtpd_use_tls = Yes
Smtpd_tls_key_file
Point to the private key file of the server. For example:
Smtpd_tls-key_file =/etc/Postfix/mailkey. pem
Smtpd_tls_cert_file
Point to the server's PEM Certificate file (must be signed by the CA ). For example:
Smtpd_tls_cert_file =/etc/Postfix/mail_signed_cert.pem
Smtpd_tls_cafile
Point to the CA root certificate file. This file contains all the public certificates of the CAS you are willing to trust. For example:
Smtpd_tls_cafile =/etc/Postfix/cacert. pem
Smtpd_tls_capath
Point to the CA root certificate file directory. Each PEM file in this directory contains a CA Public certificate that you trust. For example:
Smtpd_tls_capath =/etc/Postfix/certs
After you set the preceding parameters to the main. cf configuration file and run the Postfix reload command, Your Postfix/TLS server will be able to communicate with each other secretly and be ready to receive the starttls command from the client.

Sort out the Setting Process of Postfix/TLS
To sum up the above basic knowledge, the general process of setting TLS on the Postfix system is as follows:
1. Install the OpenSSL package because we need to use this package to generate a TLS Certificate.
2. Use TLS patch and re-compile and install Postfix.
3. Generate a server certificate and a Certificate Signing Request (CSR ). Then, submit the two to the CA with a certain credibility to sign the request, or assume the CA role and issue the certificate to yourself.
4. Install all certificate files (server keys, CSR, and CA root certificates) in the Postfix directory.
5. Edit main. CF and set the following TLS parameters:
Smtpd_use_tls = Yes
Smtpd_tls_key-file =/etc/Postfix/mailkey. pem
Smtpd_tls_cert_file =/etc/Postfix/mail_sigend_cert.pem
Smtpd_tls_cafile =/etc/Postfix/cacert. pem
If you need to set other TLS parameters, now is the time.
6. Reload the Postfix so that the changes made in Main. Cf take effect.
Now, the Postfix/TLS server can handle the problem whenever a client requires private communication.

Obtain client certificate
You may want to use client certificates instead of or enhance other SMTP verification technologies. The client certificate is a very reliable verification method, because it is very difficult to fake.
The client certificate must be issued by the CA. If you want to select a CA to issue a certificate to your user, you should follow the Ca application process to obtain the client certificate. Of course, you can also use the tools provided by the OpenSSL package to assume the CA role and issue certificates to users.

Create client certificate
The client certificate production program is similar to the process of creating a server certificate. The only difference is that there is one more step: Change the signed certificate to the Mua available format. Most popular Mua files prefer the PKCS12 format, which encapsulates signed certificates and private keys and protects them with a single password. If you use a third-party CA, the Ca should be able to provide a certificate file in the correct format to meet your Mua requirements. If you sign the certificate yourself, you should make a certificate file in PKCS12 format for distribution to users. The certificate file should contain the certificate (Public Key) issued to the user, the private key that is used together with the certificate, and your own CA root certificate.
For every user whose identity you intend to verify with a certificate, you must generate an exclusive public/private key. You should specify the naming rule for "Distinguishing names. Generally, you should use the personal email address or host name of the client machine when generating the certificate. For example, assume that you decide to distinguish the name from the email address, and now you want to issue a certificate to the kdent@ora.com user, as shown below:
1. Use the OpenSSL command to generate a pair of public and private keys. Please note that your own public key must also have the CA Signature
OpenSSL req-New-nodes-keyout kdentkey. pem-out kdentreq. pem-days 365
Because the-new option is used, the above command generates a private key and a CSR. -The nodes option requires OpenSSL not to seal the private key. -Keyout and-out indicate the private key file and CSR file respectively. Last,-days 365 indicates that the certificate is valid for one year.
2. Sign the certificate. If you work with Ca, submit the CSR generated in the previous step according to their application process and ask them to sign the CSR. If you are a ca, run the following command to sign the certificate:
OpenSSL ca-out kdent_signed-cert.pem-infiles kdentreq. pem
3. Convert signed certificate files into appropriate formats. Ask which Mua is used by the user and convert the Certificate file signed by the CA to the acceptable format of the Mua:
OpenSSL PKCS12-In kdent_sigend_cert.pem-inkey kdentkey. pem-certfile/etc/Postfix/cacert. pem-out kdent. p12-export-name "kdent@ora.com"
This command requires you to provide a password to protect the generated file (kdent. p12), and you must inform the user of the password. -The certfile option specifies your own CA root certificate file. After that, you can deliver the kdent. p12 file and script to the user.
In the last step, install the Certificate file Mua on your own. Most Mua provides relatively simple steps to import the Certificate file, so this is not a problem. If you have users who are not good at computer operations, give proper instructions.

Set client certificate verification
Postfix/TLS determines whether the certificate is acceptable based on the "fingerprint" of the certificate. "Fingerprint" is the value calculated from the certificate. Different certificates cannot calculate the same fingerprint. You must store the fingerprints of each client certificate in a standard Postfix query table. When a client displays its certificate, Postfix/TLS calculates the fingerprint of the certificate and checks whether the fingerprint is registered in the query table to determine whether to allow the client to use the forwarding service.
You must collect the certificate fingerprints of each authorized client. Many Mua have the certificate fingerprint function. You can ask the user to provide the certificate fingerprint they see in Mua to you. If your certificate is issued by yourself, you can use the OpenSSL X509 command to calculate the fingerprint:
OpenSSL X509-fingerprint-noout-In kdent_signed_cert.pem | cut-D-F2
The entire configuration process is as follows:
1. obtain the certificate fingerprints of each user. You can follow the above steps or ask the user to provide it to you.
2. Set the fingerprints of the collected channels to the/etc/Postfix/clientcerts file and specify the corresponding Identification name.
3. Convert the created clientcerts query table into a database:
Postmap/etc/Postfix/clientcerts
4. Edit the main. cf configuration file and add the following parameters:
Relay_clientcerts = hash:/etc/Postfix/clientcerts
Smtpd_tls_ask_cert = Yes
Smtpd_recipient_restrictions =
Permit_mynetworks
Permit_tls_clientcerts
Reject_unauth_destination
5. Reload the Postfix so that the changes made in Main. Cf take effect:
Postfix relaod

TLS/SMTP client setting process

Since the SMTP/TLS server can require the client to present the certificate, when the Postfix assumes the client role, it is sent to another SMTP server, or other SMTP servers are required to forward emails-smtp mda may also be required to provide client certificates. Note that only one client certificate represents your own in a postfix system. It is possible to install multiple client certificates unless you have set other MDA in master. Cf.
The certificate used to prove the identity of the server can also be used to prove the identity of the client. However, the formal certificate issued by the Ca does not necessarily allow you to use both identities at the same time. In this case, you may need to apply for another client certificate from the CA. The self-Signed server certificate we created previously has no such restriction. No matter how your client certificate comes from, the identified name must comply with the host name specified by the myhostname parameter.
The process of creating a client certificate is the same as that of creating a server certificate. If you want to use the same certificate, you only need to point several TLS client parameters to the same file used by the TLS server parameters.
The following are the most basic TLS client parameters.
Smtp_use_tls
Start TLS support for Postfix SMTP client.
Smtp_use_tls = Yes
Smtp_tls_key_file
Point to the private key file corresponding to the client certificate.
Smtp_tls_key_file =/etc/Postfix/mailkey. pem
Smtp_tls_cert_file
Point to the client certificate file.
Smtp_tls_cert_file =/etc/Postfix/mail_signed_cert.pem
Smtp_tls_cafile
The root certificate file of the CA that signs the client certificate, for example:
Smtp_tls_cafile =/etc/Postfix/cacert. pem
Assuming that you want SMTP to use the same certificate as smtpd, the procedure is quite simple:
1. Edit main. CF and set the following parameters:
Smtp_use_tls = Yes
Smtp_tls_key_file =/etc/Postfix/mailkey. pem
Smtp_tls_cert_file =/etc/Postfix/mail_signed_cert.pem
Smtp_tls_cafile =/etc/Postfix/cacert. pem
2. Reload the Postfix to make the change of Main. Cf take effect;
Postfix reload
Now, whenever the Postfix comes online to an SMTP server that shows the client certificate, SMTP provides necessary information.