ライタス株式会社公式ブログ

ブラウザとサーバーの間に暗号化通信を行うために使われる仕組みとして、HTTPSがありますが、 他社のサーバーであったり、ブログサイトでは、持ち込みドメインでのHTTPSの利用は難しいケースが多いです。 Google Bloggerもこれまでは、HTTPSをカスタムドメインで利用することはできなかったのですが、 ついに対応されたようで、弊社でも早速設定をしてみました。 設定方法はいたって簡単。 ログイン後の左メニューから[設定] > [基本]を選択し、下にちょっとスクロールすると、下記の画面が出てきます。 ここで使用するに[はい]を設定することで利用ができるようになりました。 設定されるには時間がかかるようですが、しばらくしたら、反映されると思います。 [追記] 無事反映されたようです。 証明書の情報を見ると、Let's Encrypteで取得していることがわかります。 おそらく自動更新になっているので、問題ないかと思います。

Webサイトの証明書問題は、ここ最近注目を集めており、弊社でも問合せを受け付けています。 これまでSSL証明書を使用していなかったサイトでも、いよいよ安全ではないと警告が出るようになるため、企業サイトでの対応も必要になってきます。 散発的にニュースになるので、いくつかのトピックに分け、弊社としての見解をまとめてみました。 Symantecの証明書が無効化されてしまう問題 世界的に利用者の多いVerisignを買収したSymantecの証明書部門を米Digicert社に売却しました。 これにより、一部で混乱が起きていますが、日本においては、Symantecブランドは継続されるようなので、引き続き利用は可能という見解です。 ただし、Symantec SSLの一部でブラウザChromeから信頼されなくなる問題がありますので、念のためSSLチェッカー等で確認されることをお勧めします。 詳細情報 そのSSL/TLS証明書は大丈夫？　Google Chromeからhttpsサイトとして信頼してもらえなくなる場合も!?　－INTERNET Watch https://internet.watch.impress.co.jp/docs/special/1107715.html SSLチェッカー　（Symantec社提供） https://www.websecurity.symantec.com/ja/jp/support/ssl-checker SSLチェッカー　（GlobalSign提供） https://globalsign.ssllabs.com/ 証明書鍵の強度問題 証明書は、サイトとクライアントの間の通信を暗号化するために使用する鍵の役割を果たします。 ここ最近、この暗号化鍵を解読する脆弱性が研究されており、SHA-1の暗号化鍵はすでに脆弱性が明らかになっているため、対応が必要です。 現在の一般的な証明局では、SHA-256での鍵に対応しており、SHA-1での証明書を発行することはできないようになっています。 時々発見される脆弱性に対応しないと、暗号化通信が覗き見られる可能性があるので、注意が必要です。 暗号化鍵に使用するアルゴリズムの種類は、SHA-1,SHA-256がメジャーですが、近年楕円曲線暗号というものもある...

SmartScreenフィルターと言うものがあります。 Internet Explorerに搭載されているセキュリティ機能で、怪しいプログラムやフィッシングサイトを防いでくれるものですが、 普通に開発したプログラムをインターネットを介して展開しようとすると、SmartScreenフィルターが警告を発します。 警告画面の参考 グローバルサイン　Microsoft SmartScreenの警告表示 https://jp.globalsign.com/service/codesign/knowledge/signature/smartscreen.html https://jp.globalsign.com/service/codesign/knowledge/smartscreen.html この警告を回避する方法として、EVコードサイニング証明書を購入して、 署名を付けてコンパイルする（*Visual Studioの場合。それ以外はコンパイラの仕様によると思います）方法が紹介されています。 また、Windowsストアの開発者登録をして、Windowsストアからアプリケーションを配布することでも回避可能なようです。 EVコードサイニング証明書ではなく、通常のコードサイニング証明書を導入したとしても、SmartScreenフィルターからは、「ダウンロードしたユーザー数が少ないため、PCに問題を起こす可能性があります」という警告が出ることがあるようです。 秀まるおのホームページ　デジタル署名の確認方法 http://hide.maruo.co.jp/software/chktrust.html TechNet　スマートスクリーンフィルターの挙動が変わった？ https://social.technet.microsoft.com/Forums/ja-JP/cef3929f-c13d-41fb-9d2a-ec357cd97d52?forum=internetexplorerja コードサイニング証明書を取得するには、どのベンダーを選択すると良いかについては、下記のサイトが詳しいです。（ちょっと古い記事ですが） ダイアモンドアプリコット電話研究所　コードサイニング証明書を買う前に http://www.nda.co....

