2015-07-20

Apache2.2系で中間証明書ファイルを指定するのはSSLCertificateChainFile？SSLCACertificateFile？

Apache SSL証明書

Apache2.2系で、SSL サーバ証明書を設置する際に、中間証明書ファイルを指定するディレクティブがSSLCertificateChainFileか、SSLCACertificateFileか、分からなくなってしまったのでメモ。

結論から言うと、SSLCertificateChainFileディレクティブを使うのが正しい。けど、どっち使ってもちゃんとSSLの設定は出来る。

mod_sslの公式ドキュメント（http://httpd.apache.org/docs/2.2/mod/mod_ssl.html）でDescriptionを見ると、

SSLCertificateChainFileディレクティブ：File of PEM-encoded Server CA Certificates SSLCACertificateFileディレクティブ：File of concatenated PEM-encoded CA Certificates for Client Auth

ということなので、同じ「中間証明書を指定する」ディレクティブでも、SSLCertificateChainFileは「SSL サーバ証明書」の中間証明書、SSLCACertificateFileは「SSLクライアント証明書」の中間証明書を指定するディレクティブな模様。

はーすっきり。

でもSSLCertificateChainFileディレクティブを使うのは、「Apache＋mod_ssl」（Apacheにmod_sslモジュールを追加してSSLを使う）のケースだと正解！なんだけど、「Apache＋Apache-SSL」（ApacheにApache-SSLのパッチを当ててSSLを使う）のケースだと、逆にSSLCACertificateFileディレクティブを使うのが正解っぽい。

Apache-SSLってなんですか・・・2009年のリリースが最後だし、もうほぼ使われてないと思っていいのかな・・・。

2015-07-11

SSL証明書をSHA-2に変更するときの案内ページまとめ

SSL証明書

SHA-1のSSL証明書を発行できる期間もあと半年を切り、SSL Pulseの統計情報で見るSSL/TLS (2015年6月版) によると、割合としては既にSHA-1が40%、SHA-2が60%と、SHA-2の方が多くなってきた模様。

非対応になる端末も把握し、さあいよいよSHA-2に変更するぞー！というときに、さてエンドユーザにどう告知したものか・・・と迷うところも多そうなので、参考になりそうな各社のサイトをまとめてみた。

丁寧に説明しているところもあれば、さらっと流しているところもあり、各社さまざま。

しかし上のリストの中にも1つだけあるけど、案内ページをHTTPSでしか見られないのはよくないと思うのですよ。「ガラケーで開いたら見られない！なんで！」って人が、理由を書いてあるページに辿りつけないって、誰のための案内ページなのかと・・・。

2015-06-03

イオンシネマ、リニューアル前のドメインをドロップキャッチされるの巻

Whois ドメイン

イオンシネマ（http://www.aeoncinema.com/）のトップページに、こんなお知らせが出てた。

【重要なお知らせ（ご注意）】当社HPへアクセスされる場合、旧ドメインはご利用にならないようご注意ください。

どうやら2013年7月にワーナーマイカルシネマズがイオンシネマに統合された後、旧ドメイン（warnermycal.com）を手放したら、まんまと業者にドロップキャッチされて、業者が「あなたのコンピュータにウイルスが検出されました」系の詐欺サイトを開設。詐欺サイトへ「ワーナーマイカルのサイトを見ようとしたエンドユーザ」がアクセスして、何かしらの被害が出ている模様。

ちなみに旧ドメイン（warnermycal.com）にアクセスすると、リダイレクト地獄の末にこんな感じになるので、開かないことを強くお勧めします。

Internet Archive Wayback Machineで見る限り、2013年7月にサイトをクローズした後も、1年以上は新ドメイン（www.aeoncinema.com）へ302 Moved Temporarily（＝一時的な移動）でリダイレクトをかけていた模様。旧ドメインの有効期限から推察するに、サイトクローズから1年半以上経った2015年3月頃に旧ドメインを手放したら、4月にドロップキャッチされたものと思われる。

クローズ直後に手放した訳じゃないみたいだし、一応は配慮してたんだね。

ただ2001年ごろに取得したドメインみたいなので、更新料も年々高くなって1年で1万円ちょっと・・・手放したくなる気持ちも分からなくもないけど、結局エンドユーザから「サイトにアクセスしたら、変なページが表示された！」とクレームが来て、トップページにお知らせ出して、といった対応をすることを考えたら、あと何年かはドメイン持ったままの方が安かったんじゃないの？と思う。リダイレクトのログを見てれば、手放す直前に旧ドメインへどれくらいアクセス来てたのか分かるだろうし。

あと、リダイレクトするときのステータスコードを、なぜ301 Moved Permanently（＝恒久的な移動）にしなかったのか！302じゃなくて301にしてれば、ブラウザ側がリダイレクトをキャッシュするので、2回目以降は旧ドメインにアクセスしようとした時点で、最初から新ドメインに行ってたはずで、そうすればエンドユーザが旧ドメインをブックマークしててもまだましだったと思うのに。

