「sendmail クライアント証明書」と一致するもの

sendmail-8.15.2 .on FreeBSD-9 - As I Please_202009

kava (2020年5月18日 00:27)

重力波関連の速報が知りたくて、GCN Circularsのメールを受信しているけど、NASAの シスアドからメールが。

Subject: TLSv1.1-related mail bounces with NASA/GSFC

Hello,

I am a system administrator with the Astrophysics Science Division at NASA/Goddard Space Flight Center.

Due to a directive from the US Department of Homeland Security, I have made a change today to our mail server "capella2.gsfc.nasa.gov" (the mail server for the Gamma-ray Coordinates Network, https://gcn.gsfc.nasa.gov/ ) such that it now blocks TLSv1 and TLSv1.1.

Our logs show entries of the form:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: STARTTLS=client: 11833:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:714:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: ruleset=tls_server, arg1=SOFTWARE, relay=, reject=403 4.7.0 TLS handshake failed.

I am not sure what changes might be needed on your side, but I at least wanted to alert you (because otherwise you or your users might have a "why is this suddenly failing" feeling!). I hope this is helpful.

Regards,

David

P.S. In terms of changes needed, you might need to upgrade your mail server software (sendmail, postfix, Exim, etc) to one that can "speak" TLSv1.2 or newer. Your site doesn't need to require TLSv1.2 as a minimum, as we have had to do, but it needs to be an option. Alternatively, you can let us know of a different mail address on your end to use.

と。sendmail のやりとりで TLS1.2じゃないから上げてね、というリクエスト。システムの自動応答かと思ったらどうもそうでもないような。

"US Department of Homeland Security"ってなんだ？と思ったら国土安全保障省 ？ひぇひぇ。こういうところが勧告するですね、アメリカは。
DNSのMXは primary 10,secondary 20にしていたので、通常は primary のメールサーバに来ていたが、このNASAのメールが急に secondary にメールが届くようになったので何事だろうと思っていたらこういうことだったのか。 実はprimary は TLS1.0,1.1は喋るが TLS1.2は対応していないlibssl.soをリンクしてるsendmail で動いていた。secondary はちゃんと TLS1.2を喋る libssl.soだったのでこちらに流れてきていたもののようだ。 openssl はちゃんと入れていたつもりが、sendmail はOS附属の古い libssl.so をリンクしていた。 ということで、古いOSに最新のsendmail + TLS1.2対応の ものを再インストールする必要が。 postfix,eximとかに変えることも一瞬考えるけど、milter系のものやMLソフトの整備を考えると手が出ない。 FreeBSDは、patchなどについては portsのファイルを見るとヒントになることが多いのでそれらを考慮して次のようにおこなった。
  1. まず既存の bin,configのバックアップ
  2. 必要なpatch をあてる。
  3. sendmail の configの作成
  4. compile
  5. install
と言うことで作業。
  1. まず既存のbin,configのバックアップ
    2. sendmail だけではなくて、いくつかのバイナリ・設定ファイルが作られるので、それを調べて見る。 sendmail-8.15.2.tar.gz を展開して srcのトップディレクトリで 'sh ./Build' を実行すると、 "$src/obj.`uname`.`uname -r`.`uname -p'にバイナリ別のディレクトリができる。 具体的には、
    obj.FreeBSD.9.3-RELEASE-p49.amd64
    の下に、
    editmap libsmdb mail.local makemap rmap smrsh
    libsm lbismuitl mailstats praliases sendmail vacation
    が出来た（12ディレクトリ）。
    これらが後にインストールされると思われるので、おのおのバックアップ。

    /usr/local/bin/rmail
    /usr/local/bin/mailstats
    /usr/local/bin/vacation

    /usr/local/sbin/editmap
    /usr/local/sbin/makemap
    /usr/local/sbin/praliases
    /usr/local/sbin/sendmail

    /usr/lcoal/libexec/smrsh
    /usr/local/libexec/mail.local

    libが３つ(libsmdb,libsm,libsmutil)あるがこれらはコンパイル時にstaticにリンクされるようなのでとりあえずこのまま放っておいて良いみたい。
    src/libmilter があるがこれはBuildしても自動では作成されない。sendmail/milter.c があり、sendmailをコンパイルするとｋには milter.o がリンクされているのでたぶんこれは sendmailを作成時には不要のよう。3rdパーティのプログラムを使う（かもしれない）ときに libmilter.a,libmilter.so とかでリンクするためにあるようだ。(see $src/libmilter/README)
    これは明示的に 'cd libmilter; sh ./Build; sh ./Build install' で良さそう。

    config系は

    /etc/mail/
    /usr/local/share/sendmail/
    /etc/rc.sendmail

    あたりをバックアップ。
  2. patchをあてる。
    3. ports の mail/sendmail/files/ 以下に patch-xxx がある。これらを当てればいいはず、、だが、ports用のマクロ設定（%%CC%%とかに置き換え等）がありちょっとためらう。特にこのパッチを当てなくても warningが少しでるがcompileはうまくいっているようなので、今回は当てなかった。
  3. configの作成
    4. $src/INSTALL にあるように、 $src/devtools/Site/site.config.m4 を作成する。 site.config.m4.sample があるが、これはほぼ当てにならない。portsの mail/sendmail/files/ の中に site.config.m4の機能別のファイルがあるのでこれらをconcatinate して作るのが正しいかと。このディレクトリにある、site.config.m4に、ipv6,tls,sasl2,milter を今回は追加した。 
    dnl
dnl 0) use site.config.m4
dnl
define(`confEBINDIR',`/usr/local/libexec')
define(`confMANROOT',`/usr/local/man/cat')
define(`confMANROOTMAN',`/usr/local/man/man')
define(`confMBINDIR',`/usr/local/sbin')
define(`confSBINDIR',`/usr/local/sbin')
define(`confUBINDIR',`/usr/local/bin')
define(`confNO_STATISTICS_INSTALL',`True')
define(`confHFDIR', `/usr/local/share/sendmail')
APPENDDEF(`conf_sendmail_ENVDEF', `-DTCPWRAPPERS')
APPENDDEF(`conf_sendmail_LIBS', `-lwrap')"
dnl
dnl
dnl 1) use site.config.m4.ipv6
dnl
APPENDDEF(`conf_sendmail_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_libmilter_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_libsm_ENVDEF', `-DNETINET6')
dnl
dnl 2) use site.config.m4.tls
dnl
APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS -D_FFR_TLS_EC')
APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
dnl
dnl 3) use site.config.m4.sasl2
dnl
dnl APPENDDEF(`conf_sendmail_ENVDEF', `-I%%LOCALBASE%%/include')
dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
dnl APPENDDEF(`confLIBDIRS', `-L%%LOCALBASE%%/lib')
dnl APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
APPENDDEF(`conf_sendmail_ENVDEF', `-I/usr/local/include')
APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
dnl
dnl 4) use site.config.m4.milter
dnl
APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
dnl
  4. compile
    5. $src にて、'sh ./Build'
  5. install
    6. $srcにて、'sh ./Build install'
元々 8.15.2 用で使っていた sendmail.cf はそのまま使えた。 これで TLS1.2も話す sendmail になったか。

ps.1
某日、STARTTLSを使ってちゃんとTLSで接続してくるメールを見てみたらいろいろあったので メモ。
クライアント証明書つきのTLS通信（但し認証(verify)はもちろんしていない)
  • NASA
  • Google (Gmailの転送)
  • SwarovskiのML
  • T-PointのML
  • オレオレCA証明書で発行したクライアント証明書を使っているMTA
ただの TLS通信。転送路は TLSのようだが特に認証無し。
  • shopify の広告DM
  • SBIのDairy mail
  • Land's Endの広告DM
  • 東洋経済のML
  • トクバイのML
  • キタムラのML
  • ホンダのML
  • DMMからのメール
  • JustsystemからのML
  • AmazonからのDM
  • GU(ユニクロ)からのML
  • みずほ銀行からのDM
  • OpenHouseからのDM
  • GMOからのML
  • EXPANSYSからのML
  • MoneyforwardからのML
  • JTBからのML
  • Generate DesginからのML
  • Wealthnavi からのML
  • QNAP からのML
  • Nature RemoからのML
  • furusat taxからのML
  • IPCamのメール通知クライアント(sasl認証)
単に forged なだけか、おかしな通信
  • security.criminalip.com
  • ninja.census.shodan.io
    • わざわざ SSL3.0,TLS1.0,TLS1.1,TLS1.2と繋がるか調べにやってきてる。
  • bezeqint.net
今後は sendmailもクライアント接続してくる側も証明書呈示するようになっていくんですかね。 とりあえず、うちも STARTTLSで接続したときに let's encryptあたりの証明書を呈示するようにしておいてみるか？

ps.2
TLS1.2対応になったことを、NASAのシスアドに連絡してみたところ、返答が。

I am glad to hear it is working for you once again!

Yes, I can see the moment in our logs when it got fixed:

Here is the last line of failure and the first line of success:

May 11 xx:xx:xx capella2 sendmail[15971]: ruleset=tls_server, arg1=SOFTWARE, relay=aaa.bbb.ccc, reject=403 4.7.0 TLS handshake failed.

May 11 yy:yy:yy capella2 sendmail[15971]: STARTTLS=client, relay=aaa.bbb.ccc., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128

Thanks,

David


わざわざ丁寧にありがとう。

sendmail-8.15.2 .on FreeBSD-9 - As I Please

kava (2020年5月18日 00:27)

重力波関連の速報が知りたくて、GCN Circularsのメールを受信しているけど、NASAの シスアドからメールが。

Subject: TLSv1.1-related mail bounces with NASA/GSFC

Hello,

I am a system administrator with the Astrophysics Science Division at NASA/Goddard Space Flight Center.

Due to a directive from the US Department of Homeland Security, I have made a change today to our mail server "capella2.gsfc.nasa.gov" (the mail server for the Gamma-ray Coordinates Network, https://gcn.gsfc.nasa.gov/ ) such that it now blocks TLSv1 and TLSv1.1.

Our logs show entries of the form:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: STARTTLS=client: 11833:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:714:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: ruleset=tls_server, arg1=SOFTWARE, relay=, reject=403 4.7.0 TLS handshake failed.

I am not sure what changes might be needed on your side, but I at least wanted to alert you (because otherwise you or your users might have a "why is this suddenly failing" feeling!). I hope this is helpful.

Regards,

David

P.S. In terms of changes needed, you might need to upgrade your mail server software (sendmail, postfix, Exim, etc) to one that can "speak" TLSv1.2 or newer. Your site doesn't need to require TLSv1.2 as a minimum, as we have had to do, but it needs to be an option. Alternatively, you can let us know of a different mail address on your end to use.

と。sendmail のやりとりで TLS1.2じゃないから上げてね、というリクエスト。システムの自動応答かと思ったらどうもそうでもないような。

"US Department of Homeland Security"ってなんだ？と思ったら国土安全保障省 ？ひぇひぇ。こういうところが勧告するですね、アメリカは。
DNSのMXは primary 10,secondary 20にしていたので、通常は primary のメールサーバに来ていたが、このNASAのメールが急に secondary にメールが届くようになったので何事だろうと思っていたらこういうことだったのか。 実はprimary は TLS1.0,1.1は喋るが TLS1.2は対応していないlibssl.soをリンクしてるsendmail で動いていた。secondary はちゃんと TLS1.2を喋る libssl.soだったのでこちらに流れてきていたもののようだ。 openssl はちゃんと入れていたつもりが、sendmail はOS附属の古い libssl.so をリンクしていた。 ということで、古いOSに最新のsendmail + TLS1.2対応の ものを再インストールする必要が。 postfix,eximとかに変えることも一瞬考えるけど、milter系のものやMLソフトの整備を考えると手が出ない。 FreeBSDは、patchなどについては portsのファイルを見るとヒントになることが多いのでそれらを考慮して次のようにおこなった。
  1. まず既存の bin,configのバックアップ
  2. 必要なpatch をあてる。
  3. sendmail の configの作成
  4. compile
  5. install
と言うことで作業。
  1. まず既存のbin,configのバックアップ
    2. sendmail だけではなくて、いくつかのバイナリ・設定ファイルが作られるので、それを調べて見る。 sendmail-8.15.2.tar.gz を展開して srcのトップディレクトリで 'sh ./Build' を実行すると、 "$src/obj.`uname`.`uname -r`.`uname -p'にバイナリ別のディレクトリができる。 具体的には、
    obj.FreeBSD.9.3-RELEASE-p49.amd64
    の下に、
    editmap libsmdb mail.local makemap rmap smrsh
    libsm lbismuitl mailstats praliases sendmail vacation
    が出来た（12ディレクトリ）。
    これらが後にインストールされると思われるので、おのおのバックアップ。

    /usr/local/bin/rmail
    /usr/local/bin/mailstats
    /usr/local/bin/vacation

    /usr/local/sbin/editmap
    /usr/local/sbin/makemap
    /usr/local/sbin/praliases
    /usr/local/sbin/sendmail

    /usr/lcoal/libexec/smrsh
    /usr/local/libexec/mail.local

    libが３つ(libsmdb,libsm,libsmutil)あるがこれらはコンパイル時にstaticにリンクされるようなのでとりあえずこのまま放っておいて良いみたい。
    src/libmilter があるがこれはBuildしても自動では作成されない。sendmail/milter.c があり、sendmailをコンパイルするとｋには milter.o がリンクされているのでたぶんこれは sendmailを作成時には不要のよう。3rdパーティのプログラムを使う（かもしれない）ときに libmilter.a,libmilter.so とかでリンクするためにあるようだ。(see $src/libmilter/README)
    これは明示的に 'cd libmilter; sh ./Build; sh ./Build install' で良さそう。

    config系は

    /etc/mail/
    /usr/local/share/sendmail/
    /etc/rc.sendmail

    あたりをバックアップ。
  2. patchをあてる。
    3. ports の mail/sendmail/files/ 以下に patch-xxx がある。これらを当てればいいはず、、だが、ports用のマクロ設定（%%CC%%とかに置き換え等）がありちょっとためらう。特にこのパッチを当てなくても warningが少しでるがcompileはうまくいっているようなので、今回は当てなかった。
  3. configの作成
    4. $src/INSTALL にあるように、 $src/devtools/Site/site.config.m4 を作成する。 site.config.m4.sample があるが、これはほぼ当てにならない。portsの mail/sendmail/files/ の中に site.config.m4の機能別のファイルがあるのでこれらをconcatinate して作るのが正しいかと。このディレクトリにある、site.config.m4に、ipv6,tls,sasl2,milter を今回は追加した。 
    dnl
dnl 0) use site.config.m4
dnl
define(`confEBINDIR',`/usr/local/libexec')
define(`confMANROOT',`/usr/local/man/cat')
define(`confMANROOTMAN',`/usr/local/man/man')
define(`confMBINDIR',`/usr/local/sbin')
define(`confSBINDIR',`/usr/local/sbin')
define(`confUBINDIR',`/usr/local/bin')
define(`confNO_STATISTICS_INSTALL',`True')
define(`confHFDIR', `/usr/local/share/sendmail')
APPENDDEF(`conf_sendmail_ENVDEF', `-DTCPWRAPPERS')
APPENDDEF(`conf_sendmail_LIBS', `-lwrap')"
dnl
dnl
dnl 1) use site.config.m4.ipv6
dnl
APPENDDEF(`conf_sendmail_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_libmilter_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_libsm_ENVDEF', `-DNETINET6')
dnl
dnl 2) use site.config.m4.tls
dnl
APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS -D_FFR_TLS_EC')
APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
dnl
dnl 3) use site.config.m4.sasl2
dnl
dnl APPENDDEF(`conf_sendmail_ENVDEF', `-I%%LOCALBASE%%/include')
dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
dnl APPENDDEF(`confLIBDIRS', `-L%%LOCALBASE%%/lib')
dnl APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
APPENDDEF(`conf_sendmail_ENVDEF', `-I/usr/local/include')
APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
dnl
dnl 4) use site.config.m4.milter
dnl
APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
dnl
  4. compile
    5. $src にて、'sh ./Build'
  5. install
    6. $srcにて、'sh ./Build install'
元々 8.15.2 用で使っていた sendmail.cf はそのまま使えた。 これで TLS1.2も話す sendmail になったか。

ps.1
某日、STARTTLSを使ってちゃんとTLSで接続してくるメールを見てみたらいろいろあったので メモ。
クライアント証明書つきのTLS通信（但し認証(verify)はもちろんしていない)
  • NASA
  • Google (Gmailの転送)
  • SwarovskiのML
  • T-PointのML
  • オレオレCA証明書で発行したクライアント証明書を使っているMTA
ただの TLS通信。転送路は TLSのようだが特に認証無し。
  • shopify の広告DM
  • SBIのDairy mail
  • Land's Endの広告DM
  • 東洋経済のML
  • トクバイのML
  • キタムラのML
  • ホンダのML
  • DMMからのメール
  • JustsystemからのML
  • AmazonからのDM
  • GU(ユニクロ)からのML
  • みずほ銀行からのDM
  • OpenHouseからのDM
  • GMOからのML
  • EXPANSYSからのML
  • MoneyforwardからのML
  • JTBからのML
  • Generate DesginからのML
  • Wealthnavi からのML
  • QNAP からのML
  • Nature RemoからのML
  • furusat taxからのML
  • IPCamのメール通知クライアント(sasl認証)
単に forged なだけか、おかしな通信
  • security.criminalip.com
  • ninja.census.shodan.io
    • わざわざ SSL3.0,TLS1.0,TLS1.1,TLS1.2と繋がるか調べにやってきてる。
  • bezeqint.net
今後は sendmailもクライアント接続してくる側も証明書呈示するようになっていくんですかね。 とりあえず、うちも STARTTLSで接続したときに let's encryptあたりの証明書を呈示するようにしておいてみるか？

ps.2
TLS1.2対応になったことを、NASAのシスアドに連絡してみたところ、返答が。

I am glad to hear it is working for you once again!

Yes, I can see the moment in our logs when it got fixed:

Here is the last line of failure and the first line of success:

May 11 xx:xx:xx capella2 sendmail[15971]: ruleset=tls_server, arg1=SOFTWARE, relay=aaa.bbb.ccc, reject=403 4.7.0 TLS handshake failed.

May 11 yy:yy:yy capella2 sendmail[15971]: STARTTLS=client, relay=aaa.bbb.ccc., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128

Thanks,

David


わざわざ丁寧にありがとう。

iOS13での(imap)サーバー証明書の作り直し - As I Please_202009

kava (2019年9月26日 17:33)
iOS13にアップデートしたところ、iPhoneのMailソフトで 自前の imap(dovecot)サーバにつながらなくなってしまった。 メッセージは「サーバーの識別情報を検証できません」。 全くノーケアだったけど原因は、「iOS 13 および macOS 10.15 における信頼済み証明書の要件」の中にある、
  • TLS サーバ証明書は、証明書の SAN (Subject Alternative Name) 拡張領域にサーバの DNS 名を記述する必要がある。証明書の CommonName の DNS 名は今後は信頼されなくなります。
  • TLS サーバ証明書には ExtendedKeyUsage (EKU) 拡張領域を必ず含め、ここに id-kp-serverAuth OID を指定する必要がある。
  • TLS サーバ証明書の有効期間は 825 日以下である (証明書の NotBefore フィールドと NotAfter フィールドで明記)。
あたりか？CAの証明書とsignについてはすでにsha256で行っていたので問題ないはず。cnをもう見ない、というのはうかつにも知らなかった。 SANへの対応について参照したのは、このページ。行った変更は、openssl.cnf において
  • default_days を 820(日)に
  • [req] セクションに"req_extensions = v3_req" を追加。
  • [ usr_cert ] セクションに "authorityKeyIdentifier=keyid,issuer:always","subjectAltName= @alt_names","extendedKeyUsage = critical,timeStamping,serverAuth,clientAuth,codeSigning,codeSigning,emailProtection" を追加。
  • [ v3_req ]セクションに、"subjectAltName =@alt_names","extendedKeyUsage = serverAuth,clientAuth,codeSigning,emailProtection" を追加。
  • [alt_names]セクションを新たに新設、ここに 'DNS.1= foo.baa.com","DNS.2 = *.foo.baa.com" などと記述。
これで、新たにサーバ証明書を作成し、dovecotの証明書として利用する。 とりあえずこれでエラーは出なくなり、以前通り接続できるようになった。 EKUのOIDとかも勝手に引っ張ってきてくれる。 httpd、sendmail のサーバー証明書、クライアント証明書も同じようにするかな・・・
続きを読む: iOS13での(imap)サーバー証明書の作り直し

iOS13での(imap)サーバー証明書の作り直し - As I Please

kava (2019年9月26日 17:33)
iOS13にアップデートしたところ、iPhoneのMailソフトで 自前の imap(dovecot)サーバにつながらなくなってしまった。 メッセージは「サーバーの識別情報を検証できません」。 全くノーケアだったけど原因は、「iOS 13 および macOS 10.15 における信頼済み証明書の要件」の中にある、
  • TLS サーバ証明書は、証明書の SAN (Subject Alternative Name) 拡張領域にサーバの DNS 名を記述する必要がある。証明書の CommonName の DNS 名は今後は信頼されなくなります。
  • TLS サーバ証明書には ExtendedKeyUsage (EKU) 拡張領域を必ず含め、ここに id-kp-serverAuth OID を指定する必要がある。
  • TLS サーバ証明書の有効期間は 825 日以下である (証明書の NotBefore フィールドと NotAfter フィールドで明記)。
あたりか？CAの証明書とsignについてはすでにsha256で行っていたので問題ないはず。cnをもう見ない、というのはうかつにも知らなかった。 SANへの対応について参照したのは、このページ。行った変更は、openssl.cnf において
  • default_days を 820(日)に
  • [req] セクションに"req_extensions = v3_req" を追加。
  • [ usr_cert ] セクションに "authorityKeyIdentifier=keyid,issuer:always","subjectAltName= @alt_names","extendedKeyUsage = critical,timeStamping,serverAuth,clientAuth,codeSigning,codeSigning,emailProtection" を追加。
  • [ v3_req ]セクションに、"subjectAltName =@alt_names","extendedKeyUsage = serverAuth,clientAuth,codeSigning,emailProtection" を追加。
  • [alt_names]セクションを新たに新設、ここに 'DNS.1= foo.baa.com","DNS.2 = *.foo.baa.com" などと記述。
これで、新たにサーバ証明書を作成し、dovecotの証明書として利用する。 とりあえずこれでエラーは出なくなり、以前通り接続できるようになった。 EKUのOIDとかも勝手に引っ張ってきてくれる。 httpd、sendmail のサーバー証明書、クライアント証明書も同じようにするかな・・・
続きを読む: iOS13での(imap)サーバー証明書の作り直し

sendmail での クライアント認証 - As I Please_202009

kava (2009年4月 3日 13:08)

独自ＣＡでの署名済みの正しいクライアント証明書を持ったユーザ（マシン）からだけ、smtpsの STARTTLSを用いてメールのリレーを行わせたいので、いろいろ試行錯誤していたが、3週間ほどはまってしまった。

注意点は、
  • クライアントはどっから来るからわからないので、安全のために、
    FEATURE(`accept_unresolvable_domains')
    をつける。
  • MAILERの設定は、mcファイルの一番最後に書く。どうも mcファイルの位置によって、sendmail.cfで適用されるルールの順番が変化してしまう。順番としては、FEATURE,MAILER_DEFINITIONS,DAEMON_OPTIONS,などなど。そして一番最後に MAILERを記述する。

sendmail での クライアント認証 - As I Please_sptest

kava (2009年4月 3日 13:08)

独自ＣＡでの署名済みの正しいクライアント証明書を持ったユーザ（マシン）からだけ、smtpsの STARTTLSを用いてメールのリレーを行わせたいので、いろいろ試行錯誤していたが、3週間ほどはまってしまった。

注意点は、
  • クライアントはどっから来るからわからないので、安全のために、
    FEATURE(`accept_unresolvable_domains')
    をつける。
  • MAILERの設定は、mcファイルの一番最後に書く。どうも mcファイルの位置によって、sendmail.cfで適用されるルールの順番が変化してしまう。順番としては、FEATURE,MAILER_DEFINITIONS,DAEMON_OPTIONS,などなど。そして一番最後に MAILERを記述する。

sendmail での クライアント認証 - As I Please

kava (2009年4月 3日 13:08)

独自ＣＡでの署名済みの正しいクライアント証明書を持ったユーザ（マシン）からだけ、smtpsの STARTTLSを用いてメールのリレーを行わせたいので、いろいろ試行錯誤していたが、3週間ほどはまってしまった。

注意点は、
  • クライアントはどっから来るからわからないので、安全のために、
    FEATURE(`accept_unresolvable_domains')
    をつける。
  • MAILERの設定は、mcファイルの一番最後に書く。どうも mcファイルの位置によって、sendmail.cfで適用されるルールの順番が変化してしまう。順番としては、FEATURE,MAILER_DEFINITIONS,DAEMON_OPTIONS,などなど。そして一番最後に MAILERを記述する。
1

検索