SCOMを運用してからおよそ1年が経過しました。 SCOMのコンソールから鳴き声が聞こえ始めたので、調べてみると、「通信証明書有効期限切れ確認」なる文字が・・・ 私のところでは、Windowsの証明機関を利用して通信証明書を発行していますが、発行される証明書の有効期限がデフォルトでは1年となっています。 これでは、毎年証明書を更新しなければ、死活監視もままならないということだったので、なんとか発行する証明書の有効期限を延ばせないか調べてみました。 答えは、以下のサイトにありました。 http://support.microsoft.com/kb/254632/ja Windows Server 2003 or Windows 2000 Server 限定と書いてありますが、同様の手順で、Windows Server 2008でも適用できました。 ポイントだけ抜粋して、以下に記載します。 regeditでレジストリエディタを起動 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>を開く [ValidityPeriod]をチェックして、Yearsになっていることを確認 [ValidityPeriodUnits]の値をチェック。 デフォルトは1になっている（要は1年）ので、これを好きなだけ増やす net stop certsvc & net start certsvcを実行する 設定する年数は、証明機関のルート証明書、あるいは中間証明書の期限以上には延ばせません。（切り詰められると思いますが、試していません。） ちなみに、設定後に証明書を発行して、SCOMにインポートすればエラーは消えますので、忘れずに証明書を更新しておきましょう。 インポートの仕方は、以前の記事ですが、 こちら をご覧ください。 証明書周りは制約が多いので、注意が必要です・・・ 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの記事を加筆修正したものです。

ちょっと前にワイルドカード証明書の紹介をしましたが、お客様のところで、「サーバー証明書が信頼できない」というありがちなエラーに遭遇しました。 最初は、WEBサーバーに中間証明書をインストールし忘れたのかなと思ったのですが、よく見るとちゃんとインストールされています。 現象が出ているクライアントPCの証明機関を確認したら、確かに信頼されたルート証明機関の一覧にルート証明書が存在していません。 なんでだー と悩んでも、ぐぐる先生に聞いても原因が分かりません。 クライアントにルート証明書が入っていないことには、いくらWEBサーバー側で対応しようとしても、理屈的に無理なわけで・・・（まじ、どうしようもないじゃん！？ふざけんなよ！？とか愚痴りたい） お手上げだと思って、先輩に相談したところ、以下のサイトを発見してくれました。 Windows PKI - その2 - ルート証明書更新プログラムとは？ http://blogs.technet.com/b/jpntsblog/archive/2009/12/24/windows-pki-2.aspx 上記サイトを簡単にまとめると以下のようになります。 ルート証明書はWindowsUpdateで配信される（ルート証明書更新プログラム） ルート証明書更新プログラムを有効にしておけば、勝手にダウンロードしてくれる（もちろん無効にしていれば、勝手にはダウンロードされない） Windows Vista以降は、Cryptographic Serviceとして動作する Windows Vista以降は、OSインストール時にルート証明書は、必要最小限しか持っていない この機能は、グループポリシーで制御可能 手元の環境で、同様の症状が出ているPCがあったので、ルート証明書更新プログラムが有効になっているかどうかを調べたところ、無効にされていました。 どのタイミングで無効になるのかはさっぱり分かりませんが、なにかあるのかも知れません。 とりあえず解決かな・・・と思っていますが、これから客先の環境を確認してこようと思います。 たぶん、WindowsUpdateが制限されていんじゃないかなとにらんでいます。 ちなみに、rootsupd.exeを使うという手もあるようです。確認はしていませんが、有効そう...

WEBサービスを提供する上で、必須とも言えるSSLサーバー証明書。 ただ、公的な証明局を利用すると結構高額です。 個人で使用するには、クイックSSLのような廉価版を利用することになります。 だいたいの証明局から発行されるサーバーIDは1つのFQDNしか使用できず、大量のサービスを別々のFQDNで運用する場合は、それぞれに対して証明書を購入する必要があります。 私のプロジェクトでも、このような状況はままありまして、どうしたものやら・・・と思って調べていたら、なんでも「ワイルドカード証明書」というものがあるらしいです。 ワイルドカード証明書について解説しているページを発見しましたので、以下に張っておきます。 http://jiro-omocha.blog.ocn.ne.jp/blog/2010/05/ssl_c5c7.html しかし、このワイルドカード証明書。 ライセンス形態というか、料金体系が各社まちまちなので、ちゃんと見ておかないと、後で痛いめを見る気がします。 たとえば、証明書自体は、ワイルドカードでも使用するサイトごとにライセンス料が発生するという証明局と、発生しない証明局があります。 また、同時購入がx個以上だと割引とか・・・ 日本で簡単に手に入るワイルドカード証明書は、以下の2つがオススメです。 株式会社アールエムエス(DigiCert社) スターフィールドSSL(Go Daddy社) 他にも、GeoTrustとか、GlobalSignとかがワイルドカード証明書を発行できますので、いろいろ比較検討してみてはいかがでしょうか。 どの証明局でもだいたい同じですが、Whoisの登録してあるメールアドレスを使用することになりますので、登録と異なる場合は、あらかじめWhoisの情報を修正しておく必要がありますので、注意が必要です。 弊社では、コストパフォーマンスに優れるDigicertの証明書をお取り扱いしております。 ご用命の際は、 弊社ホームページ よりお問い合わせください。 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの記事を加筆修正したものです。

