As I Please - 検索結果

certbot on FreeBSD9

なかなかやめられない古いＯＳで、次は証明書（let's encrypt) を使い続けたくて。。。運用には certbot を使うのがデフォルトのようで、ports が使えないことを前提にすれば、git clone で持ってくるのがベスト。ということで、

git clone https://github.com/certbot/certbot

を行ったら、

SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

ということで、gitが tls1.2をしゃべらない！のが問題（古い git clientすぎた）ので、まずはこれをバージョンアップしてみた。ところが、、、直らない。。。見ると gitは裏では curl を使っているようなので、これが tls1.2を使うようにしないといけなかった。ということで、curlも最新版を持ってきて openssl も tls1.2 を使えるバージョンを参照してinstall. でも、今度は　git-remote-https.core　を吐いて何もすすまない。shared ライブラリ参照が違うとかそこらへんだろうから、ということで、libzも入れ直してみたがやはりおかしい。。。コンパイラ環境の問題かもと疑ってみると、そこらへんだったみたい。 curl -> /usr/bin/gcc 利用 git -> /usr/bin/gcc 利用は coreを吐く。ということで環境変数 CC=/usr/local/bin/gcc を設定しコンパイルしなした gitだとちゃんと cloneできた。 libz,libiconv,libintl,libchasetあたりも/usr/local/lib 側をちゃんとリンクしてくれた。いまどきllvm,clangなんでしょうが、、、、、もうちょい生きながらえさせて。 git cloneでファイルをダウンロードできたが、次にhttps://certbot.eff.org/docs/contributing.htmlを参照して、

python3 tools/venv3.py

なのだが、ここでどうも yaml(pyyaml)のところでエラー。これも gccを利用しているが/usr/bin/gcc を見ているケースと/usr/local/bin/gcc を見るケースがあるのが問題のよう。 .cshrc で /usr/local/bin を優先させることで /usr/local/bin/gcc を先に見るようにしたところ、まずはここはクリア。 bash で

source venv3/bin/activate
run_acme_server &
certbot_test certonly --standalone -d test.example.com

と実行してまずはローカルで動くかどうかを試すのだが、run_acme_server のところで落ちる。うまく webserver が起き上がってくれない。

