妄想まとめ

研究とかWebセキュとか時事ネタとか。 @kazu1130_h

EC2上のAWS CLIで使われている169.254について

お久しぶりです。ひろたんです。

前々から気になっていたAWS EC2の169.254.169.254について少し遊んでみたのでまとめます。


EC2では、インスタンス内から http://169.254.169.254/ にアクセスすると、そのインスタンスに関する情報が取得できるようになっています。

docs.aws.amazon.com

あまり意識したことはないかもしれませんが、インスタンスにIAMロールを結び付けた状態でAWS CLIを使うと内部的にこの169のURLが叩かれる仕組みになっています。
これはインスタンス内で--debugオプションを使ってAWS CLIを実行するとわかると思います。

[ec2-user@ip-172-31-30-197 ~]$ aws s3 ls --debug
~~~
2018-09-03 11:11:33,898 - MainThread - botocore.vendored.requests.packages.urllib3.connectionpool - INFO - Starting new HTTP connection (1): 169.254.169.254
2018-09-03 11:11:33,899 - MainThread - botocore.vendored.requests.packages.urllib3.connectionpool - DEBUG - "GET /latest/meta-data/iam/security-credentials/ HTTP/1.1" 200 8
2018-09-03 11:11:33,901 - MainThread - botocore.vendored.requests.packages.urllib3.connectionpool - INFO - Starting new HTTP connection (1): 169.254.169.254
2018-09-03 11:11:33,902 - MainThread - botocore.vendored.requests.packages.urllib3.connectionpool - DEBUG - "GET /latest/meta-data/iam/security-credentials/testrole HTTP/1.1" 200 898
2018-09-03 11:11:33,902 - MainThread - botocore.credentials - DEBUG - Found credentials from IAM Role: testrole
2018-09-03 11:11:33,903 - MainThread - botocore.loaders - DEBUG - Loading JSON file: /usr/lib/python2.7/dist-packages/botocore/data/endpoints.json
2018-09-03 11:11:33,919 - MainThread - botocore.session - DEBUG - Loading variable profile from defaults.
~~~

これについては以下のAWS公式ヘルプに書かれていますね。
docs.aws.amazon.com

さて、ここで気になる警告が……。

警告

IAM ロールでインスタンスメタデータを使用するサービスを使用する場合は、サービスで HTTP 呼び出しが行われるときに認証情報を公開しないように注意する必要があります。認証情報を公開できるサービスの種類には、HTTP プロキシ、HTML/CSS 検証サービス、および XML インクルードをサポートする XML プロセッサーが含まれます。

この警告。色々妄想が膨らみそうですね。ブログタイトルも妄想まとめですしね!!


例えばこんなコードが動いていたとします。

GitHub - kazu1130/ssdemo: ScreenShot

これは送られてきたURLに飛んでスクショを撮って保存するだけのプログラムです。

例えばここに http://169.254.169.254/latest/meta-data/iam/security-credentials/ というURLを投げると…… ご想像の通り、credentialが奪えます。
f:id:kazu1130_h:20180903201728p:plain

あとは、盗んだcredentialで(exportコマンドと任意のAWS CLIのコマンドを)走り出すだけです!!!(?)

$ export AWS_ACCESS_KEY_ID=<Access-Key-as-in-Previous-Output>
$ export AWS_SECRET_ACCESS_KEY=<Secret-Access-Key-as-in-Previous-Output>
$ export AWS_SESSION_TOKEN=<Session-Token-as-in-Previous-Output>
$ aws s3 ls


今回のコードでは画像を./data/に保存しているだけなので何のロールも無い可能性がありますが、これが例えばS3にアップロードするようなコードだった場合、credentialが奪えそうな気がしませんか?
(因みにロールが無い場合は、/iam/security-credentials/というパス自体が404になります)


実際、サイトへアクセスして結果を返す機能を利用してcredentialを奪えた例がHackerOneに上がってたりします。
hackerone.com



さて、このような場合どういった対策を取ればよいのでしょうか。


受け取ったプログラム側で対策しても良いのですが、その場合ちゃんと接続先が169.254でないことを確認する必要があります。単に文字列で見るだけだと、例えば悪意のあるドメインを参照させてアクセスさせたり、IPアドレスの10進数表記を使ってアクセスさせたり、色々回避されてしまうからです。
※さっきのサンプルで試したら、ちゃんと http://2852039166/ を解釈してくれました。流石Chrome先生!