答えを知っていれば、大した話ではないのですが、 知らなかったために、かなりハマったお話です。 オレオレクライアント証明書（自前CAで作成した証明書のこと）を利用して個人認証をされているWEBサイトがありました。 サーバーをリプレースするとのことだったので、 新たにサーバーを作って、WEB機能を移行したのですが、 クライアント証明書が思うように認証されません。 原因が最初サッパリだったのですが、 チェックするべき重要なポイントが2箇所ありました。 1. ルート証明書 2. 失効リスト 1つめは、サーバーにルート証明書を入れ忘れただけの話だったのですが、 オレオレ証明書の場合は、特に要注意ですね。 普通(?)の公認CAで出力された証明書は、最初からサーバーにインストールされていることが多く、 見落としがちなので、注意が必要かと思います。 2つめは、証明書の仕組みを知っていれば、気がつくポイントの一つですが、 見かけ上の振る舞いでは、気が付かない事が多いのです・・・ 今回は、Windows CAで証明書を作成したのですが、デフォルトの設定では、 CRLが、自動埋め込みになっているので、設定を変えてあげないと、使える証明書になりませんのでこちらも要注意ですね。 CRLを編集する方法は以下に記載があります。 http://technet.microsoft.com/ja-jp/library/cc753296(v=ws.10).aspx 今回は、証明書を入れたPCからWEBサイトを参照したところ、403.13 Forbittenが出たので、 分かったことですが、気が付かないままの可能性もあったので、ヒヤッとしました。 http://support.microsoft.com/kb/294305/ja | 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの転載です。

昔から、チラチラ見るエラーで、サーバーとしては対策の必要もないだろうと思って放置していたのですが、 問い合わせがあったのでメモ。 Source: crypt32   Message: < http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab > にある自動更新 cab ファイルからサードパーティのルート一覧を抽出できませんでした。エラー: 現在のシステム時計または署名ファイルのタイムスタンプで確認すると、必要な証明書の有効期間が過ぎています。 内容としては、プリインストールされているサーバー証明書の更新に失敗すると出るエラーのようです。 証明書は、基本的にはWindows Updateにて配布されるのですが、これの更新に失敗する事例があるそうです。 詳しい話と、その対策は、以下のサイトに記載があります。 http://blogs.technet.com/b/jpntsblog/archive/2010/07/22/crypt32-windows-xp-windows-server-2003-microsoft-windows-capi2-windows-vista.aspx 放置していたサーバーで、対策してみたので、効果を期待してます。 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの転載です。

前回の記事 に続き、技術面からSSLサーバー証明書の導入に関して、気をつけなければならないポイントを概説したいと思います。 注意ポイント１：暗号の強度 暗号の強度と言われても難しいと思いますが、重要なポイントです。 現在、だいたいの証明書ベンダーは2048bit以上の鍵を使った証明書でないと発行してくれない状態になっていますが、たまに1024bit長の鍵を受容するベンダーがあるようなので、秘密鍵の作成のときには、注意が必要です。 また、SHA-2での申請を要するようになってきましたので、そちらも証明書ベンダーの手順書などでご確認ください。 Symantec(元Verisign）は、楕円暗号方式をサポートしている証明書ベンダーなのでより強固な暗号化を実施したい場合はこちらも選択肢に入るかと思います。 注意ポイント２：記載内容 CSRを作成するときに、フレンドリ名や組織の内容を記載しますが、記載を極力正確に記載します。特にドメイン名（FQDN）を間違えると、せっかく購入した証明書が無駄になってしまうことがあります。 注意ポイント３：中間証明書 中間証明書とは、ルート証明書とサーバー証明書をつなぐ役割を果たす証明書です。文字で書いてもよくわからないので、絵を用意しました。 中間証明書をインストールするのはサーバー側なので、ここをミスするとサーバー証明書を入れた意味がありません。 中間証明書をチェックするサイトもありますので、インストール後にそちらでチェックすることをおすすめします。 また、クロスルート証明書が必要なケースもありますので、必ずインストールする際には、ベンダーが公開しているインストール手順にしたがって行う必要があります。 注意ポイント４：証明書のバックアップ 証明書のインストールが終わったら、証明書のバックアップを取得することをおすすめしています。 これは、サーバー証明書を再発行するときは有料になってしまうことや、ハードウェアに障害が発生したなどの場合に素早く復旧するときに使うことを想定してのことです。 バックアップした証明書の保管は、頭を悩ませるポイントですが、可能な限りネットワークに置かず、暗号化を施した後、CD-RやUSBメモリに保管し、金庫などで保管というのが、良さそうなシナリオです。他にもセ...