[venv3] root@host:/usr/local/src/certbot # run_acme_server
=> Starting pebble instance deployment...
ELF binary type "0" not known.
=> Tear down the test infrastructure...
=> Test infrastructure stopped and cleaned up.
Traceback (most recent call last):
  File "/usr/local/src/certbot/venv3/bin/run_acme_server", line 11, in 
    load_entry_point('certbot-ci', 'console_scripts', 'run_acme_server')()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 221, in main
    with acme_server as acme_xdist:
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 96, in __enter__
    self.start()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 62, in start
    raise e
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 57, in start
    self._prepare_pebble_server()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 135, in _prepare_pebble_server
    self._launch_process(
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 205, in _launch_process
    process = subprocess.Popen(command, stdout=stdout, stderr=subprocess.STDOUT, cwd=cwd, env=env)
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/usr/local/src/certbot/certbot-ci/certbot_integration_tests/assets/pebble_v2.3.0_linux-amd64'

なんか、certbot が linuxの実行ファイル(linux binary for amd64)を抱えていてこれが freebsdでは動かない、ということのようだ。linux-compat とか入れればいいのかもしれないがそこまでやるかな。。。ということでこの線はあきらめて、、、 certbot は普通に python(2or3)のコードだったことを思い出して、$src/certbot/の中を見ると、setup.pyがあるので、

python3 setup.py build
python3 setup.py install

で、/usr/local/bin/certbot にインストールされた。

certbot certonly --standalone -d test.example.com

でちゃんと証明書が降りてきた。

Tag

certbot on FreeBSD9

なかなかやめられない古いＯＳで、次は証明書（let's encrypt) を使い続けたくて。。。運用には certbot を使うのがデフォルトのようで、ports が使えないことを前提にすれば、git clone で持ってくるのがベスト。ということで、

git clone https://github.com/certbot/certbot

を行ったら、

SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

ということで、gitが tls1.2をしゃべらない！のが問題（古い git clientすぎた）ので、まずはこれをバージョンアップしてみた。ところが、、、直らない。。。見ると gitは裏では curl を使っているようなので、これが tls1.2を使うようにしないといけなかった。ということで、curlも最新版を持ってきて openssl も tls1.2 を使えるバージョンを参照してinstall. でも、今度は　git-remote-https.core　を吐いて何もすすまない。shared ライブラリ参照が違うとかそこらへんだろうから、ということで、libzも入れ直してみたがやはりおかしい。。。コンパイラ環境の問題かもと疑ってみると、そこらへんだったみたい。 curl -> /usr/bin/gcc 利用 git -> /usr/bin/gcc 利用は coreを吐く。ということで環境変数 CC=/usr/local/bin/gcc を設定しコンパイルしなした gitだとちゃんと cloneできた。 libz,libiconv,libintl,libchasetあたりも/usr/local/lib 側をちゃんとリンクしてくれた。いまどきllvm,clangなんでしょうが、、、、、もうちょい生きながらえさせて。 git cloneでファイルをダウンロードできたが、次にhttps://certbot.eff.org/docs/contributing.htmlを参照して、

python3 tools/venv3.py

なのだが、ここでどうも yaml(pyyaml)のところでエラー。これも gccを利用しているが/usr/bin/gcc を見ているケースと/usr/local/bin/gcc を見るケースがあるのが問題のよう。 .cshrc で /usr/local/bin を優先させることで /usr/local/bin/gcc を先に見るようにしたところ、まずはここはクリア。 bash で

source venv3/bin/activate
run_acme_server &
certbot_test certonly --standalone -d test.example.com

と実行してまずはローカルで動くかどうかを試すのだが、run_acme_server のところで落ちる。うまく webserver が起き上がってくれない。

[venv3] root@host:/usr/local/src/certbot # run_acme_server
=> Starting pebble instance deployment...
ELF binary type "0" not known.
=> Tear down the test infrastructure...
=> Test infrastructure stopped and cleaned up.
Traceback (most recent call last):
  File "/usr/local/src/certbot/venv3/bin/run_acme_server", line 11, in 
    load_entry_point('certbot-ci', 'console_scripts', 'run_acme_server')()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 221, in main
    with acme_server as acme_xdist:
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 96, in __enter__
    self.start()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 62, in start
    raise e
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 57, in start
    self._prepare_pebble_server()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 135, in _prepare_pebble_server
    self._launch_process(
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 205, in _launch_process
    process = subprocess.Popen(command, stdout=stdout, stderr=subprocess.STDOUT, cwd=cwd, env=env)
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/usr/local/src/certbot/certbot-ci/certbot_integration_tests/assets/pebble_v2.3.0_linux-amd64'

なんか、certbot が linuxの実行ファイル(linux binary for amd64)を抱えていてこれが freebsdでは動かない、ということのようだ。linux-compat とか入れればいいのかもしれないがそこまでやるかな。。。ということでこの線はあきらめて、、、 certbot は普通に python(2or3)のコードだったことを思い出して、$src/certbot/の中を見ると、setup.pyがあるので、

python3 setup.py build
python3 setup.py install

で、/usr/local/bin/certbot にインストールされた。

certbot certonly --standalone -d test.example.com

でちゃんと証明書が降りてきた。

Tag

sendmail-8.15.2 .on FreeBSD-9

重力波関連の速報が知りたくて、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のファイルを見るとヒントになることが多いのでそれらを考慮して次のようにおこなった。

まず既存の bin,configのバックアップ
必要なpatch をあてる。
sendmail の configの作成
compile
install

と言うことで作業。

まず既存のbin,configのバックアップ

patchをあてる。
configの作成

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

compile
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
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

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

Tag

sendmail-8.15.2 .on FreeBSD-9

重力波関連の速報が知りたくて、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のファイルを見るとヒントになることが多いのでそれらを考慮して次のようにおこなった。

まず既存の bin,configのバックアップ
必要なpatch をあてる。
sendmail の configの作成
compile
install

と言うことで作業。

まず既存のbin,configのバックアップ

patchをあてる。
configの作成

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

compile
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
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

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

タグ「TLS1.2」が付けられているもの

certbot on FreeBSD9

Tag

certbot on FreeBSD9

Tag

sendmail-8.15.2 .on FreeBSD-9

Tag

sendmail-8.15.2 .on FreeBSD-9

Tag