暗号通貨eXPerience Chain（XPChain、XPC）、Discord上で使えるウォレットbotやInsightも公開されて、ますます楽しくなってきた。

私は技術系オタクだから、暗号のコードとか見るとちょっと（かなり）わくわくする。
XPC自体の活用アイデアとかはあまり出てこないけど...まあ、まだテストネットなので慌てない慌てない。

ということでテストネットだからこそということで、いろいろ弄って遊び倒す。
ある意味これもXPCの活用（？）かもしれない。

RPCコマンドを使ったrainもどきとかトランザクションの生成→署名→送信あたりはやったので、いよいよウォレットの外（Bitcoin系のライブラリとInsight）でいろいろやっていきたい。
と、その前に、アドレスや秘密鍵の関係を把握しておくことに。

※以下、XPC固有というわけではなく、Bitcoin 0.17～系にほぼ共通のはず（そもそもソースがBitcoinからフォークしてるので、ブロック構造とか使ってる暗号技術とかほほ同じのため）

※あくまで私が弄るために集めた最小限の知識やコードしか書いてないので、必ず他のサイトも参考にすること

※以下、バイト列はhex表記（ef0102dc...等）とする

異世界に転生して...じゃなくて。

※没りそうになったので当初予定の9割削減でお送りしております。

• Symantecがやらかしたせいで証明書更新が必要になった
• その時の私の環境
  さくらインターネット（以下さくら）で以下の契約をしていた
  • レンタルサーバ：mcrn.jpに割り当て
  • VPS：cvmu.jpに割り当て
  • SSL証明書：上記2つそれぞれにラピッドSSLで用意
    mcrnは手動プラン、cvmuはレンタルサーバ用自動プラン
• さくらではSSL証明書は2回更新が必要だった
  • 1回目の時は無事更新成功
  • 2回目の前に、諸事情でcvmu.jpをレンタルサーバからVPSに移行
    その際に、Let'sEncryptに失敗し、面倒なので期限の残ってたSSL証明書を引っこ抜いて流用
• 2回目の通知が来たとき、それをすっかり忘れてcvmuの分を更新手続きし、放置
  
  • 当然レンタルサーバではなくなっているので自動で進むはずがない
  • 手続き後、すぐにレンタルサーバ側から認証ファイルをVPSに移動していれば問題なかったはず
• 先日「まだ更新されてないよ、このままだとChrome70でエラーが」的なメールが来て気付く
  • 慌てて認証ファイルを移動するも当然時間切れ（変化なし）

で、ダメ元でさくらのサポートに連絡したら、認証局に連絡して新しい認証ファイル発行してもらい、無事更新完了した。

どう考えてもこっちの落ち度なのに対応してくれたし、かなりスムーズだった。
もしかして結構こういうユーザーいるのかな...？

最近Twitterで済ませることが多くなってきて、ほぼ休止状態のブログ。

今回のも小ネタだしTwitterで済ませようかな...とも思ったけど、わざわざ有料SSL契約してるのに使わない（使わせない？）のはもったいないのでブログに。

Symatecの証明書がGoogleに無効化された件で、一度更新したはずの証明書、実はまだダメだったためもう一度更新してってメールがさくらから届いた。

...うん、知ってた。Impressの記事で読んで「あ～、これもう一回くるな～」って思ってた。

まあ、面倒がってても仕方ないのでさくっと更新。この記事を書いてる時点でmcrn.jpは既に更新済み、cvmu.jpはRSプランなのでさくら側の作業待ち。

今回の更新でルートCAがGeoTrustからDigiCertに変わった。見てる側には何の影響もないけど。

VPSをいろいろ弄ってて、lynxを入れてみたくなったので2.8.8をDLして./configure && make。

しかーし！SSL使えないし日本語が変なローマ字になるしもうダメダメダメぽ。

ということでなんとかしようと調べるも、ほとんど情報が見つからない。

で、一応見つけたのがこれ

Lynxが化けまくる。その２。ncurseswで一旦解決編。 - night garden > reboot

./configure --with-screen=ncursesw \
--enable-widec --enable-cjk \
--enable-japanese-utf8 --with-ssl \
--enable-cgi-links --enable-change-exec \
--enable-charset-choice --enable-default-colors \
--enable-exec-links --enable-exec-scripts \
--enable-externs --enable-gzip-help \
--enable-htmlized-cfg --enable-internal-links \
--enable-local-docs --enable-progressbar \
--enable-scrollbar --enable-underlines \
--enable-vertrace --with-bzlib --with-zlib
make