しかもちょっと面白いのが、旧ドメインのWhois情報を見ると、「Registrar: DROPCATCH.COM 462 LLC」とある。わっかりやすい名前だな！ドロップキャッチしてるのは、一般人じゃなくて、レジストラなのか！（レジストラ＝お名前.comみたいに、レジストリからドメインを卸してもらって一般人やリセラーに売ってる業者）

Re: ドロップ・キャッチ・システム構築に関する問い合わせ：IT's my business：オルタナティブ・ブログを読んで初めて知ったんだけど、再度売りに出されたドメインをレジストリから確実に買うために存在する、ドロップキャッチ専門のレジストラっていうのが居るんだねー。

最後に、イオンシネマ・・・URLにカンマ入ってる・・・一番大事なところ間違えてるよ！

今後、当社HPへアクセスされる場合は、必ず(www,.aeoncinema.com/)をご利用ください。

2015-05-13

ドメインで_（アンダーバー）使おうとしたらbad owner name (check-names)になった

BIND DNS ドメイン

「hoge_fuga.infra.xyz」っていうサブドメインが作りたくて、自前のBINDでinfra.xyz.zoneに

hoge_fuga       IN      A       153.121.58.159

っていうレコードを追加して、再起動前に

named-checkzone infra.xyz infra.xyz.zone

でゾーンファイルのチェックしたら、

/var/named/chroot/var/named/infra.xyz.zone:22: hoge_fuga.infra.xyz: bad owner name (check-names)

って出た。

どうやらリソースレコードで_（アンダーバー）を使うと、named-checkzoneしたときにこういうエラーが出るらしい。（named.confで設定するcheck-namesのデフォルト値がfailになったBIND9.3.1以降で発生する模様）

解決方法は？

アンダーバー使わない　←こっちがあるべき姿
どうしても使いたい場合はnamed.confの中で、

zone "infra.xyz" {
        type master;
        file "infra.xyz.zone";
};

を、

zone "infra.xyz" {
        type master;
        file "infra.xyz.zone";
        check-names ignore;
};

にして、念のため

named-checkconf

も叩いて、named.confに間違いがないか確認する。

named.confにcheck-namesの行を足しても、named-checkzoneすると相変わらず「bad owner name (check-names)」っていうメッセージは出るんだけど、それでもnamed restartするとちゃんとhoge_fuga.infra.xyzが引けるようになってる。

もしbad owner name (check-names)出てるけどいいや！と、check-namesの行を足さずにBIND再起動を強行すると、「ゾーン情報にアンダーバー使っているという問題がある（とみなされる）」ため、そのゾーン全体が無効になってしまい、BINDが起動しなくなります。

# /etc/init.d/named restart
named を停止中: . [ OK ]
named を起動中:
Error in named configuration:
infra.xyz.zone:22: hoge_fuga.infra.xyz: bad owner name (check-names)
zone infra.xyz/IN: loading from master file infra.xyz.zone failed: bad owner name (check-names)
zone infra.xyz/IN: not loaded due to errors.
_default/infra.xyz/IN: bad owner name (check-names)

こんな感じです。これでもかっていうくらいbad owner name (check-names)出てます。BIND起動しないので、普通にinfra.xyz.zoneに書いてある全部のリソースレコードが引けなくなります。ぎゃー。

ドメインってアンダーバーダメなのね。知らなかった。確かにお名前.comで買えるか試したらちゃんとはねられたわ・・・。

によると、RFC952で定義されている「ホスト名に使える文字」にはアンダーバーが入っていなくて、

1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.).

でもRFC1033で定義されている「ドメイン名に使える文字」には、アンダーバーが入っているんだね。

Because of other protocol restrictions, only the following characters are recommended for use in a host name (besides the dot separator): "A-Z", "a-z", "0-9", dash and underscore

その辺の矛盾から、昔のサイトとかWindowsのActive Directoryだと普通にアンダーバー使ってたり、BIND9.3.1でcheck-namesのデフォルト値が変更になったり、今でもignoreにすれば使えたりするのかなー。

まあハイフン使えよ、という話だと思うので、取りあえず私は「アンダーバー使わない」で行こー。

あ、でもこれみたいにアスタリスク使ってると、アンダーバー入りでも普通に引けるのね。

2015-05-04

wとかlastlogを叩いても、WinSCPでログインしたユーザがNever Logged Inなのはなんで？

Linux SSH syslog

このユーザって今も使われてるのかなー？を確認したくて、wとかlastlogを叩くと、過去絶対にログインしてたはずのユーザで「一度もログインしていません」とか「Never Logged In」と出ることがあって、なんぞこれ？と思ってたので調べてみた。

結論から言うと、SCPやSFTPでログインしてもwやlastlogにログイン履歴は残らない。これは仕様。

私もこの辺の質問者とまったく同じ気持ちでした・・・。

回答欄にも書いてあるけど、wやlastやlastlogがログイン情報のソースとして参照しているのは、/var/run/utmpや/var/log/wtmpや/var/log/lastlog。

んで、sshdはSCPやSFTPでログインした情報を、/var/run/utmpや/var/log/wtmpや/var/log/lastlogに渡さない。だからSCPでログインしてるユーザが「Never Logged In」になる。

