パブリックコメントの募集期間について
最近某県で話題になったパブリックコメントですが、行政手続法においては意見公募手続と呼ばれ、命令等を定める場合には行わなければならないと定められています。(例外あり)
そして、行う場合、公示の日から起算して三十日以上の期間、募集しなければなりません。
もしこの期間を短縮しなければならない理由があるときは、公示の際にそれを示す必要があります。(短縮して理由を示さないパターンは無いはず)
行政手続法:
https://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=405AC0000000088#J
(意見公募手続)
第三十九条 命令等制定機関は、命令等を定めようとする場合には、当該命令等の案(命令等で定めようとする内容を示すものをいう。以下同じ。)及びこれに関連する資料をあらかじめ公示し、意見(情報を含む。以下同じ。)の提出先及び意見の提出のための期間(以下「意見提出期間」という。)を定めて広く一般の意見を求めなければならない。
2 前項の規定により公示する命令等の案は、具体的かつ明確な内容のものであって、かつ、当該命令等の題名及び当該命令等を定める根拠となる法令の条項が明示されたものでなければならない。
3 第一項の規定により定める意見提出期間は、同項の公示の日から起算して三十日以上でなければならない。
(略)
(意見公募手続の特例)
第四十条 命令等制定機関は、命令等を定めようとする場合において、三十日以上の意見提出期間を定めることができないやむを得ない理由があるときは、前条第三項の規定にかかわらず、三十日を下回る意見提出期間を定めることができる。この場合においては、当該命令等の案の公示の際その理由を明らかにしなければならない。
(略)
ではなぜ某県においては30日に満たない、2週間程度の期間かつ理由を示さないパブコメを行えたのでしょうか。
実は、意見公募手続含め、行政手続法の条文の多くは、地方公共団体には原則適用されません。
そのせいで、パブコメについてルールを定めてない自治体があったり、定めていても各自治体によってどういう形で定めているか(条例?要綱?)、どれくらいの期間実施するかがマチマチだったりします。
今までは「どうせ法をコピペしただけの条例がたくさんあるだけだろ」と思ってたのですが、例の件を受けて割とそうじゃない事に気付き、ほかの都道府県がどうなっているか気になったので、調べがてら表にまとめてみました。
Gist:
https://gist.github.com/kazu1130/f2a6b5f7d01272d554a950a919b530e2
自分の住んでる所はどうなっているか、この機会にぜひ確認してみてください。
BASE PASTAとBASE BREADとAll-in PASTA
なんか料理してる時間があれだなー、ということで完全栄養食を三つ試してみました。
ちなみにツイッターでよく見るCOMPはちょっと味気ないというか、食事って感じがしなかったので試してません。
一人暮らしで時間が無いと嘆いてる方に参考にして頂ければなと。
完全食 BASE PASTA® おためしセット(ポモドーロ/ジェノベーゼ) – BASE FOOD
まずはBASE PASTA。主食の完全栄養食市場を切り開いた切り込み隊長?
パスタなので茹でる手間がかかるが、ソースは温めないでOKというか市販のソースでもOK。
レンジでチンできる容器も売ってるもののぼったくりなのでお勧めしない。
とはいえ百均のパスタ用レンジ容器でやると粉が落ちなくて死ぬ。まずい。結局茹でるのが一番良い。
値段は一食390円で定期なら1割引。カップ麺のほうが安いといえば安いが、栄養価を考えるとやむなし。
そしておそらく血で血を洗うレッドオーシャンになるまで追い込まれないとこれ以上下がらないので、そこは諦めてください。
肝心の味は、、、パスタとして食べると、とても微妙。
穀物系全開で、苦手な人は苦手。
今のところ試したソース類どれでも概ね穀物な味が残る。
唯一台湾まぜそば味だけは誤魔化せてた……というか味が濃すぎてヤバかった。
慣れれば大丈夫という話もあるが、それでも、ある時突然食べたくなくなる可能性がある。
量は適正くらい。腹持ちも良いので朝とかよさそう。
まとめると、一回試して大丈夫な味だったらアリ、くらいの感じ。
完全食 BASE BREAD®️ おためしセット – BASE FOOD
続いてBASE BREAD。主食シリーズその2のパン。
こちらは袋を切ってまるごとレンジでチンするだけというお手軽さ、またパンなので食器を使わないという点も強い。
ただ、パンなのでバターなり塩なりを使いたくなる。結果として食器を使うという説はある。
値段はPASTAと同じ。
ただ、パスタと違って冷凍庫に入れとかなきゃいけないので買いだめに限界があるかも?
味は、PASTAをパンにするとこうなるんだろうなぁ、という味。
麺で穀物系な味を出されるよりも違和感が無いのでこちらの方が良いかもしれない。
味のバリエーションに乏しいかもしれないが、そこはやる気次第でどうにでもなる。
そのまま食べるのは微妙だなぁと色々試した結果、オリーブオイルと塩がベストだった。胡椒を足しても良いかも。
オイルなので皿の上にラップを敷いて使うことをお勧めする。
こちらも、ある日突然食べたくなくなる可能性がある味だなぁという感想。
量はまぁパン二つなので適正~少し多めくらい。
腹持ちはパスタ以上かも。
まとめると、BASE PASTA買うよりこっちを試せ(調理時間的にも味的にも)、という感じ。
www.allinseries.jp
BASE FOODがブルーオーシャンでちゃぷちゃぷ遊んでたら日清という黒船が襲来した、くらいの感じ。
発表当初から大人気で品薄だったが、最近になって買えるようになってきた。初期絞りすぎ問題。
こちらも茹でる手間はあるが、BASEと違って粉を落とす必要が無い代わりにほぐす必要がある。(カップ麺みたいに固めてる)
値段は400円だが5食セットで350円になる。
BASEと大差ないくらいなので、供給側によって値段が決まってる感がある。
はやいところ血で血を洗ってほしい()
味は、パスタとして食べると、とても微妙(2度目)
なんか苦い。うっすらと苦い気がする、くらいのレベルだが気になる。栄養ホールドプレス失敗したか???
完全栄養食の宿命なのかな。
あとジェノベーゼソースが草生えるwwwwwwwww
最後にかけるバジルの分量を間違えてる。半分で良い。全部掛けたらまじで草。
他サイト見ても同じこと言ってるし、なぜこの量にしてしまったのか……。
まぁでもBASE PASTAより違和感がないので、こっちの方が食べ続けられる気がする。(ソースは市販のかけるだけ系の安い奴で十分)
そして、一番伝えたいことだが、こいつはラーメンとして食うのがベスト。
ケトルでお湯を沸かしながら鍋で茹で、出来たらどんぶりに創味シャンタンかウェイパー入れて麺とケトルのお湯を入れて完成。
土日に味玉を仕込んでおいて、それを入れても良い。
流石日清、安藤さんの信念が受け継がれている(??)(まんぷく見てました)
まとめると、麺が食いたきゃこいつをラーメンにしろ、という感じ。
個人的には、手間を惜しむならBASE BREAD、そうでないならラーメンことAll-in PASTAという感じ。
どうでもいいけど今の今までall in one PASTAだと思ってた……。
以上、思い付きで書いた完全栄養食の感想でした。
とっととレッドオーシャンになって価格競争して欲しいのでもっと種類出てきてくれーーーーー!!!!
VyOSによるOpenVPN環境の構築
顔本には画像付きで出しましたが、最近買ったiPadから自宅Windowsを操作できるようにしました。
わーい
というわけで、備忘録的にその時やったこととかをメモっとく。
構成は以下のような感じ。
NICを共有したwindows 10マシン上のVyOS VMに対して、任意の回線からOpenVPNを張ってiPadに10.0.0.2/24のIPを振り、NATして192.168.0.0/24のNWにアクセスさせ、192.168.0.2にいるwindows 10(VyOSをホストしてるwin)に戻している感じ。
なんで一度192.168.0.0/24に出しているかというと、将来的にはVMをホスティングしているWindowsではなく別のPCに対してRDPする予定だから。
それなら受け口のひかり電話ルーターでVPNすれば良いように見えるけど、それだと443ポートを使えず、80/443しか外に出させないWifiを使えなくなってしまう(のと、色々configしたかった)ので、こんな感じ。
あと欲を出してTLSの事前共有鍵も使っている。これが無いとDOSとかオーバーフローとかでいたずらされるらしい?
OpenVPN TLS-Auth とは?
ハマりどころはクライアント(ovpnファイル)とサーバ側の設定の差。
アルゴリズムとハッシュを設定する場合は以下のようになる。
VyOS
set interfaces openvpn vtun0 encryption aes256 set interfaces openvpn vtun0 hash sha512
ovpnファイル
cipher AES-256-CBC auth sha512
またTLS事前共有鍵は以下の通り。
VyOS
set interfaces openvpn vtun0 openvpn-option '--tls-auth /config/auth/ovpn/ta.key 0'
ovpnファイル(winのOVPNの場合)
tls-auth [inline] 1 ... <tls-auth> </tls-auth>
ovpnファイル(iPadのOVPNの場合)
key-direction 1 ... <tls-auth> </tls-auth>
他の、例えば<ca>とかだと[inline]記法を使うとダメなのに対して、winだと<tls-auth>は[inline]記法を使わないとダメ。
また、iPadの場合はkey-direction 1という新パラメータをくっつけなきゃダメ。(winでも有効なのでむしろこっちのほうが良いけど、統一感あるのは[inline]の気がする)
鍵情報だけじゃなくdirectionパラメータも必要なのでこの設定方法になっているみたい。なおiPadでinlineがサポートされてない理由はよくわからない……。(歴史的経緯?)
ファイルを別に用意する場合は素直にファイル名で指定すればいいんだけど、ovpnファイル一つにまとめようとした結果死ぬほどハマった。
エラーメッセージが不親切すぎるねん……。
以下のようなエラーが出たらauthかcryptかtls-authのどれかが間違っている。(winでのテスト結果)
Fri May 11 00:15:31 2018 TCP connection established with [AF_INET]192.168.0.3:443 Fri May 11 00:15:31 2018 TCP_CLIENT link local: (not bound) Fri May 11 00:15:31 2018 TCP_CLIENT link remote: [AF_INET]192.168.0.3:443 Fri May 11 00:15:31 2018 MANAGEMENT: >STATE:1525965331,WAIT,,,,,, Fri May 11 00:15:31 2018 Connection reset, restarting [0] Fri May 11 00:15:31 2018 TCP/UDP: Closing socket
なお一応VyOS上からは/var/log/messageを見ればざっくりとしたログが見える。
grep openvpn /var/log/message
May 10 15:16:25 vyos openvpn-vtun0[6015]: XX.XX.XX.XX:62855 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:62855, sid=4d06b0ed 7c24ca86 May 10 15:16:25 vyos openvpn-vtun0[6015]: XX.XX.XX.XX:62855 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]XX.XX.XX.XX:62855 May 10 15:16:25 vyos openvpn-vtun0[6015]: XX.XX.XX.XX:62855 Fatal TLS error (check_tls_errors_co), restarting May 10 15:16:25 vyos openvpn-vtun0[6015]: XX.XX.XX.XX:62855 SIGUSR1[soft,tls-error] received, client-instance restarting
さて本題。
細かい説明は参考サイトに任せて、VyOSのconfigを貼る。
interfaces { ethernet eth0 { address 192.168.0.3/24 duplex auto hw-id XX:XX:XX:XX:XX:XX smp_affinity auto speed auto } loopback lo { } openvpn vtun0 { encryption aes256 hash sha512 local-port 443 mode server openvpn-option "--push route 192.168.0.0 255.255.255.0 --push dhcp-option DNS 192.168.0.1 --push redirect-gateway def1" openvpn-option "--tls-auth /config/auth/ovpn/ta.key 0" protocol tcp-passive server { client client1 { ip 10.0.0.2 } subnet 10.0.0.0/24 } tls { ca-cert-file /config/auth/ovpn/ca.crt cert-file /config/auth/ovpn/server.crt dh-file /config/auth/ovpn/dh.pem key-file /config/auth/ovpn/server.key } } } nat { source { rule 1 { outbound-interface eth0 source { address 10.0.0.0/24 } translation { address masquerade } } } }
iPadに埋め込んだOpenVPN用のconfigファイル[client.ovpn]はこんな感じ。
割と余計な設定が残っているけど(゚ε゚)キニシナイ!!
client remote vpn.urische.me port 443 proto tcp-client dev tun persist-tun persist-key resolv-retry infinite ping 10 verb 4 mute 10 cipher AES-256-CBC tls-auth [inline] 1 auth SHA512 key-direction 1 <ca> CA証明書 ca.crtの中身 </ca> <cert> クライアント証明書 client.crtの中身 </cert> <key> クライアント証明書の秘密鍵 client.keyの中身 </key> <tls-auth> TLS事前共有鍵 ta.keyの中身 </tls-auth>
VyOSの設定は、下のようなコマンドで設定。
configure set interfaces openvpn vtun0 encryption 'aes256' set interfaces openvpn vtun0 hash 'sha512' set interfaces openvpn vtun0 local-port '443' set interfaces openvpn vtun0 mode 'server' set interfaces openvpn vtun0 openvpn-option '--push route 192.168.0.0 255.255.255.0 --push dhcp-option DNS 192.168.0.1 --push redirect-gateway def1' set interfaces openvpn vtun0 openvpn-option '--tls-auth /config/auth/ovpn/ta.key 0' set interfaces openvpn vtun0 protocol 'tcp-passive' set interfaces openvpn vtun0 server client client1 ip '10.0.0.2' set interfaces openvpn vtun0 server subnet '10.0.0.0/24' set interfaces openvpn vtun0 tls ca-cert-file '/config/auth/ovpn/ca.crt' set interfaces openvpn vtun0 tls cert-file '/config/auth/ovpn/server.crt' set interfaces openvpn vtun0 tls dh-file '/config/auth/ovpn/dh.pem' set interfaces openvpn vtun0 tls key-file '/config/auth/ovpn/server.key' set nat source rule 1 outbound-interface 'eth0' set nat source rule 1 source address '10.0.0.0/24' set nat source rule 1 translation address 'masquerade'
OpenVPN関連個所のみ抜粋。
上のset interfaceでOpenVPNのvtun0に関する設定を行い、下のnatでNATの設定をしている。
もっと細かい、OpenVPNの準備の仕方とかeth0へのIP割り当てとかは参考サイトを参照。
なお、証明書関連のデータはCentOSで既に作っていたのでそれを流用している。
作り方はこちらを参照。
VPNサーバー構築(OpenVPN) - CentOSで自宅サーバー構築
余談ながら、超絶便利なことに以下のコマンドを実行すると何と現在のconfigをコマンドに落としてくれる。
/opt/vyatta/sbin/vyatta-config-gen-sets.pl /config/config.boot
参考にしたサイト:
qiita.com
Client-side HTTP parameter pollution
Burpに新しく追加されてたのさっと読んでみた。
pollution=汚染 という意味らしい。
HTTPパラメータ汚染……。うーん、、、想像つかん
AppsecEU 2009のこの資料に詳しくまとまってるらしい。
https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
ざっくり言うと、ユーザ入力を受け取ってパラメータに吐いてる箇所に、パラメータを追加して意味を変えちゃうこと?
うちだとURLインジェクションの一部として報告することになるかな。
例えば
<form action="?mode=edit&id=<?php print h($_GET["id"]); ?>" method="POST">
みたいなフォームを吐くPHPがあったとして、ここに
?id=2%26mode%3Ddelete
みたいなパラメータをつけてアクセスさせれば、
<form action="?mode=edit&id=2&mode=delete" method="POST">
になって、編集のつもりでsubmitしたのにデータが消える、みたいな罠ページが作れると。
PHPは後についたパラメータを見るのでmode=editが消される。
しかも例えばintval($_GET["id"]) でDBから何かを引っ張ってきてたりすると、正しくデータを読めちゃうしで、意外と刺さる気がする。
AppSECの資料だとクライアント側だけじゃなく、サーバ側で起こす例(backendへのhttpアクセスがある時に等)とかWAFのバイパス、Rewrite時の挙動を狙った例とかにも言及されてる。この辺はCTFでたまに見る奴や。
なんとなくPHPにおけるparam=hoge -> param[]=hogeに近い何かを感じた。
……とはいえ、なんか名前のわりにぱっとしない。(※個人の感想です)
RFなんちゃらとかCSVExcelなんちゃらとかと同じ香りが……。(※個人の感想です)
Flashだともうちょっと面白くなるかもしれない?
数日したら忘れてそうなので備忘録として。
bootとの戦い
先週水曜辺りからPCが目に見えて重くなり、ちらっと回復不能セクタの文字がよぎったのを無視して使っていたら突然スタートアップ修復からの激重起動。
流石にヤバイと感じてSSDに換装するものの、浮気心から同時にUEFIBootにしようと手を出して焼け野原へ突撃。
黒い画面に_の点滅恐怖症になるくらいにらめっこした後に、今日どうにかこうにかSSDからの起動まで落ち着いたというお話でしたとさ。
さてさて、もう手当たり次第に色々やりすぎて何やったか覚えてないけど一応覚書。
まずここを見ながら修復ディスク作成。
「Windows PE」とは何か - PCと解
結局ディスクに焼いたけどUSBに焼くのがベストっぽい。
ついでにPuppyLinuxをUSBへ。
Gparted/Grub4DoSはめちゃめちゃ役に立った。
しかしPBR直す時にバイナリエディタの使い勝手が死んでてキレそうになった。
KNOPPIXJPなんで死んでしまったん……
そして作ったディスクを使ってこの辺のコマンドをこねこね
bcdboot
bcdsect
bcdedit
diskpart
でも相変わらず______
そこでふとUUID重複に気付く。ついでにMBR->/bootmgrでのエラーっぽいと悟る。
元ディスク抜いてpuppyのgrub経由で起動したら数日振りのwindowsスタート画面!!!
コピー元ディスク指したままでもいいとこ(winload.exeのエラー)までいけたから錯覚してたが、そらあかんか。
というわけで元ディスク繋いでgpartでpartのUUIDを振りなおして再起動。
起動出来ない。なんでや工藤
でも_点滅から BOOTMGR IS MISSINGだったり winload.exeが見つかりませんだったりになった。エラーメッセージがあるの素敵。
まぁでもよく分からんのでとりあえずGrub4dosをSSDに入れて、元HDDもUSBの外す。
そして再び修復ディスク。一回目はcmdで/fixbootとかを打ったけどダメ。
再起動したら自動修復が出来ます的なメッセージが。成り行きに任せたら一人で起動出来るようになった!!!!
そして恐る恐る元HDDを繋げて再起動。ちゃんと認識してSSDの速度でbootされる。
そして今に至る。
/fixmbrその他色々頑張ったのに結局grubに投げたのは負けた感あるけど、クソ忙しい時期だしまぁ仕方ないね!
日曜深夜に100回くらい「こいつを窓から投げ捨てて新しいPCを買うか」とか考えたけど、それ別にSSDにWin7再インスコと変わらんやんという理性で殴り続けて得た結果なわけで、勝利ってことで。
明日気力があったら参考にしたサイト張りますね。
LINEのBOTを組んでみた
お久しぶりです、ひろたんです。
ようやくLINEがBOT用APIを一般公開してくれたと聞いて、飛びついてきました。
LINE Developers - BOT API - Overview
先着1万人らしいですよ!!はよはよ!!
ただこいつ、中々に曲者で……。
Botに対して発言とかのアクションがあったときに、あらかじめ登録しておいたcallback用URLを叩きにきてくれる機能があるのですが、HTTPSじゃないとダメな上、Let'sEncryptの証明書だと叩きに来てくれないんですよね。
なので、こんなスクリプトをherokuにおいて、自前のサーバにバイパスさせて遊んでました。
<?php function heroku_getallheaders(){ $headers = ''; foreach ($_SERVER as $name => $value) { if (substr($name, 0, 5) == 'HTTP_'){ $headers[strtoupper(str_replace(' ', '-', ucwords(str_replace('_', ' ', substr($name, 5)))))] = $value; } } return $headers; } $headers = heroku_getallheaders(); if(isset($headers["X-LINE-CHANNELSIGNATURE"])){ $json_string = file_get_contents('php://input'); $url = "https://urische.me/hogehoge"; $curl = curl_init($url); $options = array( CURLOPT_HTTPHEADER => array( 'Content-type: application/json', 'X-LINE-ChannelSignature: '.$headers["X-LINE-CHANNELSIGNATURE"] ), CURLOPT_POST => true,//POST CURLOPT_POSTFIELDS => $json_string, CURLOPT_SSL_VERIFYPEER => false ); curl_setopt_array($curl, $options); $result = curl_exec($curl); exit(); } else { print "making now...."; }
herokuだとgetallheaders()が使えなかったので、PHP: getallheaders - Manualにあった代替関数を定義して使ってます。
これで何処でも受け取れるようになるので、urische.meでこんなスクリプトを動かしてAPIを叩いてます。
肝心の中身は単に発言された内容をsay:なんちゃら とオウム返しするだけです。
<?php $headers = getallheaders(); if(isset($headers["X-LINE-ChannelSignature"])){ $json_string = file_get_contents('php://input'); if(base64_decode($headers["X-LINE-ChannelSignature"]) === hash_hmac("sha256",$json_string,$LINE_SECRET,true)){ botmain(json_decode($json_string)); } } function botmain($json){ global $LINE_SECRET,$LINE_CHANNEL,$LINE_MID; $results = $json->result; $ret = array(); $sendheaders = array( 'Content-Type: application/json; charset=UTF-8', 'X-Line-ChannelID: '.$LINE_CHANNEL, 'X-Line-ChannelSecret: '.$LINE_SECRET, 'X-Line-Trusted-User-With-ACL: '.$LINE_MID ); for($i=0;$i<count($results);++$i){ $resContent = array( "contentType"=>1, "toType"=>1, "text"=>"say:".$results[$i]->content->text ); $resp = array( 'to' => array($results[$i]->content->from), 'toChannel' => 1383378250, # Fixed value 'eventType' => '138311608800106203', # Fixed value 'content' => $resContent, ); $url = "https://trialbot-api.line.me/v1/events"; $curl = curl_init($url); $options = array( CURLOPT_HTTPHEADER => $sendheaders, CURLOPT_POST => true,//POST CURLOPT_POSTFIELDS => json_encode($resp), CURLOPT_SSL_VERIFYPEER => false, CURLOPT_RETURNTRANSFER => true ); curl_setopt_array($curl, $options); $result = curl_exec($curl); curl_close($curl); } }
Trialということで機能は少ないですが、自分用に色々するには便利そうですね!
ところで巷で公開されてるサンプルの大半が署名検証をはしょってるんですよね。(要出典)
そのままコピペしてそのまま動かしている人が沢山居るだろうな……と思うと何とも言えない気持ちになりますね。
PHPでX-LINE-ChannelSignatureを検証するコード、以下に改めて張っておきます。
<?php base64_decode($headers["X-LINE-ChannelSignature"]) === hash_hmac("sha256",$json_string,$LINE_SECRET,true)
ではでは、そのうち何処かで。
CentOS6.xでLet'sEncryptするお話
お久しぶりです、ひろたんです。
Let'sEncryptのPublicβ前日まではその事を覚えていたのですが、12/3に家に帰るとLet'sEncryptという概念を忘れる病に罹ってしまい、今日までEncryptすることが出来ませんでした。
ですが昨日、特効薬である祝日+年末休暇と繋げた5連有休を使ってようやく完治しました。
そこで今日はLe'sEncryptしたお話をします。
まずPython2.7系の実行環境を取ってきます。
最初、何も考えず野良リポジトリ突っ込んでpython2.7に切り上げたのですが、yumが死んだ上にtrushを使っている関係でrmまで死んで酷い目にあったので、
Redhat / CentOS 6.x users need python 2.7という記事にあった便利なSCLとかいうのを突っ込んでその上で実行する方針にしました。
yum install centos-release-SCL yum install python27 python27-python-devel python27-python-setuptools python27-python-tools python27-python-virtualenv scl enable python27 bash
因みに、一回でもpython2.6環境でletsencrypt-autoコマンドを走らせていると、.local/share/letsencrypt以下にその状態を保持して、python2.7に上げたのに何度やっても2.6のエラーが出る現象にぶち当たるので気をつけてください。
あと、そのままでやったら僕の環境ではSSL周りのWarningが出ました。
Updating letsencrypt and virtual environment dependencies...../root/.local/share/letsencrypt/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning. InsecurePlatformWarning
Security: Verified HTTPS with SSL/TLSを読めって言われたので、
言われたとおりに読んで以下のコマンドを叩きました。
wget "https://raw.github.com/pypa/pip/master/contrib/get-pip.py" python get-pip.py pip install pyopenssl ndg-httpsclient pyasn1
ついでに実行前にhttpdを止めておくと捗ります。
なんでも ACMEというLet'sEncryptを支えるプロトコルのために必要だとか。
証明書発行対象FQDNと実行しているサーバのFQDNがマッチしているか、トークン的なものを使って確認してるらしいです。
service httpd stop
あとはいつものようにgit cloneしてcdしてそれっぽいものを動かすだけです。何も引数を与えずにletsencrypt-autoを叩けば対話形式で実行されますが、証明書失効までの期間が短く、自動更新できるようコマンド一発でいけたほうが色々便利という情報を某社の凄い人が顔本上で言ってたので、今回はその実験もかねてコマンド一発方式でやりました。
git clone "https://github.com/letsencrypt/letsencrypt" cd letsencrypt ./letsencrypt-auto --debug certonly --standalone -d 対象のFQDN -m 自分のメアド --agree-tos --renew-by-default
あとは
/etc/letsencrypt/live/対象のFQDN/fullchain.pem
を公開鍵として、
/etc/letsencrypt/live/対象のFQDN/privkey.pem
を秘密鍵として、それぞれApacheに設定すればOKです。
SSLCertificateFile /etc/letsencrypt/live/対象のFQDN/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/対象のFQDN/privkey.pem
/etc/letsencrypt/archive/対象のFQDN/にも入ってますが、liveの方は更新されたものが自動で反映される(最新の物へのシンボリックリンク)ようになっているため、こちらのほうが色々捗ります。
無料で、しかもこんだけの手間でHTTPS化出来るとか夢のような仕組みですね。