web-dev-qa-db-ja.com

exim4クライアント証明書のチェックは常に無効です

私のeximサーバーは、接続が確立されたときにクライアント証明書を要求するように構成されています。 ACLを（rcpt段階で）設定して、ヘッダー応答をログに記録または追加します。証明書チェックの結果の：

warn
   encrypted = *
   ! verify = certificate
   #condition = ${if def:tls_in_peerdn {yes}{no}}   # -> newer versions of exim use $tls_in_peerdn!
   condition = ${if def:tls_peerdn {yes}{no}} 
   add_header = X-TLS-Client-Certificate: invalid (${tls_peerdn})
   log_message = Invalid TLS client certificate presented (${tls_peerdn}).

warn
   encrypted = *
   ! verify = certificate
   condition = ${if def:tls_peerdn {no}{yes}} 
  log_message = No TLS client certificate presented.

warn
   verify = certificate  
   add_header = X-TLS-Client-Certificate: valid
   condition = false

残念ながら、私が目にするメッセージが有効であるとチェックされることはありません。ただし、証明書がないかどうかのチェックは機能します。

設定しました

tls_try_verify_hosts = *

したがって、チェックが行われ、（Debianを使用して、標準構成に含まれています）トラストアンカーが構成され、アクセス可能になります。

tls_verify_certificates = /etc/ssl/certs/ca-certificates.crt

でテストしています...

openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -verify 4 -connect mailserver.dom.tld:25 -starttls smtp -cert /etc/ssl/letsencrypt/fullchain.pem -key /etc/ssl/letsencrypt/privkey.pem

...サーバーが使用するのと同じキーを使用してサーバーからそれ自体に、正しい順序で中間証明書を含めると、有効なチェック結果が得られません。

何が足りないのですか？

debianconfigurationcertificateeximtls
1
Adrian Zaugg

パラメータ-CAfileの値は、Let'sEncryptのchain.pemと-certcert.pemの値である必要があります。

openssl s_client -CAfile /etc/ssl/letsencrypt/chain.pem -verify 4 \
        -connect mailserver.dom.tld:25 -starttls smtp \
        -cert /etc/ssl/letsencrypt/cert.pem \
        -key /etc/ssl/letsencrypt/privkey.pem

このように、証明書はサーバーによって検証されます。

0
Adrian Zaugg

サーバーがデフォルト構成を使用している場合は、snakeoil自己署名証明書を使用している必要があります。これは、発信接続と着信接続でTLS接続を確立するのに十分で許容されます。ただし、検証は失敗します。検証に合格するには、信頼できる機関からの証明書を使用する必要があります。

ログインの代わりに使用できる証明書をクライアントに提供していますか？ユーザー証明書を提供されたユーザー以外に、クライアント証明書は頻繁に失敗すると思います。多くのサーバーは自己署名証明書を使用しているか、検証の失敗を引き起こす他の問題を抱えています。

tls_verify_hostsまたはtls_try_verify_hostsを設定しない限り、Eximはクライアント証明書を要求しません。証明書については、Eximドキュメントの 暗号化されたSMTP接続 セクションで詳しく説明されています。

多くの組織は、STMPを使用するためにDNSを正しく構成するのに問題があります。 DKIMは特に厄介で、私が遭遇するほとんどの署名者は検証に失敗します。多くのサイトがサーバーを正しい有効な証明書で構成していることを私はほとんど期待していません。

最近TLSv1.0以降への接続を制限した後、多くのサーバーへのSTARTTLSのアナウンスを停止する必要がありました。私はまだ、クライアントのTLS証明書を検証しようとはしていません。私がそうするならば、それはせいぜい彼らのスパムスコアに数えられるでしょう。 tls_peerdnログセレクターを有効にして、検証に合格できるサイトがあるかどうかを調査できます。

SMTP over TLSは成長していますが、標準からはほど遠いです。それを使用しているサイトは、他の手段で信頼されているサイトです。

更新：ログを確認しましたが、これまでのところ、検証に合格した送信者は2人だけです。ほとんどのクライアントは検証しませんでした。

証明書を検証してみました：

  • OpenSSLはopenssl.client.netとして接続しますが、これはrDNS検証を渡してはなりません。
  • Fullchain.certは、デフォルトのトラストストアの証明書までさかのぼりません。チェーン証明書はトラストストアの証明書によって署名されているため、これは問題ありません。
  • Opensslはクライアント証明書を送信しようとさえしないようです。おそらくトラストチェーンが原因です。 fullchain.pemファイルに3番目の証明書を追加した場合に機能する可能性があります。
  • サーバーのDNがリストされていますが、open_sslが証明書を送信しようとしたことを示すものはありません。

私が使用したテストコマンドは次のとおりです。

echo quit | openssl s_client -cert fullchain.pem -key privkey.pem \
   -starttls smtp -connect mail.systemajik.com:587 -debug 2>&1 | less
1
BillThor