CORY's twilight zone > 98備忘録 (tips)[an error occurred while processing this directive] > Postfix TLS認証
Webサーバでは当たり前になっているSSL認証・暗号化も、E-mailでは意外と未対応のサーバが多いようです。しかしこれは、私信だろうが何だろうがお構いなしに、暗号化されない平文の状態でインターネットへ出ていることを意味します。
近頃Webでは何でもhttpsにするのが流行っているようですが、それに比べてE-mailサーバ(MTA)をSMTPS/POPS,IMAPS対応にする話はあまり聞こえません。Webは成り済まし対策の面もあるのでしょうし、MTAはエンドユーザから見えにくくて意識が高まりづらいのかもしれませんが、少なくとも筆者は、暗号化の優先順位はMTAの方が高いように思っています。
かつては年間1万円以上していたSSLサーバ証明書も、Webでの普及に伴い値下がりして数千円で取得できるようになり、手頃感が出てきました。さらに2016年4月より本格サービスとなった Let's Encrypt では、有効期間が3ヶ月ながら、無料で取得でき、更新も自動化できる仕組みが用意されています。これなら、独自CAを立ち上げて自己署名する（俗に言うオレオレ証明書）より手軽で、手間を考えるとむしろ自己署名の方が割高と言えるかもしれません。
そこで、とある SMTPサーバ (Postfix MTA) で TLS による暗号化および証明書ベースの認証を使えるようにした（Postfix を使った SMTPS MTAサーバのみを対象とし、POPS,IMAPS … qmail, dovecot などについては他稿に譲ります）時のメモを整理してみました。
なお、ここでは本稿執筆時点の安定版、FreeBSD 9.2-RELEASE とOS標準の OpenSSL 0.9.8、および Postfix 2.2以降（筆者は 2.10.2 で確認）を使った例を挙げていますが、他のUnix系OSの場合でも部分的に参考になるかもしれません。 もちろん、筆者や第三者が何らの保証をするものではありませんので、いずれにせよ自己責任でお願いします。
◆ Postfix の基本的な設定を済ませる ◆ CA発行のSSLサーバ証明書を購入する ◆ Let's Encrypt の無料サーバ証明書を利用する ◆ ルートCA証明書の用意とサーバ証明書の確認 ◆ Postfixに設定する ■ その他
Postfix に関する情報は巷に多く出ているので各自調べてもらうのが良いでしょう。 とりわけPostfixのぺーじさんの貢献によるところが大きいと思いますが、筆者も非常に助けられており、感謝申し上げます。
Postfixの添付文書「Postfix TLS サポート」に一通りのことがまとめて書かれているので、通読をお勧めします。
というわけで、ここでは基本的な設定に関することは割愛:-)。
なお、いきなり証明書を購入するのが不安なら、まずは自分で署名した証明書（俗に言うオレオレ証明書）を使ってTLSによる暗号化だけでも使えるようにしてみると、良い練習になるでしょう（格安CAがここまでお手軽になると、独自CAによる自己署名はかえって面倒かもしれませんが…）。
今は無料の Let's Encrypt もある時代です、くれぐれも練習用以外（つまり本格運用のサーバ）に自己署名証明書を使わないようにしましょう。
Let's Encrypt の無料サーバ証明書を利用する場合（root権限が必要）は次章へどうぞ
SSLサーバの暗号鍵を商業 CA (Certificate Authority) に署名してもらうと、その証明書は第三者による検証ができるようになります。このあたりの仕組みは他稿に譲りますが、要は、鍵は自分で作ることに変わりはないものの、その鍵が本人のものであることを、信頼できる第三者に証明してもらう仕組みです。
「SSLサーバ証明書」などで検索すると、多くの代理店が引っかかるでしょう。本稿ではSSLストアのRapidSSL を例にしています。米GeoTrust社が提供するサービスの格安版 RapidSSL を扱う日本国内代理店のひとつ。近頃は極端な円安のせいで値上がりしてしまったものの、本稿執筆時点では1年（12ヶ月）で1050円と格安でした。
もちろん実在証明も何もない、数分で自動承認されて出てくるようなお手軽CAですが（申請内容が怪しいと審査が入るようですが）、ドメイン名が乗っ取りなどされていないであろうという程度の信頼性確保に使うには充分でしょう。
他社の格安サービスで取得する場合も、似たような手順になると思われます。
この他、2016年4月に本格サービスが始まったNPOによる完全無料のサービス Let's Encrypt の例は（手順が異なるので）次章で示します。
で、ここからが本稿の本題。
大まかな手順を。まずは自分の秘密鍵を作り、あわせてその秘密鍵に署名してもらうためのリクエスト(CSR)ファイルを作ります。
% openssl genrsa -rand /dev/urandom -des3 2048 > server.key ←秘密鍵を作る 5804 semi-random bytes loaded Generating RSA private key, 2048 bit long modulus ..................+++ .......................+++ e is 65537 (0x10001) Enter pass phrase: （秘密鍵を暗号化するためのパスワード） Verifying - Enter pass phrase: （同上） % chmod 600 server.key ←他の人に見えないようにしておく % openssl req -new -key server.key -out server.csr ←証明書要求データを作る Enter pass phrase for server.key: （秘密鍵を暗号化したときのパスワード） You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:Kanagawa Locality Name (eg, city) []:Kawasaki Organization Name (eg, company) [Internet Widgits Pty Ltd]:Kimagurenote Organizational Unit Name (eg, section) []:（空欄でいい） Common Name (e.g. server FQDN or YOUR name) []:kimagurenote.net Email Address []:（空欄でいい） Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:（空欄） An optional company name []:（空欄） % cat server.csr -----BEGIN CERTIFICATE REQUEST----- MIICpzCCAY8CAQAwYjELMAkGA1UEBhMCSlAxETAPBgNVBAgTCEthbmFnYXdhMREw ... Uxqq/+l1ytKAJ3I= -----END CERTIFICATE REQUEST-----
CA証明書申請時には、最後に出てきた BEGIN CERTIFICATE REQUEST 〜 END CERTIFICATE REQUEST の部分を聞かれるので、申請時にコピーしてWebブラウザ等に貼り付ける。
審査方法は、Webサイトを立ち上げておく必要がある所もあるようですが、筆者が試したRapidSSLの例ではWebサイトを立ち上げていなくてもOKでした（申請内容にもよるかもしれないが）。
申請すると数分程度で、承認を求めるメール（英語）が届きます。この中に書いてあるURLをWebブラウザで開くと、申請内容の確認（日本語、右画像）が出るので、よければ「承認します」ボタンを押します。 手続きが済むと数分で、証明書入りのメール（英語、下記）が届きます。
From: xxxxxxxxx@geotrust.com
Subject: Subject: kimagurenote.net RapidSSL Order: xxxxxxxx Complete
Dear KIMAGURE NOTE,
Congratulations! GeoTrust has approved your request for a RapidSSL certificate.
Your certificate is included at the end of this email.
INSTALLATION INSTRUCTIONS
（中略）
Web Server CERTIFICATE
-----------------
-----BEGIN CERTIFICATE-----
MIIFJDCCBAygAwIBAgIDD+ovMA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNVBAYTAlVT
...
IRBldo5TIUUhFHMaeP22HktJzZx76AF+
-----END CERTIFICATE-----
INTERMEDIATE CA:
---------------------------------------
-----BEGIN CERTIFICATE-----
MIID1TCCAr2gAwIBAgIDAjbRMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
...
LEL2TxyJeN4mTvVvk0wVaydWTQBUbHq3tw==
-----END CERTIFICATE-----
インストール方法などが英文で書かれたメールの文末に、サーバの証明書と、中間CA証明書が入っています。RapidSSLは中間CA証明書が無いとサーバの証明書を検証できない（場合が多い）ので、各々をコピー＆貼り付けでサーバに送ります。
% cat > server.crt -----BEGIN CERTIFICATE----- MIIFJDCCBAygAwIBAgIDD+ovMA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNVBAYTAlVT ... IRBldo5TIUUhFHMaeP22HktJzZx76AF+ -----END CERTIFICATE----- ^D ← 行頭で Ctrl+D を入力 % cat > intermediate.crt -----BEGIN CERTIFICATE----- MIID1TCCAr2gAwIBAgIDAjbRMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT ... LEL2TxyJeN4mTvVvk0wVaydWTQBUbHq3tw== -----END CERTIFICATE----- ^D ← 行頭で Ctrl+D を入力
上記の例では、サーバの証明書を server.crt、中間CA証明書を intermediate.crt というファイル名で保存しています。
なお、承認メールは本ドメインの所定のメールアドレスかwhoisに登録されているメールアドレスを使う必要がありますし、第三者から見て申請内容が疑わしい場合は審査に時間がかかるようなので、申請前にwhoisを確認し、更新しておく（ドメイン代行業者の代理登録になっている場合は、一時的にでも自分の住所名前とメールアドレスに変更しておく）と良いでしょう。
CA発行のSSLサーバ証明書を購入した場合は、本章は不要なので次へどうぞ
SSL(TLS)暗号化を普及させることを目的とするNPOによる Let's Encrypt が2015年12月より公開ベータテストを始め、その実績を踏まえて2016年4月14日より本格運用に移行しました。
このサービスは、認証局としてドメイン名の所有者に無料でサーバー証明書を発行することで、SSL/TLSによるHTTPの暗号化(HTTPS)を誰でも利用できるようにするものですが、同サービスで発行される証明書はメールサーバにも応用できます（クライアント証明書としては利用できない）。
もちろん実在証明はなく、不正使用を最小限にする狙いでしょう、有効期間は3ヶ月に制限されています。取得方法も一般の認証局とは一線を画し、専用のスクリプトで自動的に取得・更新される仕組みを導入しているので、初期設定した後は、cron などを使って自動で更新するようにしておくと、運用が楽になりそうです。
Let's Encrypt の使い方はこちらに日本語の解説（本項執筆時点でまだ公開ベータ時代のものですが、同じ方法が使えます）があるのでそれを参照してもらうとして、以下では FreeBSD（9.3-RELEASE 以降）を使った例を載せておきます。
なお、下記の方法で Let's Encrypt を使うにはroot権限が必要です。レンタルサーバなど root権限のないサーバで使う方法もありますが、自動更新などが使えず、3ヶ月毎の更新作業が煩雑になるので、商業CAの証明書をお勧めします（安い物なら3年有効で4千円以下ですからね…）。
% which git ←gitが使えるか確認 git: Command not found. ←gitが入っていない場合はこうなるので… % pkg install git ←gitをインストール。（すでに入っている場合は不要） ... （途中、確認を求められる） % git clone https://github.com/letsencrypt/letsencrypt ↑証明書の取得・自動更新用スクリプトがダウンロードされる % cd letsencrypt ↑ホームディレクトリ直下に letsencrypt ディレクトリが作成されているので、そこに移動 % su ←以降の操作にはroot権限が必要 # ./letsencrypt-auto --help ←説明が表示されるが… WARNING: FreeBSD support is very experimental at present... if you would like to work on improving it, please ensure you have backups and then run this script again with the --debug flag! ↑ FreeBSD への対応はまだ実験的なので、
バックアップを取るなどの対策をしてから --debug を付けて起動してね！ # ./letsencrypt-auto --help --debug Bootstrapping dependencies via FreeBSD... Updating FreeBSD repository catalogue... ... ←これから使うプログラムが勝手に更新される letsencrypt-auto [SUBCOMMAND] [options] [-d domain] [-d domain] ... The Let's Encrypt agent can obtain and install HTTPS/TLS/SSL certificates. By default, it will attempt to use a webserver both for obtaining and installing the cert. Major SUBCOMMANDS are: ... # /usr/local/sbin/apachectl stop ←Webサーバ(httpd)が動いている場合は一旦止める ※ # ./letsencrypt-auto certonly --standalone --standalone-supported-challenges tls-sni-01 -d kimagurenote.net -d www.kimagurenote.net -d mail.kimagurenote.net ↑ certonly は、証明書の取得のみを自動（インストールは手動）で行う ドメイン名は複数指定できる Checking for new version... Requesting root privileges to run letsencrypt... /root/.local/share/letsencrypt/bin/letsencrypt certonly --standalone ... この間で、初回に限り、メールアドレスの入力と、 規約への同意やIPアドレスの記録を求めるダイアログ（英語）が表示される IMPORTANT NOTES: ↓取得に成功すると、こんな感じ。 - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/kimagurenote.net/fullchain.pem. Your cert will expire on 2016-07-11. To obtain a new version of the certificate in the future, simply run Let's Encrypt again. - If you like Let's Encrypt, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le # /usr/local/sbin/apachectl start ←Webサーバ(httpd)が動いていた場合は再起動する ※
※上記の例では、自動認証にTCPポート443を使います。現在WebサーバでHTTPSを使っていない場合は、Webサーバを止めなくても差し支えありません。
逆に、当該WebサーバではHTTPSのみを使っており、HTTPを使っていない場合は、パラメータのうち --standalone-supported-challenges tls-sni-01 の部分を削除することで、TCPポート80を使うようになり、Webサーバを止めずに実行できます。
途中で入力したメールアドレスと規約等への同意は記憶され、次からは省略されます。
このように、最初に専用スクリプトをインストールする手間はありますが、一旦設定してしまえば、後は自動的に更新できるようになっており、一般的な格安商業CAを使うよりも更に簡単になっています。
最後の表示に書いてある通りですが、下記のファイルが生成されます。
いちいち「最新の」と書いた理由は、このスクリプトが自動更新に対応しており、更新される度にファイルが蓄積されてゆくからです。上記のパスは、その最新のファイルに自動的に設定されるシンボリックリンクの場所を指しています。
届いた証明書が正しく使えるかどうか、検証しておくと良いのですが、ここで意外とはまるかもしれません…いや筆者ははまったのですよ(苦笑)。
ここまでは何の変哲もなく。
% openssl x509 -text -in server.crt Certificate: Data: Version: 3 (0x2) Serial Number: 1042991 (0xfea2f) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=GeoTrust, Inc., CN=RapidSSL CA Validity Not Before: Jan 4 18:05:06 2014 GMT Not After : Jan 7 18:44:44 2015 GMT Subject: serialNumber=***, OU=GT**, OU=See www.rapidssl.com/resources/cps (c)14, OU=Domain Control Validated - RapidSSL(R), CN=kimagurenote.net
Webブラウザを使っていると、大手認証局のルート証明書はWebブラウザに入ってくるのが当たり前。 OSにも、たとえば Microsoft Windows や Apple Mac OS X では、ブラウザだけでなく自社のアップデートサービスに使う必要からも、ルート証明書がOSに付いてきます（Windows Update のルート証明書の暗号化性能が低くてセキュリティホールになったりもしましたが…）。
一方、Unix系OSで一般的に使われているOpenSSLにはルートCA証明書は入っておらず（Linuxはdistributorが入れている場合があります）、しかしここに載っているように、信頼できるルートCA証明書を予め用意しておかないと証明書を検証しようがありません。
OpenSSL の faq を見ると、こう書いてあります。
「ウチでは審査基準を持ってないからルートCA証明書は入れていないよ。アプリケーション開発者や管理者の判断で入れてね。または、たとえば Mozilla のを入れている人がいるよ。」
ルートCA証明書は、第三者との相互認証を確立する上で基盤になる大事な物ですが、それだけにバンドルするルート証明書の選定には厳しい基準が求められます（そのはずです）。セキュリティホールになるような脆弱なルート証明書をバンドルしてしまうと、（Windowsで実際に起きたように）かえってセキュリティホールになりかねません。
下手に入れるくらいなら入れない方が安全、という考え方はとても正しいのですが、一方で使い勝手がよろしくない面もありますね。
では皆さんどうしているかを見ると、Mozilla から拝借しているんですね(笑)。例えば FreeBSD はルート証明書がバンドルされていないOSのひとつですが、Mozilla がバンドルしたルートCA証明書が ports/packages (ca_root_nss) になっており、これが広く使われているようです。
本稿執筆時点の FreeBSD/i386, pc98 では下記の要領で入れることができます：
# pkg_add ftp://ftp.jp.freebsd.org/pub/FreeBSD/ports/i386/packages/security/ca_root_nss-3.15.1.tbz # ln -s /usr/local/share/certs/ca-root-nss.crt /etc/ssl/cert.pem
パッケージが無い場合は、OpenSSL の faq で紹介されている updating ca-bundle.crt に載っているperlスクリプトを拝借して動かせば良いでしょう。ちなみに $cvsroot の設定値は Mozilla 開発者ガイドに載っています。
パッケージは mozilla-rootcerts、設置場所（symlinkを張る先）は /etc/openssl/cert.pem
取得した証明書が正しく検証できるかどうか、openssl verify で確かめておきます。
上記の要領でルートCA証明書を用意した上で、下記のように検証してみます。
% openssl verify -purpose sslserver -untrusted intermediate.crt server.crt server.crt: OK
ルートCA証明書や中間証明書を含めて正しく配置されていないと、ここで "unable to get issuer certificate" といったエラーになります。root権限が無いなどでルートCA証明書をインストールできない場合は、下記のように場所を指定してもOK。
% openssl verify -purpose sslserver -CAfile /usr/local/share/certs/ca-root-nss.crt -untrusted intermediate.crt server.crt
筆者はこのパラメータ指定ではまったのですが、中間CA証明書をサーバ証明書に連結してもうまく検証できず、別々のファイルにして -untrusted で指定してやらないとだめなようです。
なお、いずれの証明書もPEM形式（-----BEGIN CERTIFICATE----- から始まる、文字の羅列として扱える形式）で用意する必要があります。
ようやくここまできました(笑)。
以降の手順はroot権限にて行います。
まず、上記で用意した server.crt と intermediate.crt（中間CA証明書が必要な場合）は、Postfix では連結して1つのファイルにした物 (server_intermediate.crt) を使います。その際、サーバ証明書を先に、中間CA証明書を後にします（ここに書いてある通り）。 これを、Postfix の main.cf と同じディレクトリ（/etc/postfix など）に配置します。
% su # cat server.crt intermediate.crt > /etc/postfix/server_intermediate.crt
連結する際、元のファイルの最後にLF（改行）が入っていないとうまく動作しないので、確認しておきます。
# grep '-' /etc/postfix/server_intermediate.crt -----BEGIN CERTIFICATE----- -----END CERTIFICATE----------BEGIN CERTIFICATE----- -----END CERTIFICATE-----
もし、上記のように END〜 と BEGIN〜 がつながっている行がある場合は、テキストエディタ（viでもeeでも使いやすい物を）で開き、間に改行を入れてやります。
次に、サーバの秘密鍵 (server.key) を、Postfix の main.cf と同じディレクトリに配置します。秘密鍵はパスワード保護を除去しておく必要があります。また、root以外に見えないようにします。
# openssl rsa -in server.key -out /etc/postfix/server.key ← パスワードを設定していない秘密鍵を書き出す Enter pass phrase for server.key: （秘密鍵を暗号化したときのパスワード） writing RSA key # chmod 600 /etc/postfix/server.key
/etc/postfix/main.cf を編集し、下記値を追加します。 （この設定では、TLSを使わない／証明書を検証できないクライアント・サーバの接続も許可されます。）
smtpd_tls_CAfile = /usr/local/share/certs/ca-root-nss.crt smtpd_tls_cert_file = $config_directory/server_intermediate.crt smtpd_tls_key_file = $config_directory/server.key smtpd_tls_ask_ccert = yes ← SMTPクライアントの証明書提示を要求しない場合は no smtpd_tls_received_header = yes smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache smtpd_tls_loglevel = 1 smtpd_tls_security_level = may ← Postfix 2.3〜: TLS接続を有効にする（強制はしない） smtpd_use_tls = yes ← Postfix 2.2: TLS接続を有効にする（強制はしない） smtpd_tls_auth_only = yes ← 認証(AUTH)が必要なメールクライアントにはTLS接続を必須にしたい場合 smtp_tls_CAfile = /usr/local/share/certs/ca-root-nss.crt smtp_tls_cert_file = $config_directory/server_intermediate.crt smtp_tls_key_file = $config_directory/server.key smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache smtp_tls_loglevel = 1 smtp_tls_security_level = may ← Postfix 2.3〜: TLS接続を有効にする（強制はしない） smtp_use_tls = yes ← Postfix 2.2: TLS接続を有効にする（強制はしない） tls_random_source = dev:/dev/urandom
設定ファイルを確認し、問題なければ postfix を再起動。
# /usr/sbin/postfix check # /usr/sbin/postfix stop # /usr/sbin/postfix start # tail /var/log/maillog ... Jan 6 20:05:49 haqua postfix/postfix-script[79888]: starting the Postfix mail system Jan 6 20:05:49 haqua postfix/master[79890]: daemon started -- version 2.10.2, configuration /etc/postfix
ひとまずエラーが出ていないようなら、メールを送受信して試してみます。
実際にメールを送受信して、ログを見て動作を確認します。 （下記例は loglevel = 1 の場合） ただし、相手側の設定によってはサーバ証明書を要求・確認しない場合があり、この場合は Untrusted TLS connection（相手サーバの証明書が検証できない）、Anonymous TLS connection（相手クライアントがサーバ証明書の提示を求めてこない）としてログに残ります。その例を以下に付けておきます。
また、実際にサーバ証明書の検証を行うMTAに当たるまでいくつか試してみると良いと思いますが、筆者が試した時には Gmail がサーバ証明書の検証・提示を行っていたので、その例 (Trusted TLS connection) も付けておきます。
% tail /var/log/maillog ... Jan 6 20:17:37 haqua postfix/cleanup[80069]: 2F79E3AC9C: message-id=<***> Jan 6 20:17:37 haqua postfix/qmgr[80053]: 2F79E3AC9C: from=<***@kimagurenote.net>, size=1104, nrcpt=1 (queue active) Jan 6 20:17:37 haqua postfix/smtp[80071]: Untrusted TLS connection established to example.jp[***.******.***]:25: TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256bits) Jan 6 20:17:37 haqua postfix/smtp[80071]: 2F79E3AC9C: to=<***@example.jp>, relay=example.jp[***.***.***.***]:25, delay=0.74, delays=0.14/0.24/0.32/0.04, dsn=2.0.0, status=sent (250 2.0.0 s06BHbD6036266 Message accepted for delivery) Jan 6 20:17:37 haqua postfix/qmgr[80053]: 2F79E3AC9C: removed
% tail /var/log/maillog ... Jan 6 20:17:40 haqua postfix/smtpd[80075]: connect from example.jp[***.***.***.***] Jan 6 20:17:41 haqua postfix/smtpd[80075]: Anonymous TLS connection established from example.jp[***.***.***.***]: TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits) Jan 6 20:17:41 haqua postfix/smtpd[80075]: 251923AC9D: client=example.jp[***.***.***.***] Jan 6 20:17:41 haqua postfix/cleanup[80069]: 251923AC9D: message-id=<***> Jan 6 20:17:41 haqua postfix/qmgr[80053]: 251923AC9D: from=<***@example.jp>, size=2902, nrcpt=1 (queue active) Jan 6 20:17:41 haqua postfix/local[80078]: 251923AC9D: to=<***@kimagurenote.net>, relay=local, delay=0.05, delays=0.04/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Jan 6 20:17:41 haqua postfix/qmgr[80053]: 251923AC9D: removed Jan 6 20:17:41 haqua postfix/smtpd[80075]: disconnect from example.jp[***.***.***.***]
% tail /var/log/maillog ... Jan 6 20:35:36 haqua postfix/cleanup[86498]: F14503AC9D: message-id=<***> Jan 6 20:35:36 haqua postfix/qmgr[86421]: F14503AC9D: from=<***@kimagurenote.net>, size=1706, nrcpt=1 (queue active) Jan 6 20:35:37 haqua postfix/smtp[86500]: Trusted TLS connection established to gmail-smtp-in.l.google.com[***.***.***.***]:25: TLSv1 with cipher RC4-SHA (128/128 bits) Jan 6 20:35:39 haqua postfix/smtp[86500]: F14503AC9D: to=<***@gmail.com>, relay=gmail-smtp-in.l.google.com[***.***.***.***]:25, delay=3.1, delays=0.15/0.17/1.1/1.7, dsn=2.0.0, status=sent (250 2.0.0 OK 1389051338 sz7si54824159pab.174 - gsmtp) Jan 6 20:35:39 haqua postfix/qmgr[86421]: F14503AC9D: removed
% tail /var/log/maillog ... Jan 6 20:35:42 haqua postfix/smtpd[86504]: connect from mail-***.google.com[***.***.***.***] Jan 6 20:35:43 haqua postfix/smtpd[86504]: Trusted TLS connection established from mail-***.google.com[***.***.***.***]: TLSv1 with cipher RC4-SHA (128/128 bits) Jan 6 20:35:44 haqua postfix/smtpd[86504]: 945993AC9E: client=mail-***.google.com[***.***.***.***] Jan 6 20:35:45 haqua postfix/cleanup[86498]: 945993AC9E: message-id=<***> Jan 6 20:35:45 haqua postfix/qmgr[86421]: 945993AC9E: from=<***@gmail.com>, size=4140, nrcpt=1 (queue active) Jan 6 20:35:45 haqua postfix/local[86506]: 945993AC9E: to=<***@kimagurenote.net>, relay=local, delay=0.76, delays=0.75/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Jan 6 20:35:45 haqua postfix/qmgr[86421]: 945993AC9E: removed Jan 6 20:35:45 haqua postfix/smtpd[86504]: disconnect from mail-***.google.com[***.***.***.***]
main.cf に smtpd_tls_received_header = yes を設定しておくと、メールヘッダでもTLS接続の記録を見られるので、（他のサーバが付けた Received: は基本信頼できないという大前提を踏まえつつ）メールが届くまでに、どこの間は平文で、どこの間は暗号化されたかを知る目安になるかと思われます。
以下に参考例（関係ないヘッダを削除するなど少し手を加えています）。 しかし、サーバ mail-***.google.com に対し、common name が "smtp.gmail.com" の証明書で verified OK となるのは釈然としないなぁ…
Return-Path: <***@gmail.com>
X-Original-To: ***@kimagurenote.net
Delivered-To: ***@kimagurenote.net
Received: by 10.***.***.*** with SMTP id ***;
Wed, 8 Jan 2014 18:09:44 -0800 (PST)
X-Received: by 10.***.***.*** with SMTP id ***;
Wed, 08 Jan 2014 18:09:43 -0800 (PST)
Received: from mail.kimagurenote.net (mail.kimagurenote.net. [***.***.***.***])
by mx.google.com with ESMTPS id ***
for <***@gmail.com>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Wed, 08 Jan 2014 18:09:43 -0800 (PST)
Received-SPF: pass (google.com: domain of ***@kimagurenote.net designates ***.***.***.*** as permitted sender) client-ip=***.***.***.***;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of ***@kimagurenote.net designates ***.***.***.*** as permitted sender) smtp.mail=***@kimagurenote.net
Received: by mail.kimagurenote.net (Postfix, from userid 1001)
id 15B0F3AC9C; Thu, 9 Jan 2014 11:09:41 +0900 (JST)
To: ***@gmail.com
From: Testuser <***@kimagurenote.net>
Subject: testmail
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Date: Thu, 9 Jan 2014 11:09:40 +0900
Message-ID: <***>
（以下本文）
Delivered-To: ***@kimagurenote.net
Received: from mail-***.google.com (mail-***.google.com [***.***.***.***])
(using TLSv1 with cipher RC4-SHA (128/128 bits))
(Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK))
by mail.kimagurenote.net (Postfix) with ESMTPS id ***
for <***@kimagurenote.net>; Thu, 9 Jan 2014 11:09:49 +0900 (JST)
Received: by mail-***.google.com with SMTP id ***
for <***@kimagurenote.net>; Wed, 08 Jan 2014 18:09:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-original-authentication-results:delivered-to:to:from:subject
:mime-version:content-type:date:message-id;
bh=***;
b=***
X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ***@kimagurenote.net designates ***.***.***.*** as permitted sender) smtp.mail=***@kimagurenote.net
X-Received: by 10.***.***.*** with SMTP id ***;
Wed, 08 Jan 2014 18:09:45 -0800 (PST)
To: ***@kimagurenote.net
From: Testuser <***@gmail.com>
Subject: testmail
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Date: Thu, 9 Jan 2014 11:09:40 +0900
Message-ID: <***>
（以下本文）
SSL暗号化・認証に使うファイルがいくつか登場しましたが、拡張子も様々なものが登場し、ちょっと複雑かと思います。
ここでは .key（秘密鍵）, .csr（証明書要求データ）, .crt（X509証明書） などが登場しました。他の参考記事では、.pem（データがBase64で格納されていることを示す拡張子。データ形式を示すもので、中身は問わない。）を使っている所もあるようです。
つまり、データの内容を示す拡張子と、データ形式を示す拡張子が混在しており、中身は同じ物なのに、ある場所では .crt を使い、別の場所では .pem を使っていることがあるのです。慣れないと戸惑うかもしれませんが、どちらが正しいというものでもないので（たぶん）、前後をよく読んで文脈から判断しましょう。
【参考】
Postfix関連（Postfixのぺーじさんによる和訳版）
OpenSSL関連
RapidSSL関連
更新日 : 2016年04月16日 (12046)
CORY's twilight zone > 98備忘録 (tips)[an error occurred while processing this directive] > Postfix TLS認証
