無料で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サイトの常時暗号化が一般的になる日もそう遠くないかもしれない。
スラドは? (スコア:2)
有料の証明書を採用するお金がないというなら、せめてLet's Encryptのを使って?
Re: (スコア:0)
別コメに書いてあるだろ…
法人にこそ流行って欲しい (スコア:1)
法人用途だと「法人なのに無料サービスなんて使えない」みたいな体面やらメンツやら出てくるけど、そこは機能で判断して欲しいよね。
ECサイトみたいに重要な個人情報を特に扱っていないサイトなら、Let's Encryptでも十分なはず。
というか、そういうサイト向けのサービスなんだよね?
#いるんだよ、本当に。
#法人が無料サービスなんか使っていいのか、みたいな話が。
#じゃあサーバに使っているCentOSは何なんだ、と聞いたら答えられないか、若しくは「Linuxは話が別だ」とか反論になっていない意味不明な事を言い出す奴らが。
Re:法人にこそ流行って欲しい (スコア:1)
個人的には企業は身元証明として Domain Validated (DV) 証明書ではなく Organization Validation (OV) 証明書を使って欲しい、予算に余裕があるなら Extended Validation (EV) 証明書にして欲しいと思ってる。
Re: (スコア:0)
なにかあったときに、誰の首をはねるかですよ。他社か自社か。
Re: (スコア:0)
そういうの気にする会社でCentOS使ってるって頭おかしくないですか?
Re: (スコア:0)
だからそんな頭おかしい会社があるってことだろう。
Re: (スコア:0)
突然証明書が使えなくなるリスクと責任の所在を考えたら無料サービスなんて使えないでしょ。
証明書とかカスみたいな金額使ってリスクヘッジするかしないかの話と、サーバーOSの選定は話が別でしょ。
Re: (スコア:0)
突然証明書が使えなくなるリスクって、例えばどんなケースが?
その証明書が使っているルート証明が、OSによって拒否されるとかぐらいしかないと思いますが……。
Let's Encryptは
とありますし、その可能性は薄いでしょう。
というか、サーバOSこそ金を使ってリスクヘッジすべき分野だと私は思いますが……。
Re: (スコア:0)
CA証明書の秘密鍵が漏れた場合とか?
証明書の期限が切れた場合とか
期限切れは突然ではないわな
Re: (スコア:0)
秘密鍵漏洩は、別にLet's Encryptに限った話じゃないですよね。
漏洩させないための運営体制が不安、という事であれば確かにその通りではありますので、そのあたりは他の返信よりは説得力がありますね。
でも、シマンテックとかComodoとか、大手もやらかしたりしてるので、本当に細かい事を言い出すと、大手に金を払っているから安心って事でもない様な気がしています。
まあ、それを言い出すとキリが無いと言えばそうですけど。
ところで、どこかが秘密鍵漏洩やらかしてなかったっけ……と思って探してみたけど、見つからないですね。
記憶違いでしょうかね……。
Re: (スコア:0)
https://ja.wikipedia.org/wiki/2011%E5%B9%B4%E3%83%87%E3%82%B8%E3%83%8E... [wikipedia.org]
これかな?
Re: (スコア:0)
は、厳密には
「両者の契約・契約書が存在しない者は使えない」
ですよ。
万が一サービスの停止やトラブルで障害や情報流出があった場合に、
責任問題をどうするか明確に取り決めていないと、コンプライアンス上アウトです。
契約書を交わして責任問題を明確に取り決めれるのであれば、企業は無料でも導入しますよ。
ただ、無料サービスでそこまでやってくれるところが基本殆ど無いわけで。
Re: (スコア:0)
責任の所在は、外部になければいけないんでしょうか?
他レスでもCentOSは話が違うと出ていますが、サポート契約は別にしていないですし、その場合に責任の所在がどこに出るかと言えば自社でしょう。
もちろん、銀行の勘定系のOSとかクレジットカードの決済サービスとかでそういった考えになるのはわかりますし、むしろ私も責任を取ってくれる有料の外部サービスを使った方が良いと思いますが、ただの証明書ですよ?
Let's Encryptの証明書に何かしらの独自要素があるなら、それに起因したトラブルとかはあり得ると思いますが……。
通常のトラブルについては、他の証明書も同じでしょう。
というか、他の有料証明書は何かトラブルがあった時、何らかの責任を取ったりするのですか?
有料の証明書を手配した事もありますが、障害や情報流出に関して証明書を発行した組織が責任を持つなんて話は聞いたことがありませんが……。
Re: (スコア:0)
同じサービスクオリティで、同じ事故が起こったとしても
新興の無料サービスに飛びついた結果事故が起こったと
多くの有力企業が使用している有料サービスで事故が起こったでは
対外的に受けるダメージが全然違うと想像できませんか?
「有料サービスなら実際に責任とってくれるか」なんて端から誰も期待も論じてもいないんですよ。
「ただの証明書」だからこそ「責任の所在は、外部になければいけない」んであり、「体面」が一番重要で「機能で判断」なんてしてたら会社が潰れちゃいます。
別に法人に流行らなくて良いかな (スコア:0)
流行で入れるようなところなどどうせ他のところがユルユル。
自分でLet's Encrypt使って良いかどうかも判断できないようなECサイトの
くせに「重要な個人情報を特に扱っていない」と素人判断される方が恐ろしい。
挙げ句の果てに確信を持ってすらいない発言に流されて使い出すとかホント
やめてほしい。
無論sslすら使ってないのは論外だけど、金払うくらいのプライドがあった方
がまだまし。コスト意識は残るしね。まぁ、その金でコンサルにでも相談した
方が良いけど。本でも買って勉強してくれるのが一番良いかな。
# OSSは金、人、技術のウチ二つ出せと申しますが、技術も無い、金も出さないでは目も当てられません。
Re: (スコア:0)
むしろ前例があるのだから結構な話じゃないですか>CentOS
Re:法人にこそ流行って欲しい (スコア:1)
そう、結構な話ではあるんですが……。
CentOS使ってるのにLet's Encryptは駄目、となるのがよくわからないんですよ。
他のレスでいくらか指摘を頂きましたが、有料の証明書を使った所で、
を頂けている様に思えません。
有料の証明書を使う事でどんな事象において、どんな責任回避が出来るのか、私は全く知りませんが……。
単なるドメイン認証の証明書でも、何か私の知らない特殊な契約とかあったりするんでしょうかね。
Re: (スコア:0)
その辺は法人向け損害保険の約款次第じゃないですかね、保険適用の範囲外になるかどうかは調べないとわかりませんが。
Re: (スコア:0)
扱う金額と、それに伴う経営層のコミットメントの大きさと、リスク顕現時の責任の所在を考えると「CentOSは良くてLet's Encryptは駄目」なんてケースはいくらでも起こりえます。
導入責任者の立場から見れば、年間数百数千万ならともかく、十数万節約するために自分の人生かけてられるかって話なんですよ。
CentOSは検討の余地がありますが、Let's Encryptに関してはただただ愚かしいの一言です。
Re: (スコア:0)
リスク評価で一番やばいのは
リスクがあることではなくて、リスクがあるのに問題がないと勘違いすること。
十数万円支払っただけで自分の人生がかかるようなリスク回避が出来ていると信じているようですが、それって本当ですか?
そんな契約存在してますか?
Re: (スコア:0)
> CentOSは良くてLet's Encryptは駄目な明確な理由
実績じゃない?多さというよりは時間的長さ。
2,3年すれば「なんでもっと早く採用しなかったんだ」とか言い出したり。
あとは節約可能な費用が少なすぎるから魅力的にうつらないとか。
「それだけ安くなるなら止む無し」と思えるかどうか。
Let's Encryptはどうかわからないけど大昔は安い証明書の証明機関がブラウザに初期状態では登録されていないものもあって
使っちゃうと警告でて印象悪いとか(詳しくない外部の方々からのクレームとかの対応で余計人件費かかるとか)
Re: (スコア:0)
機能以上に信頼と実績を重視すべきだろう。
実績という点でcentOSは申し分なく信頼という点でも後ろにRed Hatがいるというのは大きい。
突然終了しても割合スムーズにRed Hat製品に移行できるのも大きいな。
反面Let's Encryptは後援団体を見れば信頼できるが実績がないのが大きい。
Re: (スコア:0)
突然終了しても普通のSSLに戻ります、
でいいんでは
Re: (スコア:0)
突然の終了よりはLet's Encryptのサーバが改ざんされるなどする方が怖いな。
要はLet's Encryptのセキュリティに対する信用の問題。
1サイトあたり1/2枚弱? (スコア:1)
>380万以上のウェブサイトに対して、170万枚以上のサーバ証明書
逆ならまだ分かるんだけど。
多分、ウェブページに対して、という事なんだろうね。
慎重な言葉遣いをするなら、サイト=複数のページで構成される全体、となる。
Re:1サイトあたり1/2枚弱? (スコア:4, 参考になる)
原文 [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] より引用:
今の時代、1つのWebサーバで複数ドメインのHTTPSなWebサイトを配信するのは珍しくありません。その場合、SAN や SNI が使われます(両方とも Let's Encrypt で利用可能)。
例えば、「srad.jp」と「security.srad.jp」の両方を Let's Encrypt の証明書で HTTPS にしたい場合(実際には複雑な構成だと思いますが、仮にWebサーバが1台だとした場合)
のどちらも可能です。
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 を使用した証明書を発行することが可能です。
Re: (スコア:0)
サブドメインだったり、証明書がワイルドカードになってたり(でも推奨してなかったような)とかですかね?
Re: (スコア:0)
いやいや380万ウェブ *ページ* っていうんなら
ページ数が少なすぎだよ。
1サイト平均2ページなんてアリエナイ。
今流行のシングルページでAjaxバリバリのページなんてWEB全体からみたら少数派だよ。
うろ覚えだけど世のウェブサイトの大半はワードプレスだとかいう統計もあったから1サイト10記事/ページぐらいはあるはず。
ことHTTPSの対応サイトに限ったとしても EC-CUBEとかパッケージ関連で通販作ったサイトが多数のはずだから、商品数ごと1ページって考えると膨大なページ数となり平均値をかさ上げするから1サイト2ページでは収まらないと思うよ。
だから他の方の指摘のように1つの証明書で複数の"サイト"を賄っているってのが正解じゃないかな。
よかったのか、ホイホイ発行して。 (スコア:0)
54 2F 4F
DVなので用途上は問題ないでしょう (スコア:0)
VC9P
ここまで触れられないHTTP/2 (スコア:0)
HTTP/2の対応にはTLS接続が必須になるわけですが、
予算的にアレな個人サイトではオレオレ証明書で無理矢理通すと閲覧者が不用に警戒する
ここでLet's Encryptすれば無料でオレオレ証明書より安全にHTTP/2 Readyが達成できるわけです。
また、彼らはプラグイン等でCipher関連を含めたサーバの設定も行える。
(プライバシー的に)安全で高速なネット環境というのはこうやって整備されるのですね
Re: (スコア:0)
俺ならこのサイトによく似たサイトをつくって以下略しちゃうね!
Re: (スコア:0)
それで困るようならドメイン買い漁ってリダイレクト
証明書も買おうねって話になるわけです
とりあえずゲートウェイでの全体的な検閲からは避けられる
親親コメの通りHTTP/2Readyは達成されるのは良いね
親コメも一理あるし、ちゃんと用途を選ぼう