セキュリティ的にゆるいというのは肌で感じるオプション群。でもこれはいけそう。

当ブログをMovable Typeによる自前ホスティングに移行する前の、「さくらのブログ」URL（sblo.mcrn.jp）からの転送を、2016年10月23日をもって終了します。

以降は、sblo.mcrn.jpサブドメイン自体が廃止となり、アクセス不能になります。

ブックマーク等に登録されている場合は、転送後URLの「mcrn.jp/blog/～」をブックマークし直してください。

このサイト（mcrn.jp）を常時SSL化＆HSTS化してもう10ヶ月。

さくらからSSL証明書更新のお知らせが届いた（2ヶ月前と1ヶ月前に届く）。

ところが、手順通りやっても更新できない。

何度やっても「新規取得」しか選べない。

もしかして更新できる時期になってない！？でも90日切ったら可能って書いてあるんだけど...。

しかし、その原因は意外なところにあった。

順番に入れていく。まだローカルでテストしてる段階なので、VPSに入れる時にはオプションとか変更するかも。

以下、特に断りがないかぎりバージョンは本記事公開時点の最新を選択。

CVMUプロジェクト自体、安定性より最新を重視してるので、さすがにdevelopment・canary・nightlyやβ版、RC版は使わないけど、正式リリースであれば出たばっかりのバージョンでもどんどん使っていくつもり。

※コマンドの先頭が「#」になってるものはroot権限が必要という意味で、実際はsudoでやってる場合もある。

なんてことはない、ただRubyでHTTPSなWebサーバにアクセスしてGETでデータをとってくるというだけの話なんだけど...

問題発生

まず思いついたのがこのコード。

require 'net/https'
Net::HTTP.get(URI.parse("https://mcrn.jp/ret.cgi"))

しかし、次のようなエラーが返ってきてしまう。

OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
from C:/Ruby21x/lib/ruby/2.1.0/net/http.rb:923:in `connect'

原因究明

もしかしてSNIに対応していない？と思ったけど違った（4年以上前に対応してる）。

さらに調べて、以下の記事をヒントに証明書の場所を調べてみてびっくり。

エラー：OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed - komiyakの通り道

require 'openssl'
p OpenSSL::X509::DEFAULT_CERT_FILE

"C:/Users/Justin/Projects/knap-build/var/knapsack/software/x64-windows/openssl/1.0.1l/ssl/cert.pem"
=> "C:/Users/Justin/Projects/knap-build/var/knapsack/software/x64-windows/openssl/1.0.1l/ssl/cert.pem"

Justin！？誰？？？（※1）

ブログ移行に伴い、sblo.mcrn.jpをさくらのブログから外してリダイレクト用に設定しなおしたので、ついでに証明書を取ってSSL化。

これでmcrn.jp配下のドメインは全部SSL化できたので、.htaccessのHSTS設定にに「includeSubdomains」と「preload」を追加（※1）して、HSTS Preload Submissionに申請。

反映までにしばらくかかるけど、preloadじゃないHSTSは既に効いてる状態なので、.htaccessの強制HTTPSリダイレクトと組み合わせて完全HTTPSが実現。

こんなタイトルだけど、中身としては「こうあるべき」というより「私はこれがいいと思う」みたいな感じ。

（以下、特に区別しない限りは「PC」にフルWindowsタブレット・ファブレットも含むものとする。要するにPCで動くブラウザが動けばPC）

1.URL構造

まず、URL構造をどうするかだけど、主に考えられるのは

1. サブドメイン（https://sp.mcrn.jp/等）
2. サブフォルダ（https://mcrn.jp/sp/等）
3. そのまま（PC・スマホで同じURL）

の3つ（※1）。

個人的にはc＞b＞a。このサイトでもcの「そのまま」を採用

サブドメインだとサーバによってはSSLが別証明書になっちゃうし（さくらSNIだとマルチドメイン不可）、セキュリティ的にも同じ（same origin）と見なされなかったりする。

調べてみても、サブドメインは「運営組織・ポリシーが大きく違う」「テーマ・イメージが別物」など、とにかく「意味的（semantic）に分けたい」時に使う感じ。

「スマホ向け・PC向け・ケータイ（フィーチャフォン、ガラケー）向け」というのは多くの場合「形式的（syntactic）」な分類だから、その場合はサブドメインの利点は少ないかも。