2014-11-09
この間の日記の続き。 コメントに貴重な情報をいただいたので、少し調べてみた。まだうまくいっていないので経過報告といったところだが、ひとつ変なことに気がついたので、記しておく。 検証のために書いたコードは Gist に置いた。まず、imap.mail.me.com の証明書を検証するために必要な、「Verisign Class 3 Public Primary Certification Authority - G3」と「VeriSign Class 3 Public Primary Certification Authority - G5」の証明書だけを入れたファイルを使い、検証をさせてみた。$Net::SSLeay::trace = 3 にしても、検証過程が読みとれなかったので、コールバックを使って経過を確認してみた。 すると、最初に呼ばれた際の Issuer (正確には Issuer
IO::Socket::SSL で証明書の検証をする - あまつぶ＠はてなダイアリー
久々に更新。 Twitter でぼちぼち書いてたけど、まとめておこうかなと。 IO::Socket::SSL には、接続先の証明書を検証する機能があるが、検索してもあまりその使い方が出てこない。いつかのバージョンで、「SSL_verify_mode」を設定せずに使おうとすると警告が出るようになったため、「とりあえず SSL_VERIFY_NONE に設定したら動くよ」っていう情報があちこち見つかるのだが、「SSL_VERIFY_PEER」を使うのが推奨されているにもかかわらず、そうした場合に証明書をどうやって検証するかっていう情報がなぜかあまり出てこない。 証明書の検証をするためには、SSL_ca_file あるいは SSL_ca_path で CA の証明書のファイルが入っている場所を指定すればよい(ドキュメント)ということなのだが、どこにどういう形式で保存されているかは OS によって
NginxでのOCSP Stapling対応設定
意外にハマったのでメモ。 OCSPとは OCSP（Online Certificate Status Protocol）とは、SSL/TLS暗号化通信の初期フェーズにおいて証明書の失効を確認するための手順。 従来は署名所失効リスト(CRL)が利用されていたが、CRLはリストが肥大化しダウンロードに非常に時間がかかるようになってきたため、単一レコードの取得で済むOCSPが、現在では証明書の失効を確認する方法として一般的になった。 OCSP Staplingとは 通常は以下の図のように、証明書をダウンロードしたクライアントがOCSP Responderにサーバ証明書の失効を確認する。 OCSP Staplingに対応すると、以下の図のように証明書の失効確認をサーバ側で処理することができる。 また、OCSPレスポンスは一定の間はサーバにキャッシュされ、都度OCSP Responderに問い合わせ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirecting to SSL using Nginx