実際に組まなければいけなくなった場合、僕だったらおそらくサービスを丸ごとコンテナにぶち込んでiptablesで制限をかけると思います。
外部にアクセスしている機能(今回のならHeadless-Chrome)の詳細が分かっていれば、もしかしたらコードレベルで対処するかもしれませんが、解釈の違い等で死ぬ未来が見えているので出来る限りコードを書かない対処をしたくなりますよね。

上記対策だとコンテナ内からAWS CLIを叩けなくなってしまいますが、コンテナ内外でデータDirを共有しつつコンテナ外でアップロード用のスクリプトを動かすことで、コンテナ内から169につなぐ必要がなくなるため、丸ごとブロックしても正常にAWS CLIを動かすことができます。

具体的には

iptables -I DOCKER-USER -d 169.254.169.254 -j DROP

のようなコマンドを打てばブロックできるはずです。



まぁそもそもLambda等に切り出しちゃうのが一番なのかもしれませんがねw


以上、明日某所で話すネタを先にまとめた記事でした。

VyOSによるOpenVPN環境の構築

顔本には画像付きで出しましたが、最近買ったiPadから自宅Windowsを操作できるようにしました。
わーい


というわけで、備忘録的にその時やったこととかをメモっとく。


構成は以下のような感じ。
f:id:kazu1130_h:20180510222024p:plain


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

qiita.com

CVE-2018-1000006に関して

結構致命的ながらあんまり騒がれてない気がしたので調べてみました。

影響のあるアプリ

  • Windowsで動く(Mac,Linux上で動いてるものは対象外)
  • setAsDefaultProtocolClientを呼び出している
  • 脆弱なバージョンのElectronを使って作られている

の、3点全てを満たすアプリ。

原理

ElectronのsetAsDefaultProtocolClientは、レジストリに以下の文字列を登録する。

 "(setしたElectronアプリのEXEファイルまでのパス)" "%1"

しかし、%1は単純に置換されるので、以下のようなカスタムURIスキームを踏ませればオプションを任意につけられる。

myapp://hoge" --no-sandbox 

そして、gpu-lancher等のような任意のプロセスを動かせるオプションを使ってcmd.exeを呼び出して任意のコードを動かす。

言ってみれば受動型任意コード実行みたいな感じ。

対策

雑記

これを動かすときは"がエンコードされずに渡されなければならないため、ブラウザが限定されます。
Electron内部からだとダメ。Firefoxもダメ。
Chromeは昨日配信のパッチを当てるとダメ。
唯一IEだけは"をエスケープせずにそのまま渡してくれるので優秀(?)。
よって、PoCを動かすときはIE推奨。
IEは他のブラウザと違ってちゃんとリンク先のアドレス(ここで言うhoge" --no-sandbox)まで含めた確認ウィンドウを出すが、実は長さ制限があるため、ひたすらスペースなりでごまかせば許可してくれる気がする。
特にSkypeのリンクがハメやすそう。


あと、あまり指摘されてない気がするけど、setAsDefaultProtocolClientしたプロトコルは明示的にremoveするまで残ります
なので、昔テストで動かしたアプリとかがそのまま残っていると、思わぬ所で発火する可能性があります。(packageしたelectron-api-demosとかはヤバいかも?)
日常使うものならともかく、一回起動させてテストしてそのまま、みたいなアプリがあると、普通に攻撃される可能性が高い。
起動させてからディレクトリを変えたりしてると発火しない(レジストリには起動時のパスが残るので)ものの、再度色々確認したほうが良いかも。
特にHKCU\Software\Classes\以下でURLが指定されてるもの。原理的にはElectron以外でも起こりえるし。

Client-side HTTP parameter pollution

Burpに新しく追加されてたのさっと読んでみた。


portswigger.net


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&amp;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を買うか」とか考えたけど、それ別にSSDWin7インスコと変わらんやんという理性で殴り続けて得た結果なわけで、勝利ってことで。
明日気力があったら参考にしたサイト張りますね。

LINEのBOTを組んでみた

お久しぶりです、ひろたんです。

ようやくLINEがBOTAPIを一般公開してくれたと聞いて、飛びついてきました。


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化出来るとか夢のような仕組みですね。