Postfix Transport Layer Security Protocol (TLS) (1)

PostfixForTlsYes. 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.