パスワードを忘れた? アカウント作成
12754720 story
暗号

無料でSSL/TLS証明書を発行するLet's Encryptが正式サービスを開始 34

ストーリー by hylom
そろそろ試してみよう 部門より
Printable is bad. 曰く、

無料でSSL/TLS証明書を発行するプロジェクト「Let's Encrypt」が、オープンベータテストを終えて正式サービスを開始した(公式発表公式発表の和訳GIGAZINE)。

2015年9月のベータテスト開始以来、Let's Encryptの証明書発行数は急増しており、380万以上のウェブサイトに対して、170万枚以上のサーバ証明書を発行するに至っている。

Let's Encryptでは、IETFで標準化されているACMEというオープンプロトコルで証明書の発行手続きを完全自動化しており、いくつかのコマンドを実行するだけで簡単に証明書を取得することができる。

ファーストサーバWordPress.comなど、ホスティングサービスへのLet's Encryptの導入も進んでおり、Webサイトの常時暗号化が一般的になる日もそう遠くないかもしれない。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Patilise (45974) on 2016年04月20日 10時47分 (#3000653)

    有料の証明書を採用するお金がないというなら、せめてLet's Encryptのを使って?

    • by Anonymous Coward

      別コメに書いてあるだろ…

  • by Anonymous Coward on 2016年04月18日 12時16分 (#2999535)

    法人用途だと「法人なのに無料サービスなんて使えない」みたいな体面やらメンツやら出てくるけど、そこは機能で判断して欲しいよね。
    ECサイトみたいに重要な個人情報を特に扱っていないサイトなら、Let's Encryptでも十分なはず。
    というか、そういうサイト向けのサービスなんだよね?

    #いるんだよ、本当に。
    #法人が無料サービスなんか使っていいのか、みたいな話が。
    #じゃあサーバに使っているCentOSは何なんだ、と聞いたら答えられないか、若しくは「Linuxは話が別だ」とか反論になっていない意味不明な事を言い出す奴らが。

    • *.srad.jp, *.osdn.jp の証明書に関して言えば、GeoTrust の RapidSSL [rapidssl.com] を採用している。
      個人的には企業は身元証明として Domain Validated (DV) 証明書ではなく Organization Validation (OV) 証明書を使って欲しい、予算に余裕があるなら Extended Validation (EV) 証明書にして欲しいと思ってる。
      親コメント
    • by Anonymous Coward

      なにかあったときに、誰の首をはねるかですよ。他社か自社か。

    • by Anonymous Coward

      そういうの気にする会社でCentOS使ってるって頭おかしくないですか?

      • by Anonymous Coward

        だからそんな頭おかしい会社があるってことだろう。

    • by Anonymous Coward

      突然証明書が使えなくなるリスクと責任の所在を考えたら無料サービスなんて使えないでしょ。
      証明書とかカスみたいな金額使ってリスクヘッジするかしないかの話と、サーバーOSの選定は話が別でしょ。

      • by Anonymous Coward

        突然証明書が使えなくなるリスクって、例えばどんなケースが?

        その証明書が使っているルート証明が、OSによって拒否されるとかぐらいしかないと思いますが……。
        Let's Encryptは

        IdenTrust のルート証明書によってクロス署名されています。

        とありますし、その可能性は薄いでしょう。

        というか、サーバOSこそ金を使ってリスクヘッジすべき分野だと私は思いますが……。

        • by Anonymous Coward

          CA証明書の秘密鍵が漏れた場合とか?
          証明書の期限が切れた場合とか
          期限切れは突然ではないわな

          • by Anonymous Coward

            秘密鍵漏洩は、別にLet's Encryptに限った話じゃないですよね。
            漏洩させないための運営体制が不安、という事であれば確かにその通りではありますので、そのあたりは他の返信よりは説得力がありますね。

            でも、シマンテックとかComodoとか、大手もやらかしたりしてるので、本当に細かい事を言い出すと、大手に金を払っているから安心って事でもない様な気がしています。
            まあ、それを言い出すとキリが無いと言えばそうですけど。

            ところで、どこかが秘密鍵漏洩やらかしてなかったっけ……と思って探してみたけど、見つからないですね。
            記憶違いでしょうかね……。

    • by Anonymous Coward
      「法人なのに無料サービスなんて使えない」
      は、厳密には
      「両者の契約・契約書が存在しない者は使えない」
      ですよ。

      万が一サービスの停止やトラブルで障害や情報流出があった場合に、
      責任問題をどうするか明確に取り決めていないと、コンプライアンス上アウトです。


      契約書を交わして責任問題を明確に取り決めれるのであれば、企業は無料でも導入しますよ。
      ただ、無料サービスでそこまでやってくれるところが基本殆ど無いわけで。
      • by Anonymous Coward

        責任の所在は、外部になければいけないんでしょうか?

        他レスでもCentOSは話が違うと出ていますが、サポート契約は別にしていないですし、その場合に責任の所在がどこに出るかと言えば自社でしょう。

        もちろん、銀行の勘定系のOSとかクレジットカードの決済サービスとかでそういった考えになるのはわかりますし、むしろ私も責任を取ってくれる有料の外部サービスを使った方が良いと思いますが、ただの証明書ですよ?

        Let's Encryptの証明書に何かしらの独自要素があるなら、それに起因したトラブルとかはあり得ると思いますが……。
        通常のトラブルについては、他の証明書も同じでしょう。

        というか、他の有料証明書は何かトラブルがあった時、何らかの責任を取ったりするのですか?
        有料の証明書を手配した事もありますが、障害や情報流出に関して証明書を発行した組織が責任を持つなんて話は聞いたことがありませんが……。

        • by Anonymous Coward

          同じサービスクオリティで、同じ事故が起こったとしても
          新興の無料サービスに飛びついた結果事故が起こったと
          多くの有力企業が使用している有料サービスで事故が起こったでは
          対外的に受けるダメージが全然違うと想像できませんか?

          「有料サービスなら実際に責任とってくれるか」なんて端から誰も期待も論じてもいないんですよ。
          「ただの証明書」だからこそ「責任の所在は、外部になければいけない」んであり、「体面」が一番重要で「機能で判断」なんてしてたら会社が潰れちゃいます。

    • 流行で入れるようなところなどどうせ他のところがユルユル。
      自分でLet's Encrypt使って良いかどうかも判断できないようなECサイトの
      くせに「重要な個人情報を特に扱っていない」と素人判断される方が恐ろしい。

      挙げ句の果てに確信を持ってすらいない発言に流されて使い出すとかホント
      やめてほしい。

      無論sslすら使ってないのは論外だけど、金払うくらいのプライドがあった方
      がまだまし。コスト意識は残るしね。まぁ、その金でコンサルにでも相談した
      方が良いけど。本でも買って勉強してくれるのが一番良いかな。

      # OSSは金、人、技術のウチ二つ出せと申しますが、技術も無い、金も出さないでは目も当てられません。

    • by Anonymous Coward

      むしろ前例があるのだから結構な話じゃないですか>CentOS

      • by Anonymous Coward on 2016年04月18日 14時54分 (#2999647)

        そう、結構な話ではあるんですが……。

        CentOS使ってるのにLet's Encryptは駄目、となるのがよくわからないんですよ。
        他のレスでいくらか指摘を頂きましたが、有料の証明書を使った所で、

        • 「ただの証明書」が起因となるどんなトラブルが起こりえて
        • 有料の証明書を使う事でどんな責任を取ってくれて
        • CentOSは良くてLet's Encryptは駄目な明確な理由

        を頂けている様に思えません。
        有料の証明書を使う事でどんな事象において、どんな責任回避が出来るのか、私は全く知りませんが……。
        単なるドメイン認証の証明書でも、何か私の知らない特殊な契約とかあったりするんでしょうかね。

        親コメント
        • by Anonymous Coward

          その辺は法人向け損害保険の約款次第じゃないですかね、保険適用の範囲外になるかどうかは調べないとわかりませんが。

        • by Anonymous Coward

          扱う金額と、それに伴う経営層のコミットメントの大きさと、リスク顕現時の責任の所在を考えると「CentOSは良くてLet's Encryptは駄目」なんてケースはいくらでも起こりえます。
          導入責任者の立場から見れば、年間数百数千万ならともかく、十数万節約するために自分の人生かけてられるかって話なんですよ。
          CentOSは検討の余地がありますが、Let's Encryptに関してはただただ愚かしいの一言です。

          • by Anonymous Coward

            リスク評価で一番やばいのは
            リスクがあることではなくて、リスクがあるのに問題がないと勘違いすること。

            十数万円支払っただけで自分の人生がかかるようなリスク回避が出来ていると信じているようですが、それって本当ですか?
            そんな契約存在してますか?

        • by Anonymous Coward

          > CentOSは良くてLet's Encryptは駄目な明確な理由

          実績じゃない?多さというよりは時間的長さ。
          2,3年すれば「なんでもっと早く採用しなかったんだ」とか言い出したり。

          あとは節約可能な費用が少なすぎるから魅力的にうつらないとか。
          「それだけ安くなるなら止む無し」と思えるかどうか。

          Let's Encryptはどうかわからないけど大昔は安い証明書の証明機関がブラウザに初期状態では登録されていないものもあって
          使っちゃうと警告でて印象悪いとか(詳しくない外部の方々からのクレームとかの対応で余計人件費かかるとか)

    • by Anonymous Coward

      機能以上に信頼と実績を重視すべきだろう。
      実績という点でcentOSは申し分なく信頼という点でも後ろにRed Hatがいるというのは大きい。
      突然終了しても割合スムーズにRed Hat製品に移行できるのも大きいな。
      反面Let's Encryptは後援団体を見れば信頼できるが実績がないのが大きい。

      • by Anonymous Coward

        突然終了しても普通のSSLに戻ります、
        でいいんでは

        • by Anonymous Coward

          突然の終了よりはLet's Encryptのサーバが改ざんされるなどする方が怖いな。
          要はLet's Encryptのセキュリティに対する信用の問題。

  • by Anonymous Coward on 2016年04月18日 12時17分 (#2999536)

    >380万以上のウェブサイトに対して、170万枚以上のサーバ証明書

    逆ならまだ分かるんだけど。
    多分、ウェブページに対して、という事なんだろうね。
    慎重な言葉遣いをするなら、サイト=複数のページで構成される全体、となる。

    • by Printable is bad. (38668) on 2016年04月18日 12時58分 (#2999567)

      原文 [letsencrypt.org] にも 「we’ve issued more than 1.7 million certificates for more than 3.8 million websites」 とありますので、誤訳ではありません。

      証明書数がウェブサイトの数(ドメインを1つのWebサイトとカウント)を上回っているのはSANが利用されているためです。

      Let's Encrypt 正式サービス開始と新スポンサー [letsencrypt.jp] より引用:

      訳注:
      (中略)
      サーバ証明書発行対象のウェブサイトの数が、サーバ証明書発行枚数を上回っているのは、サブジェクトの代替名 (SAN:Subject Alternative Name) [letsencrypt.jp]という仕組みを使うことで、1枚の SSL/TLS サーバ証明書を、複数の異なるドメイン名で使用することが可能な為です。

      今の時代、1つのWebサーバで複数ドメインのHTTPSなWebサイトを配信するのは珍しくありません。その場合、SAN や SNI が使われます(両方とも Let's Encrypt で利用可能)。

      例えば、「srad.jp」と「security.srad.jp」の両方を Let's Encrypt の証明書で HTTPS にしたい場合(実際には複雑な構成だと思いますが、仮にWebサーバが1台だとした場合)

      • 「srad.jp」用の証明書と「security.srad.jp」用の証明書の2枚を発行して、TLSハンドシェイク時にクライアントが伝えてくれたホスト名をもとに証明書を振り分ける方法(SNI)
      • SANsに「srad.jp」「security.srad.jp」の両方を記載した1枚の同一の証明書を、「srad.jp」でも「security.srad.jp」でも使う方法

      のどちらも可能です。

      SNI は Windows XP + IE や Android 2.x だと非対応 [wikipedia.org] なので、SAN の方が対応ブラウザは多いかと思います。ただ、古めのガラケーは SAN にも非対応なことが多いです(Android 2.x が SAN 対応かは未確認)。

      また、SNI と SANs の併用(srad.jp と security.srad.jp を SAN を利用した1枚の証明書として、更に同一のサーバで SNI を利用して other-site.www.example.jp, other-site.www2.example.jp を配信するなど)も可能です。

      ちなみに、証明書発行コマンドのパラメータとして複数ドメインを列挙する [letsencrypt.jp] だけで自動的に SAN を使用した証明書を発行することが可能です。

      親コメント
    • by Anonymous Coward

      サブドメインだったり、証明書がワイルドカードになってたり(でも推奨してなかったような)とかですかね?

    • by Anonymous Coward

      いやいや380万ウェブ *ページ* っていうんなら
      ページ数が少なすぎだよ。
      1サイト平均2ページなんてアリエナイ。

      今流行のシングルページでAjaxバリバリのページなんてWEB全体からみたら少数派だよ。
      うろ覚えだけど世のウェブサイトの大半はワードプレスだとかいう統計もあったから1サイト10記事/ページぐらいはあるはず。

      ことHTTPSの対応サイトに限ったとしても EC-CUBEとかパッケージ関連で通販作ったサイトが多数のはずだから、商品数ごと1ページって考えると膨大なページ数となり平均値をかさ上げするから1サイト2ページでは収まらないと思うよ。

      だから他の方の指摘のように1つの証明書で複数の"サイト"を賄っているってのが正解じゃないかな。

  • by Anonymous Coward on 2016年04月18日 12時53分 (#2999561)

    54 2F 4F

  • by Anonymous Coward on 2016年04月18日 21時28分 (#2999827)

    HTTP/2の対応にはTLS接続が必須になるわけですが、
    予算的にアレな個人サイトではオレオレ証明書で無理矢理通すと閲覧者が不用に警戒する
    ここでLet's Encryptすれば無料でオレオレ証明書より安全にHTTP/2 Readyが達成できるわけです。
    また、彼らはプラグイン等でCipher関連を含めたサーバの設定も行える。

    (プライバシー的に)安全で高速なネット環境というのはこうやって整備されるのですね

    • by Anonymous Coward

      俺ならこのサイトによく似たサイトをつくって以下略しちゃうね!

      • by Anonymous Coward

        それで困るようならドメイン買い漁ってリダイレクト
        証明書も買おうねって話になるわけです
        とりあえずゲートウェイでの全体的な検閲からは避けられる

        親親コメの通りHTTP/2Readyは達成されるのは良いね
        親コメも一理あるし、ちゃんと用途を選ぼう

typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...