sshd_configの設定でどうにかならんかなーと思ったけど、どうにもならなさそう。

という訳で、SCPやSFTPでログインした履歴が見たかったら、/var/log/secure見るのが正解かな、と思う。勿論、必要な情報がちゃんと出るように、事前にsshd_configでSyslogFacilityをAUTHPRIV、LogLevelをVERBOSE（デフォルトはINFO）にしておいて。

2015-03-03

ChromeでCT（Certificate Transparency）非対応のSSL EV証明書は警告表示

SSL証明書

少し前から、ChromeでHTTPSのページを開いたときに、「○○により確認済みですが、公開監査記録がありません」っていうメッセージが出るようになってて、何それ？と気になっていた。

どうやら、使用されているSSL証明書がCertificate Transparency（以下CT）に対応していないと、このメッセージが出る模様。でもTwitterやらFacebookやらの証明書すら非対応ってどういうこっちゃ？と思ったら、各社まだCT対応の証明書の販売が間に合っていない様子。

各認証局のCT対応状況（2015年3月1日時点）

シマンテック　→「対応済み」のリリース見つけられず。恐らくCT未対応
シマンテックグループではCTに準拠するために、EV SSL証明書にProof情報を追加する対応を2014年（予定）より順次提供することを計画しています。 http://www.symantec.com/ja/jp/page.jsp?id=ssl-certificate-transparency
サイバートラスト　→CT未対応。2015年3月中旬から対応予定
2015 年 3 月中旬に CT に対応したサーバー証明書の提供を開始する予定です。 https://www.cybertrust.ne.jp/ssl/sureserver/ct.html
digicert　→CT対応済み。
Digicert は本年、Google ともに CT（Certificate Transparency：透かし入り証明書）実現の準備に取り組み、CTをサポートする最初の CA（認証局）として、Digicert CT プラットフォームを準備しました。 http://www.digicert.ne.jp/topics/CertificateTransparency.html
Trend Micro SSL　→CT対応済み。
Trend Micro SSL では、2014 年 12 月 22 日のシステム改修により、CT への対応を開始します。システム改修後は、新規に発行されるすべての EV 証明書に対し、CT Log から SCT が発行されるようになります。 http://esupport.trendmicro.com/solution/ja-JP/1106400.aspx?cm_re=Sup-_-tmssl-_-news_05
グローバルサイン　→「対応済み」のリリース見つけられず。恐らくCT未対応
GlobalSignでは、2014年末までにEVの証明書についてCTへの対応を完了する予定です。 https://jp.globalsign.com/blog/2014/certificate_transparency.html
Rapid SSL　→「対応済み」のリリース見つけられず。恐らくCT未対応

非対応のEV証明書はChromeでグリーンバーが表示されなくなる

ChromeにはCTの検証機能が導入されているので、今までも証明書の詳細を見れば「○○により確認済みですが、公開監査記録がありません」というメッセージが表示されていた。とはいえぱっと見じゃ何もわからないので影響はなかった。

でも2015年2月にリリースされたChrome 41（ベータ版）以降は、警告度合いがより厳しくなっているようで、

2015 年 1 月 1 日以降に発行した
CT非対応の
EV証明書

という3つの条件が揃うと、折角EV証明書なのにグリーンバーが表示されず、OVやDVと同じ表示になってしまうとのこと。

今は上記のような限定された条件だけど、SHA-1→SHA-2のときみたいに、順次警告度合いが厳しくなっていくとしたら、そのうちOVやDVも「CT対応でないと鍵マークが出ない」みたいになっていくのでは・・・と予想。

恐らくは「グリーンバーが出るから、一目でフィッシングサイトと見分けがつく！」というメリットのために、高いお金出してシマンテックのEV証明書を買ってるんだろうに、SHA-1だしCT非対応だしで、グリーンバーどころか三角の警告マークが出ているみずほダイレクトとか本当に可哀想で涙なしには見られない。

2015-02-28

DNSで使える便利な*（アスタリスク）

BIND DNS ドメイン

DNSの設定で*（アスタリスク）使えるとか知らなかった！

$ORIGIN infra.xyz.
（中略）
@       IN      A       153.121.58.159
www     IN      A       153.121.58.159
ns1     IN      A       153.121.58.159
ns2     IN      A       54.64.115.59
*       IN      A       153.121.58.159

infra.xyz.zoneにこんな感じで書いておくと、@とかwwwとかns2みたいに存在するレコードはそっちの値が返るし、それ以外（hoge.infra.xyzとか、fuga.infra.xyzとか、hoge.fuga.infra.xyzとか）は全部「153.121.58.159」が返ってくるよー。

サブドメインいっぱい作って、全部同じウェブサーバに向けるようなときは*（アスタリスク）便利！ BINDだけじゃなくて、お名前.comのネームサーバ（お名前.comの管理画面で登録するあれ）でも使えたー。

mochikoAsTechのdig日記

当方好きなコマンドはdigです！お友達から！！よろしくお願いします！！！