これは、いわゆる無料の SSL/TLS 証明書なわけですが、ブラウザ Mozilla Firefox を作っているモジラ財団とか、
ネットワーク機器大手のシスコとか、ネットワークインフラ大手のAkamaiとかが出資している大規模なプロジェクトなので、
途中で有料化したり、サービス停止になったりする心配もありません。
さらに、全ブラウザにルート認証局として入っているアメリカの最大手CA IdenTrust の傘下の証明書という扱い（クロスルート）になったので、
クローズベータをやっている現時点でも、全ブラウザに対応しているという神証明書です。
はっきりいって、IdenTrust の証明書をけっているブラウザなんて考えられないので、ジオトラストとかのドメイン認証証明書と同格以上の証明書が
無料で手に入ることになります。
明々後日からは、専用クライアントをダウンロードして、コマンドを実行するだけで、VPS など root 権限があるサーバとドメインがあれば証明書が入手可能なので、
期待しておきましょう。
もう、SSL/TLS の証明書にお金をかける時代はおわったのです（ただし、実在証明を含むEV証明書を除く）
【Let's Encrypt 公式サイト】（英語）
ttps://letsencrypt.org/ 【Let's Encrypt 公式Twitter】（英語による最新情報）
ttps://twitter.com/letsencrypt 【Let's Encrypt 総合ポータル】（日本語）
ttps://letsencrypt.jp/ 【Let's Encrypt 導入方法】（日本語）
ttps://letsencrypt.jp/usage/ Let's Encrypt のローンチスケジュールは延期されてきましたが、
2015年12月3日 に Let's Encrypt 公開ベータプログラム（Public Beta Program）が開始される予定です。
公開ベータプログラム開始後は、独自ドメインとWebサーバがあれば、誰でも簡単に Let's Encrypt の SSL/TLS 証明書を取得することができます。
【対応ブラウザとOS】
Let's Encrypt の「SSL/TLSサーバ証明書」は、アメリカ合衆国大手認証局（CA）である IdenTrust 社のルート証明書から
チェーンできるクロスルート (クロスサート) 証明書です。IdenTrust 社の証明書によって、
中間証明書「Let's Encrypt Authority X1」および「Let's Encrypt Authority X2」に対するクロス署名が行われています。
そのため、Let's Encrypt 発行の証明書は、大手認証局（CA）が有償で販売している証明書と同様に、ほとんどのWebブラウザやOSが標準で対応しています。
・Microsoft Internet Explorer (Windows)
・Google Chrome (Windows、Mac OS X、Linux、Android、iOS)
・Mozilla Firefox (Windows、Mac OS X、Linux、Android、iOS)
・Apple Safari (Mac OS X、iOS) など
（
ttps://letsencrypt.jp/より引用） root権限のあるサーバならば、
ttps://letsencrypt.jp/usage/ （日本語）にある手順の通りに、 クライアントをダウンロードしてコマンドをうつだけで導入可能
しかし、SNI 対応のレンタルサーバ（VALUE SERVER とか COREサーバーとか、さくらのレンタルサーバ）とかに居れる場合、
root権限必須の専用クライアントが動作しないため、証明書の発行作業を仮想環境でやる必要がある
なので、ローカルの Windows パソコンとかで VirtualBox などの仮想環境構築ツールに CentOS などのOSをインストールして
そこで Let's Encrypt のクライアントを動かす必要あり
自動認証ではなく、手動認証のオプションを指定することで、サーバのドキュメントルートに、Let's Encryptクライアントが指示した
JSON ファイルを設置することで、ドメイン所有者の認証プロセスが完了するので、レンタルサーバでも SNI 対応なら使える模様
手動認証のオプションコマンドについては、下記ドキュメントを参照
【Let’s Encrypt クライアントのドキュメント】（英語）
ttps://letsencrypt.readthedocs.org/en/latest/ 専用サーバ、VPS などのroot有りのサーバならコマンド一発で使えるけど、
共有サーバだと Linux アプリ（root）を実行できる環境がないと、多少面倒です
やっぱ潰れちゃう？
ドメイン名認証しているだけだからLet's Encryptより優れている点が1つもないし
IE でも Firefox でも Opera でも Google Chrome でも Safari でも正規証明書扱い
あげくためしてみたら、Lynx とか wget とかそういったテキスト系ブラウザでも正規証明書と認証
SHA-2証明書だからガラケー対応は怪しいけど、VeriSignとかもSHA-2に移行したから同じことだし
これは認証局あちこち潰れる予感
これからは認証局はアドレスバーが緑になる EV SSL 売っていくしか存続手段が無いだろう
大手企業のサイト運営している気分になれそう
興奮して夜も眠れなさそうだ
だって、プライバシーマークの協会だって、HTTPなんだぜ？
ttp://privacymark.jp/ それなのに個人がSSL使えるとか、すごくね？
使う分にはいいんだけど、悪用する人への対策はどうなるのかな
90日間固定
90日な理由は
ttps://letsencrypt.jp/blog/2015-11-09.html に書かれてる Let's Encrypt は、
$ ./letsencrypt-auto certonly -a standalone \
-d example.com -d www.example.com \
--server
ttps://acme-v01.api.letsencrypt.org/directory --agree-dev-preview みたいなコマンド一発で証明書を取得・更新できるので、2ヶ月に一回ぐらいコマンドを手動で実行するか、cron で回してください、ってことらしい
なるほど。自動化できるんなら運用で躓くことは少なそうだな。
STGとかなら良いけど、一般公開しているサイトでは二ヶ月に一回もやりたくない
初心者向けモード（オプション無し）だとポート80のweb鯖を止める必要あるけど、
コマンドラインオプションで apacheとか既に動いてるweb鯖のdocument root 指定すれば止めなくてすむ
（そのdocument root 以下に認証用ファイルを設置して認証してくれる）
ただ、証明書はメモリに読み込まれてるだろうから
service httpd restert はいるだろうけど、
ダウンタイムは1～2秒だろう
漏れはクローズベータの初期からやってるけど
httpd stop → 証明書更新 → httpd start で1秒足らずだよ
でも漏れは小心者で万が一httpdの起動に失敗したら怖いので月1ぐらいで手動でやるわw
同じ理由でyum update とか、geo ip の更新とかも手動でやってるから
日常鯖メンテのプロセスに1分以内の作業が加わるだけだから
手動でも特に気にならん
サーバーって放置で運営するもんでもないし
今や同じのが無料だもんな
やっぱり認証局はボロ儲けだったんだな
なるほど、認証用ファイル設置も自動でやってくれるのか
再起動はlogrotate時に任せても良いけど、起動しなかったら夜中に起こされるな・・・
自動化出来るところは自動化したいよ
10や20なら手動でもいいけど・・・
なるほど
10や20を超える大量の鯖管理してたら
確かに自動化が重要やな
はてブのブックマーク数とかツイート数とかがリセットされるよね
googleのランクは301リダイレクトで完全に引き継げるらしいけどね
httpへのリンクのまでも、httpsの方にリンクしているとみなしてくれるので
リンク効果も引き継げる模様
Googleはフルssl推進派だし、sslサイトのランクを上げる対応をしているので当然とも言えるが
楽しみだわ
早く証明書が欲しいﾆｬﾝ
www無しで取ると、www付きが Subject Alternative Names（サブジェクトの別名）に入るけど、
それ以外はワイルドカードもサブジェクトの代替も無理だったと思う
サブドメインでも取れるし、常識的な範囲なら枚数制限もないから
サブドメインごとに証明書とって、SNIで振り分ければOK
サーバ会社の方でも対応してほしいね
アメリカ時間だから、日本だと4日～5日だと考えた方が良いぞ
時差ってもんがあるからな
てかアメリカってタイムゾーンいっぱいあったよね？
今は git の時代だからね
ディストリに依存せずにコマンド1つでパッケージを取得できる素晴らしいシステムですから
Cent OS 7 iptablesがなくなってFirewalldになったりとか
同じくCent OS 7 でMySQLじゃなくてMariaDBになったりとか
なんかgitという聞いたこともないようなものが飛び出したりとか
なんで Linux の世界ってこんなに変わっちゃったんですか？
10年以上も（下手したら20年近く？）、iptables, Apache, MySQL が主流でそれがずっとかわらなかったし
安定してて特に問題もなかったのに、なんで新しいソフトの動作覚えないといけないんでしょう
これっておじさんの鯖管を虐めて若者がいい気になりたいだけでは？
実際若い人に「なんで Apacheじゃ駄目なの？」とか「なんで iptables じゃ駄目なの？」と聞いても
「今は○○が主流になってきており・・・」とか「多少軽いらしいです」とかどうでもいいような返答しか返ってこないし
わざわざ再学習のコストかけてまで変える必要ないよね
↓
なんで、ちょっと軽い程度の理由でnginxに移行しないといけないんだろう
httpd.confとかmod_rewriteとかの書き方覚え治すだけのメリットあるとは思えない
サーバ負荷になってるのはhttpdじゃなくてphp / CGIとかSQLなんだから
httpdを軽いのに乗り換えたって全体としては誤差だろ
必要になったらnginxのリバースプロクシたてればいい
だよね
会社でちょっとしたWebサービスを公開するときなんかに
若い社員に今時Apacheなんて時代遅れだからnginxにしろと言われるけど
まだまだApacheでいけるよね
若い社員になんと言われても「特に必要がある場合を除き、実績のある枯れたソフトウェアを使うのが望ましい」とApacheを押し通すことにする
Let's Encrypt は Apache ・ nginx のどちらかに依存してるわけじゃないよ
lighttpd って /usr/local/www/data に拡張子無しのファイル置いたら text/plain のMIMEヘッダで外部からアクセス可能になるよね？
なら、下記のコマンドで証明書の取得までは一発でいけるはず（lighttpd を起動したままでOK）
./letsencrypt-auto certonly -a webroot --webroot-path /usr/local/www/data \
-d example.com -d www.example.com \
--server
ttps://acme-v01.api.letsencrypt.org/directory --agree-dev-preview たぶん、上記で起動したままでいけるはずだけど、もし lighttpd が IIS みたいに拡張子無しのファイルには外部からアクセスできない仕様だとすると、
一回停止させてから
ttps://letsencrypt.jp/usage/ の手順でやる必要がある（その場合ダウンタイム有り） あと、/usr/local/etc/lighttpd の書き換えは自動で行われないから手動でやらないといけないわけだけど、
ttp://l-w-i.net/t/lighttpd/ssl_001.txt によると、 「証明書はPEM形式の必要があるが、秘密鍵(.key)と証明書(.crt)を別々に所有している場合は以下の手順で両者を結合する。」
とのこと（2007/9/19更新 だから今は違うか）
とまぁこれぐらいの手間かければ好きなWeb鯖で使えるってことだ
H20って水？
どういう意味？
> わざわざ再学習のコストかけてまで変える必要ないよね
こんな事言ってる奴は爺じゃなくても向いてないと思う
sslやらCDNやらアクセス解析やらなんでもやってくれるんで
H2Oとかnginx含めて自前でリバースプロクシ建てる必要を感じない
おいしい水だよ
ttps://letsencrypt.jp/usage/ を読んだ限りでは更新時に同意求める画面が開くようだから cron で自動化ができるのかよくわからん。
できるなら月1回の更新になるけど更新しすぎとか警告来るかな
そのページの下の方に利用規約への同意は保存されると書かれてる
Name is not whitelisted
というエラーです。
まだパブリックになってないのかな
今は、クローズベータだから、クローズベータで承認されたドメインでしか使えないの。
パブリックベータになったら、そのエラー出なくなるよ
パブリックベータ開始は、アメリカ時間の今日中だから、もうしばらくお待ちを
ttp://letsencrypt.status.io/ > Public Beta begins at 6 PM GMT on 3 December.
日本時間だと明日の午前3時だな。
全WebサイトのSSL(TLS)化を目指しているプロジェクトなんだから https のリンクにしてあげないと可哀想です
ttps://letsencrypt.status.io/ 貴重な情報サンクス
わくわくするぜ
やっぱりHTTPSしか想定してないんだろうか
無理やりやるとしたら、メールサーバ用のWEBサーバ別に立てて証明書作って、
さらに自動化処理の中に作成した証明書ファイルをメールサーバに
コピる処理を作らなければならないのかな
Postfix とか、Dovecot とか最近のメール鯖はちゃんと暗号化の
メカニズムを内蔵してる。証明書はウェブと同じものが使える。
あー、そうなんだけど、
WEBサーバ無しの(外部からポート80接続させない)メールサーバだけでは
証明書の自動処理できないでしょって話。
外部から接続できるWEBサーバで自動処理を動かして証明書ファイルを受け取るわけでしょ？
それをメールサーバの所定のディレクトリに配置するには自分で仕組みを作らないとってこと。
それともメールサーバだけで完結する何かいい方法あります？
ttp://letsencrypt.jp あと30分ちょいか
手作業でいれたやつ対応させるとするか、、
ttps://letsencrypt.jp/usage/ の解説のとおりにやってみたら 5分足らずであっさり証明書取得できたわ
あまりにも簡単で拍子抜けたわ
letsencryptのスクリプトで内蔵httpd立ち上げてるみたいだから行けるんじゃないの
うまく出来ました。
cron 用のスクリプトで動作できましたので月1回動作で登録します
12月と1月が31日まで、2月が29日までだからちょうど90日です。
つまりhttpアクセス禁止してるサーバじゃ無理
普段HTTP起動していないんだから何の問題もない
ごめん勘違いしてた
一応他のポートでも行けるようにする議論はあるみたい
それならサーバ毎にポート分けて対応できそうな気がするが
スラドでも記事になったようだぞ
【サーバー証明書を無料発行する「Let's Encrypt」がパブリックベータに移行】
ttp://security.srad.jp/story/15/12/05/0454205/ 今夜から使うぞ
./letsencrypt-auto certonly -a standalone \
-d letsencrypt.jp -d www.letsencrypt.jp \
--server
ttps://acme-v01.api.letsencrypt.org/directory をその分ドメインだけ変えて繰り返せばよいのかな。
ん？SANじゃなくてSNIなのですが…
何でも聞かないとできないタイプか
は？
SANsの証明書を使いまわせばいいだけだろ
こっちはかなり楽そうだな
説明通りに設定するだけで使える。メリットでもあるし、デメリットにもなるかもしれないなｗ
証明書だけじゃなく、SSL の動作に関してもある程度設定詰めないといけないしね。
まぁそれすら生成してくれるサイトあるけど。
ウェブ素人なんや
察してくれ
ttp://www.atmarkit.co.jp/ait/articles/1512/07/news072.html これは Let's Encrypt がどんどん普及していくかもしれない
マルチドメインはなんだかなーなんだよなー
となってるな
マウスクリックしかできないweb素人でも
一瞬で証明書が取れる時代になったわけだ。
の通り 5 個だった。
話変わるけど、
<VirtualHost *:443>
Define vhost hoge.example.com
ServerName ${vhost}
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/${vhost}/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/${vhost}/privkey.pem
SSLCACertificateFile /etc/letsencrypt/live/${vhost}/fullchain.pem
...
...
こう書けば証明書の記述はコピペで行けるから楽だな。
letsencrypt-auto の証明書配置好きだわｗ
全部外部向けに https で公開したいわけじゃないけど
7日間で5証明書では毎日チビチビ取得するの面倒だな
β取れたら緩和されるかな？
>SSLCACertificateFile /etc/letsencrypt/live/${vhost}/fullchain.pem
これ間違ってない？
証明書の発行やらは現状だと httpd 止めないと行けないからあまりホスト数多いと更新の時点ではダウンタイム長くなりそうだな。
そこは fullchain.pem か chain.pem どっちでもいいけどそうした方が結果としては良い。
最悪無くとも暗号化経路は確保されるけど SSL Server Test のスコア落ちるから嫌だｗ
いんや、そっちじゃなくて
SSLCA～
クライアント証明書を認証するためのサーバー側のCA証明書ストアを記述するディレクティブじゃない？
って話
SubjectAltName は証明書を見るとサブドメインが全部バレてしまうので嫌なんじゃー
自動で大量取得されないため？
でもオープンソースだからどうにでもなるよね
それ、初回だけだよ
ライセンス同意とメールアドレスの入力の内容は保存されるので
他のドメインで取得する場合でも、確認画面などは一切立ち上がらずコマンドのみでいける
ああ、なぜそのディレクティブが～ってって事か。
俺もそれは謎に思って調べたら Let's Encrypt のフォーラムでそう記述するところが大半だった。
SSLCACertificateFile の指定が無いと SSL Server Test で Incomplete Chain だかなんだかアラートが出た。
この点、今一理解してないｗ
全部CUIでいいじゃん
--debug とかログとか見ると、あれのために python の追加モジュールとか
色々インストールさせられるみたいなんだけど
普段 python なんか使わないからゴミが増えて邪魔なんだよなぁ
まだ Apache2.2 使いだから Apache2.4 のことはよくわからない
そんな恐ろしいことできるわけない
内部向けは内部にCA作ってWindowsのポリシーで信頼させてる
WindowsでActiveDirectoryのみになるけどこれが楽
最新の Apache でも同じ。obsolute だけど。
SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem
となってるな、Apacheは 2.4.7
証明書は発行してもらいました
Let's Encrypt の秘密鍵は暗号化されてないので、本来は不要
もし、バリューサーバーが空白の暗号キーを受け付けないなら、
openssl のコマンドで、何らかのパスフレーズで秘密鍵を暗号化して、
そのパスフレーズを入力すればおっけー
共有レンサバとはいえ秘密鍵を盗める状況じゃ
他が詰んでる気がするんだけどどうなの
あともう直ってるかもしれないけど
俺がやったときはCA証明書がエラーで設定できなかったよ
サポートに言えばやってくれるけど3ヶ月ごとに連絡は面倒だわな
パスワードの入力は必須とありますね。
正常に接続出来た様です。ありがとうございました。
すでにサブドメインで何十とサイトがあると導入失敗リスク高いよね多分
まぁテスト環境でも作っていっぺん導入してみるか
Rapid は値上げしたから他のにしたら。
俺だよ俺、俺だけどさ
え、俺って誰だって？ いや俺は俺だよ
メールで添付したルート証明書、インストールしてくれない？
ttp://www.cacert.org 5 domain 制限越えられるかなってやったら追加で証明書取れたよ。
ttps://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 ５ドメインずつ分けて週一で取得or更新しにいくドメイン管理スケジューラみたいなのが無いと
ややこしいことになりそうだ
週に５ドメインで、60日に一度更新が推奨されてるからざっくり最大40ドメインが限界か
期限が 30～40 日前程度になった証明書は更新させてしまう。
って言うような単純なスクリプトを書いて回してるよ。
Too many うんたらで週制限掛かっても、cron で毎日勝手にリトライすることになるから
制限が外れ次第順次更新いけるはず。
更新周期は 60 日に一度とかなっているけど、実際にはもっと速く更新は出来るからなー。
更新しすぎでエラーになってしまった
もうちょっと緩和してくれんかな
1IPあたりの制限とか、1アカウントあたりの制限とか、色々
クライアントの使い方を翻訳してくれるのはいいんだけど --standalone モードで
一度 httpd を落として 80番を落とさないといけないように書いてあるけど
これってやっぱ導入のハードル上げてると思うのよね
本家英語の使い方には --webroot モードで無停止でやる方法も併記されてて
この方法を知ってればもっと早く導入してたしさ
どっちにしろ総合的に色々煩雑な印象がして
無料の StartSSL でいいやってなってしまうわ
いつの話をしてるんだ？
2009年には主要3ブラウザで使えるようになってるぞ。
> 一度 httpd を落として 80番を落とさないといけないように書いてあるけど
> これってやっぱ導入のハードル上げてると思うのよね
>
> 本家英語の使い方には --webroot モードで無停止でやる方法も併記されてて
> この方法を知ってればもっと早く導入してたしさ
まったくだ。
そいでもって
> ちょっとシェルスクリプトのテストしてたら
> 更新しすぎでエラーになってしまった
とすっかり同じ状態。こまったもんだ。
人によるのだろうが、自分の場合は今までオレオレ証明書だったSTG環境やバックエンド用ドメインなので、
IP制限やBasic認証が掛かっているために設定を変更しなければならない
それならstandaloneの方が便利だし楽
一応それでgoogleとの暗号化通信はsmtpsもpop3sでfetchも成功したけど正しい設定か不安
サービスとしては無停止で再読み込みできる
httpd stop -> letsクライアント起動 -> httpd start より100倍マシ
nginx も reload で無停止再読み込みいけるんじゃなかったっけ？
それでよいと思うよ。openssl s_client -connect で大丈夫ならＯＫ．
ここは中間証明書は親切だね。
ｃｏｍｏｄｏなんか３ｔもファイル出してきてどれが中間ファイルだかわからなくて苦戦したよ。
結局3つを指定の順番でマージしろって。ならマージしたファイルよこせっての。
正しい設定かと言われるとたぶんNO
暗号化通信成功してるから結果オーライというならYES
httpd 側でデフォルトサーバーを用意して、mx のホスト名を httpd に定義しなければ
デフォルトサーバーに回るから、そのまま --webroot で更新行ける。
postfix やら dovecot とかにレッツのサーバー証明書を設定したりする人現れてるし
無駄無駄無駄無駄～って叫びたかっただけ
あ、イントラネットとかセキュアな通信が必須な相手で事前に合意した２者間とかはまた別だけどね
そこは “面白そうだから“ という正当な理由で Postfix や Dovecot にも Let's の証明書つかってるよ!
じゃ無駄じゃないね
考えてみれば当たり前の話なんだが
SubjectAltName にドメイン羅列するためにいっぱい -d を指定したら、
指定したドメイン１個１個に対してチェックのために接続してくるんだね
プライマリMX と セカンダリMX の証明書を１個にまとめようとしたら
let's Encrypt の居ない セカンダリMX の 80 番ポートにチェックしに来てエラーになって
しまった
-d でトップドメインが違うのでも良いの JP と gtld がごちゃ混ぜ
今見たら解説が更新されててhttpd停止不要なやり方も併記されたみたいだよ
ttp://https://letsencrypt.jp/usage/">ttps://letsencrypt.jp/usage/ >>145
いくつ書いてもおｋ
TLD が違っても良いけど、-d を複数書くとサブジェクトの代替名（SAN : Subject Alternative Name）が使われた1枚の証明書になるから、
SNI に対応していないブラウザ、例えば Windows XP とか Android 2系とかもサポートしたいなら注意が必要（Windows Vista以降はSNI対応）
詳しくは
ttps://letsencrypt.jp/docs/using.html#webroot を参照 おう
ありがとう日本語の中の人
SNI は1つのサーバーで複数の証明書を使う技術
つまり Virtual Host ごとに違う証明書をクライアントに放出するので、1つのIPアドレスのサーバで複数の証明書を分けられる
SNI対応ブラウザは、PCからなら Windows XP は不可だけど、Windows Vista 以上なら対応している
ttps://ja.wikipedia.org/wiki/Server_Name_Indication#.E5.AF.BE.E5.BF.9C.E3.82.BD.E3.83.95.E3.83.88 スマホがネックで、Android 2 系が対応していない。Android のうち、まだ 5～10％のシェアがあるので困りもの
一方、SANs は 1枚の証明書に複数の SAN を書くことで1枚の証明書を複数のドメインに対応させるもの
Let's Encrypt で -d に複数ドメイン書くとこっちになる（証明書を別々に発行して SNI を使うことも可能）
こっちは、たぶん Windows XP にも対応しているので、SANs使った方がサポートOSは多くなる
ただSANs については Android 2系が対応しているかどうかの情報は、ググっても曖昧に書かれた個人ブログぐらいしか見つからなかった
SNI と混同している人もいそうなので、確かなソースが欲しいが、なかなか見つからない
そして自分で検証しようにも Android 2がないからできない
これもちょっと誤解を招くレスだなぁ
https で VirtualHost するための技術・手段という意味では近いとも言えるが
どっちを使ったほうがいいとかそういうもんじゃないんだが
説明するのも面倒だ
> どっちを使ったほうがいいとかそういうもんじゃないんだが
概念的には全く別物だけど、「1つのIPアドレスしかない1台のサーバで、複数の HTTPS なサイトを運営したい」という一般的な要件なら
下記の (1) SNI でも (2) SANs でも、同じ結果が得られるわけで、どっちでも良いのでは？
(1) SNI で example.com にアクセスしているブラウザには example.com 専用の証明書A、
example.jp にアクセスしているブラウザには example.jp 専用の証明書Bを送り付ける
(2) example.com にアクセスしているブラウザにも
example.jp にアクセスしているブラウザにも
同様に SANs を使って複数ドメイン（example.com と example.jp の2つ）に対応した証明書Cを送り付ける
管理上のメリット・デメリットとしては、ブラウザの対応状況を除くと、
(1) だと、サイトの数だけ別々の証明書を取得して管理しなければならない。それぞれで有効期限などを管理するのが面倒。
(2) だと、サイトが増えるたびに、証明書を発行しなおさなければならない。失敗すると他のサイトにも影響が出る。
といった感じだと思われ
勿論、「概念的には別物」なので、SNI でサイトごとに SANs で複数ドメインに対応した別々の証明書を送るなんて併用も可能
www の有り無しと同一サブドメインのだけ SANs で1つの証明書でまとめて、あとは SNI で分けるなんて併用も一般的
つまり (1) と (2) を併用することもできるってことね
まぁ、なんらかの事業者が顧客のサイトを代理で運営している（もしくはレンタルサーバ業務をやっている）とかの場合には
他の顧客のドメイン名がSANsに入った証明書を使うというのはどうかと思うから (1) のSNI 一択になるけどね
> まぁ、なんらかの事業者が顧客のサイトを代理で運営している（もしくはレンタルサーバ業務をやっている）とかの場合には
> 他の顧客のドメイン名がSANsに入った証明書を使うというのはどうかと思うから (1) のSNI 一択になるけどね
と、思うじゃん？
でも身近なCDNでは(ry
ttp://uzulla.hateblo.jp/entry/2015/02/25/033133 
ttp://cdn-ak.f.st-hatena.com/images/fotolife/u/uzulla/20150225/20150225032705.png 他人のドメイン名がだぁ～～～っと入った証明書って気持ち悪いな
てか、これって秘密鍵が万が一漏えいしたら羅列されたドメイン名全部の偽サイトの作成ができちゃうんだから危険だよね
CloudFlare退会したとしても、そのSANsを消した証明書を作り直したりもしないだろうし
こういうのはやめるべきだと思う
よかったら、「blngs」で検索してみて！
SNSの宣伝ですか
今時、独自のSNS展開するなんていうのはセンスが無いからやめた方が良いよ
既存のSNS内でコミュ作ればいいだけでしょ
そんなのではアクセス稼げない 時代遅れだしセンスが無い
そして、この過疎版で宣伝して宣伝効果があると考えるのが痛い
「板」全体で1日数レスあるかないかのような掲示板で宣伝して何になるの？
この「板」全体のPVも数百/dayぐらいしか無いと思うよ？
悪い事言わないから、お前さんはネットビジネスのセンスが全くないんで、早く諦めた方がいい
時間が無駄になるだけなんで、サーバ運営、Web製作、Webプログラミングのうちなにかができるんだったら
それを生かした雇われの仕事探した方がいいよ
「口コミ」はその場にいる人に対してしか聞いて貰えないんだから「書き込み」と書くべきだ
「可視化」を「見える化」と言ったり「コミットする」だの「アボイドする」だの横文字連発した上で
「君もビジネス用語ぐらい使えるようになりなさい」と説教してくる上司と同じぐらいうざい
ここ Let's note のスレだったのね
すまそ
っておい
ワロタ
最近のLet'snoteの光学ドライブ普通になって特色なくなっちゃったよな……
色々面倒だと思ってたらコマンド数行打つだけで終わった
前ベリサリンで証明書取るときにはCSRの発行とかなんとかでつまずいて
（opensslのバージョン古くて鍵がちがかったりとかで）
何度も何度も何度も電話して2週間ぐらいかかったけどLet'sだと1時間足らずだった
証明書発行のプロセスに関する知識の無い人が凄い増えそうだ。
まぁ俺も勉強中で Let's Encrypt きたから途中で投げちゃったけどなｗｗ
お前さんにゃ無理かも知れぬ
ttp://livedoor.2.blogimg.jp/tunes2/imgs/3/2/32c50c49.jpg 悪魔バスター★スター・バタフライ
ttp://livedoor.2.blogimg.jp/tunes2/imgs/3/2/32c50c49.jpg 悪魔バスター★スター・バタフライ
ttp://livedoor.2.blogimg.jp/tunes2/imgs/3/2/32c50c49.jpg 悪魔バスター★スター・バタフライ
ttp://livedoor.2.blogimg.jp/tunes2/imgs/3/2/32c50c49.jpg 👀Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
ＶＰＳレンタルサーバーで使っていますよ。
httpもpopも色々なドメインが1の種類のファイルで済むので楽だね。
ttps://msnr.net/2015/12/letsencrypt.html ちょうど1時間ずれるのは、こういうもんなの?
それとも Let's Encrypt だけ?
書いたあとに自分でググった。
ttps://community.letsencrypt.org/t/time-zone-problem-with-issue-date/3151/11 あえて1時間ずらしてるらしい。時計が多少狂っていても大丈夫なように。
そもそも共用サーバじゃできないよ
何が出来ないのさ？
本当に知らんのか？
ttp://http://www.sakura.">ttp://www.sakura. ne.jp/news/sakurainfo/newsentry.php?id=1018 ttps://help.sakura. ad.jp/app/answers/detail/a_id/2326/~/ssl%E3%82%92%E5%88%9D%E3%82%81%E3%81%A6%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B つーか、お前👀
Rock54: Caution(BBR-MD5:0dc23c366b23c59a9fe320a62dd69b5a)
恥ずかしい奴だな
通報しておいた
Registrant Name: MASANORI ITO
Registrant Organization: MSNR.NET
Registrant Email: POSTMASTER@MSNR.NET
Created Date: Sunday, December 16th, 2001
Updated Date: Sunday, November 17th, 2013
Expires Date: Friday, December 16th, 2016
Admin Name: MASANORI ITO
Admin Organization: MSNR.NET
Admin Email: POSTMASTER@MSNR.NET
素直に知らなかったと認めれば良いのに、関係ない事にいちゃもんつけたあげく、
あまつさえ無関係なブログの人を晒すとか・・・
いくら公開情報だからって非常識すぎ
さくらのレンタルサーバーでも、Let's Encryptを使えるということですが、
でも、Let's Encryptって、動的に短期間で更新処理を行ってroot権限で再配置する必要があったんじゃなかったんですか？
のリンクを読みました。
更新処理用のマシン（root）を別途用意してますね。
でも、証明書のアップロードは手動なんですか。
90日ごとに手動でこの操作が必要なの？
デーモンを起動することを言っている？
ポート80で受けるならその時点ではrootが必要なのは当たり前、という話
わざわざrootて書いてるからさ
証明書の同期？crontab?
そして、RSYNCで？、FTP?、SCP?
疑問
１、証明書関係のファイルのコピー（同期）って、
さくらのレンタルサーバーでできるの？
やったことがないから知らないが、証明書って特定のディレクトリに収める必要があって、
そこの書き込みにはroot権限が要るんじゃない？
２、さくらのレンタルサーバーで、同期の手段って、どっちの方向へアクセスできる？
さくらレンタルサーバー → 取得専用自分マシン
取得専用自分マシン → さくらレンタルサーバー
>ポート80で受ける
？postで証明書ファイルを受けるの？それは怖いことだ。
仕組みもよく知らんで茶々いれてんじゃないよ
だったらその定義ファイルに証明書の場所書いてあるはずだし
そこがrootである必要はない
何を見当違いな話しとんや？
無料っていろいろと危険なんやなぁ
webroot モードで NFS で /var/www/～ を共有するか、manual モードでやるしかないっぽいけど
なんかもっといい方法ないかな
有効期限短いからcron自動化したいけど、各サーバーに lets クライアントを入れて回るのは嫌だな
rsyncで、マスターマシン内の証明書を、他のマシンと同期するとかは？
阿呆はさらに余計なことをしようと
バックのサーバ群はSSLしない
ただいろいろと修正がいるだろうけど
それが一番いいな
ttps://sslnow.ml/ 誰か試してみて
sha1RSA
CN = avast! Web/Mail Shield Root
O = avast! Web/Mail Shield
OU = generated by avast antivirus for SSL/TLS scanning
ttps://my.softbank.jp/msb/d/top TLS 1.0、RC4 / 128 ビット暗号 (高); RSA / 2048 ビット交換
TLS 1.0、Triple DES / 168 ビット暗号 (高); RSA / 2048 ビット交換
TLS 1.0、AES 128 / 128 ビット暗号 (高); RSA / 2048 ビット交換
TLS 1.0、AES 256 / 256 ビット暗号 (高); RSA / 2048 ビット交換
ttps://www.virustotal.com/en/file/7b6af39264f866465b0d68e0a57ba08bba6c28cb2b1f47e9f7b5767c017680be/analysis --manualするの面倒で別のFreeBSDマシンからsshfsして--webroot指定で取得したんだが
まとめるの面倒なのでやってないけど分かる人には分かるってことで。
なので、CentOSからでもsshfsいければいけるはず。
あとはコントロールパネルから手動でアップロードしないといけない点については
スクリプト書けばよさそうだけど、まだ書いていない。
ttps://letsencrypt.org/certificates/ より ECDSAが無料で体験できるのが待ち遠しいなぁ
RSAとECDSAのDual署名はopensslが対応しているのでapache他多数でも使えるハズ
自分のドメイン名を設定する意味がいまいちピンとこなくて。
そりゃ、アクセスされた時でしょ。
証明書に書いてあるドメイン名とアクセスしてるドメイン名が一致してますよって証明書だよ。
ありがとうございます。
クライアント側が、
サーバ証明書に記載されているサーバのドメイン名と、自分がアクセスしている先のドメイン名とを
照合しているってことかな。
なんか緩いなあと感じるが、
サーバ証明書は、第三者機関からデジタル署名を受けているんだよね。
でもそれって、含まれている公開鍵だけじゃなかったっけ。
その署名された公開鍵にも、サーバのドメイン名って含まれているのかな。
それなら、冒頭の、クライアント側でのドメイン名の照合には意味があるね。
letsencrypt-auto の中身みてみたらどうもpythonのvirtualenvが必須のようで、
しかも自動でgccとか触って欲しくないものを強制的に更新・インストールしようとしてくれちゃうのでさっき実行しかけて慌てて止めました
最低限不要なものをインストールしないで済むなら、少々.shなり.plなり書く労力は受け容れるんですが
letsencrypt-nosudoで、途中関係ない問題が出て手間取ったけどもあっさりできた
あとでこれ参考にcronで走らせられる完全自動化バッチか何か書くことにします
しかも、最初のドメイン名やメールアドレスの対話入力のためだけにTUIの環境が要求されるのは
なんじゃそりゃーと思った
CUIでいいじゃんね…
>クライアント側が、
>サーバ証明書に記載されているサーバのドメイン名と、自分がアクセスしている先のドメイン名とを
>照合しているってことかな。
YES.
もちろんその証明書の正当性有効性自体も。
>サーバ証明書は、第三者機関からデジタル署名を受けているんだよね。
YES.
>でもそれって、含まれている公開鍵だけじゃなかったっけ。
NO.
ttps://community.letsencrypt.org/t/list-of-client-implementations/2103 いつの間に・・・
大して話題が無いという…
できればweb鯖止めたくないなーと
最初にweb鯖止めないで公式蔵動かして繋いできたそれっぽいリモホのIP使えばええんやろ
cron の周期はどれくらい？
毎週？
最近のアンチウィルスソフトはSSL通信の監視も出来るけど
そのためにオレオレ証明書を入れてクライアントを騙したりするし
SSL通信の内容がアンチウィルスソフトメーカーに筒抜けになる気がして
機能OFFにしてるんだよなぁ
Let's Encryptの登場で今後不正サイトがSSL/TLS化されるって言われてるし、
監視しないと心配になってきたな
イタチごっこなのはわかるんだが。
以下ちょっと長い引用
>Let's Encryptは証明書を発行する前にGoogleのSafe Browsing APIを用いてドメインが
>悪用されていないか確認しているが、発行後の確認は行っていない。
>Trend Microのブログ記事では発行後にドメインの悪用が確認された場合、認証局が証明書を
>取り消すべきだと主張する。
>一方、Let's Encryptのサービスを提供するInternet Security Research Group(ISRG)の
>Josh Aas氏は発行後の取り消しについて、効果的でなく現実的でもないとしている。
ttp://srad.jp/story/16/01/10/1837213 そもそも現状の証明書の扱いに問題があるわけだけれども
証明書発行機関はインターネットの警察ではない
DV証明書はそのドメインと暗号化通信していることを保証するだけでそのサイトの善悪までは知らん
というのはエンジニアとしてはものすごく正しいことを言っているのだが
実際にインターネットを利用して被害にあうエンドユーザーには通じない
最終的にLet'sの証明書は信用できない、Let'sはウィルス、マルウェア被害を助長する悪の組織、
みたいにならなければいいけど
多数の人の中で証明書の正しさとSSL/TLSであることがごっちゃになってるし
example.com + www.example.com の証明書は取れても
それのサブドメイン sub.example.com は取れないみたいな制限あること多いよね
あとは親ドメインの証明書を他の人が取ってたらそれのサブドメインの証明書は取れないみたいなのとか
Let's Encrypt ってそーいう制限ないから domain shadowing と相性ピッタリなんだよね
domain shadowing
被害者を少しでも減らすためにもうちょっと対策考えるべきじゃね
義務じゃないけど努力義務的な感じで
トレンドマイクロから通報されてrevokeするのがそんなに大変な作業かね
ttp://nakedsecurity.sophos.com/2013/05/27/anatomy-of-a-change-google-announces-it-will-double-its-ssl-key-sizes/ この Web サイトで提供されているセキュリティ証明書にはエラーがあるため、
信頼しないでください。
セキュリティ証明書の問題によって、詐欺や、お使いのコンピューターから
サーバーに送信される情報を盗み取る意図が示唆されている場合があります。
まあむこうの考える理想としてそういうことをやってはいけないのだろう
現状を変えたいのだと
全くその通りだしめざしてるのはそれだろ
目的は単純な暗号化なんだから
DV証明書ってそういうものだろ、という、繰り返されたいつものやつ
なぜかといえばブラウザが緑になるせいでhttps＝安心安全と教育されてきたから
鍵マークみたいなのが出るのは昔からだが
まぁ鍵マークとURLを確認＝安全って教えられてるわな
緑に関してはもちろんそうだけどもEVとDVの違いをちゃんと理解して使ってる奴がどのくらいいるのかとね
↓
通信は安全だけど、サイト自体はフィッシングサイトかもしれない、ウィルス流し込まれたかもねー
って一般には理解できんと思うが、そーいう目的だと言われたらもうここの発行した証明書を
ブロックするしかないな
だったら、RapidSSL とかグローバルサインとか含めて、DV証明書全部ブロックしたら？
DV証明書っていうのはそういうもんだからね
言っとくけど、フィッシング詐欺やらウイルス配布やらに悪用されているDV証明書なんて山ほどあるから
Let's Encrypt を糞会社のトレンドマイクロが叩いただけで、それ以外の既存の大手CAのDV証明書だってフィッシングサイトなどに悪用されてる
サイトを信頼したいなら、その法的に実在している法人や団体が運営していることを証明している
アドレスバーが緑色になるEV証明書だけ信頼していればいいでしょ
文句いってるトレンドマイクロの方が明らかにおかしなセキュリティ会社なんだけどね
トレンドマイクロの「パスワードマネージャ」が、localhostでNode.jsを使ってHTTPサーバーを実行していて、
全世界から任意のコードを実行できて、記録されたパスワードも盗用可能という致命的な脆弱性があるという糞会社だからセキュリティを語る資格はない
てか、パスワードマネージャに HTTPD が入ってるとか、脆弱性以前にバックドアとしか言いようがない糞設計だよね
ウイルス対策ソフト自体も誤検出放置で信頼性皆無だし
ttp://it.srad.jp/story/16/01/14/0853225/ トレンドマイクロ叩きとかどうでもいいし
何ヒートアップしてんの
トレンドマイクロが危惧してるのは今回の domain shadowing の手法と
サブドメインだけで証明書を取りまくれる仕様の合わせ技って
ところじゃないかな
もちろん他にもそういうザル認証局はあるんだろうけど、Let's Encrypt は自動化しやすいし…
ほら、無職ニートとかが変態的犯罪を起こすと「犯人の自宅にはアニメのDVDが大量にあり…」
みたいな恣意的な報道されるじゃん？ あんな感じでさ
今回の件で Let's Encrypt が悪いとは思わないけど
今後 Let's Encrypt が悪者にされるのは心配だよね
公開鍵証明書という正式な名称使った方が誤解ない
それを区別するためにだな。。。
サーバー用公開鍵証明書、
クライアント用公開鍵証明書、
S/MIME用公開鍵証明書、
アプリ署名用公開鍵証明書
という正式な名称使った方が誤解ない
俺はそれがイヤだから無料の Let's Encrypt を使っているだけというね。
暗号化経路さえ確保出来ていればそれでいいよ。
暗号化とデータの保証では駄目なん？
今時大手CAもDV証明書売ってるし、フィッシングサイトが HTTPSに対応しているなんてのは今時当たり前（大手CAのDV証明書利用）であって、いちいちニュースにもならない。
ニュースになったとしても、○○銀行のフィッシング詐欺サイトがどうのこうのと注意喚起されるだけで、どこの証明書が使われたなんてのは記事にならない（実際どうでもいいし）。
ところが Let's Encrypt の証明書が使われたときだけ騒ぐというのは嫌がらせとしか思えない
大手CAと違って広告費払ってくれない非営利団体運営だから、叩きやすいんだろうね
一方、DVやってるジオトラストは、シマンテック・ベリサイン系列だから気軽に叩く訳にはいかんだろうし
自動化は更新だけで十分だよね
そんなことはジオトラストとかの大手DVもやってなくて機械的に取れるんだけど
だいたい、手動による認証ってなんか意味あるの？
証明書取得時だけ普通のサイトっぽくして、証明書取得後にフィッシングサイトに書き換えられたら終わりじゃん
もうちょっと考えてから書き込んだら？
i;;;」' __ __i
|;;| '・`, '・`{
(6|}. ・・ } 嫌なら使うな！
ヽ 'ー-ソ
ノ、ヽ＿/
/, ヽ
ト,.| ト|
電話やSMS確認でもするんか？
大概のことは自動化余裕だぞ
なにを？
ttps://support.microsoft.com/ja-jp/kb/931850 この Web サイトのセキュリティ証明書には問題があります。
ttps://www.knaw.nl/nl sha384WithRSAEncryption
TLS 1.0、AES 256 / 256 ビット暗号 (高); RSA / 4096 ビット交換
オレオレ証明書
Program Files\CSR\CSR Harmony Wireless Software Stack
cert_install.bat
@ECHO OFF
cd .
call certmgr.exe /add HarmonyTest.cer /s /r localMachine root
call certmgr.exe /add HarmonyNewTest.cer /s /r localMachine root
Harmony(Test).cer
HarmonyNew(TEST).cer
bluetooth
bluetooth追加後、証明書が書き込まれる。
ttps://www.ssllabs.com/index.html TLS 1.0、Triple DES / 168 ビット暗号 (高); RSA / 2048 ビット交換
kb3081320
WEPOS および POSReady 2009 のセキュリティ更新プログラム (KB3081320)
schannel.dll
ttps://my.softbank.jp/msb/d/top TLS 1.0、RC4 / 128 ビット暗号 (高); RSA / 2048 ビット交換
このページは表示できません
ttps://media.defcon.org/ sha512RSA
DigiCert SHA2 High Assurance Server CA
ttps://trinlink.tmfhs.org/EpicCareLink/common/epic_login.asp TLS 1.0、AES 256 / 256 ビット暗号 (高); RSA / 2048 ビット交換
時々現れる荒らしだからスルーな
(V) ヨドバシカメラのPC売り場に出かけて
|| 「嫌なら使うな」の腕章付けて販促活動して欲しいわ
受けること間違いなしwwww
./letsencrypt-auto: line 104: [: too many arguments
./letsencrypt-auto: line 106: [: too many arguments
Updating letsencrypt and virtual environment dependencies..../letsencrypt-auto: line 186:
/root/.local/share/letsencrypt/bin/pip: そのようなファイルやディレクトリはありません
CentOS5.11とpython2.6はあかんのか？
既存環境壊したくなければ、chroot環境作るとか
#言ってはみたが試してはいない
この制限って、どんな時に発動して、どうやったら解除？
使えないわけではない
最初はいちいちうざいけど crontab に登録してしまえばどうでもよくなる
他のクライアント使ってもいいし
ググってもよくわかんないんだけど
レジストラのアカハックしてサブドメイン作ったら
それを種に他のサブドメインの証明書も作れる
こういうこと？
www.yahoo.co.jpがあるとするやろ
ad.yahoo.co.jpを作ってそれを自分の鯖に向けて証明書を取得
そしてそこでフィッシング詐欺みたいな感じでユーザー情報GET
ttps://github.com/lukas2511/letsencrypt.sh ↑これでいけた
centosでコケた人はお試しあれ
> ad.yahoo.co.jpを作って
これどうやるの？
自分がドメイン乗っ取りやフィッシングなどの犯罪行為の方法をkwsk質問してる自覚ある？
攻撃方法を知れば防御もできると思うぞ
ttp://http://security.srad.jp/comments.pl?sid=676026">ttp://security.srad.jp/comments.pl?sid=676026&cid=2947587 に書かれている レジストラの垢をフィッシング詐欺その他で乗っ取って、DNSのAレコードを書き換える攻撃のこと
>>284
> ad.yahoo.co.jpを作ってそれを自分の鯖に向けて証明書を取得
その ad というサブドメインを yahoo.co.jp に追加するために、ヤフー株式会社が所持しているレジストラアカウントを乗っ取るのが
domain shadowing という攻撃方法
単なるレジストラアカウントの乗っ取りで合って、別に目新しい攻撃方法ではないけど
・メインのAレコード（@ や www）を書き換えないので、ドメイン所有者が攻撃に気が付きにくい
・ブラウザやセキュリティソフトは長年使われていた正規サイトのサブドメインのため、ヒューリスティック判定で詐欺サイトとして自動検出しない
ってだけ
その不正につくったサブドメインにLet's Encryptの証明書が使われたと大騒ぎしているのがトレンドマイクロだけど
色々ブーメランなことになったので、トレンドマイクロはそのLet's Enbcrypt批判の記事を修正した
Let's Encryptの証明書が使われるとか些細なことだな
別にレジストラじゃなくてもDNSサーバー乗っ取ればいいわけで
それ自体は昔からある手法
サブドメインをこっそり乗っ取るのが最近の流行
DNSサービスではなくて？
サーバ乗っ取れるならWEBサーバ乗っ取ればいい
そうすればSSLなんて取得する必要ない
なんせ本物のサイトが弄りたい放題なのだから
普通速攻気付かれて修正されておわりだよね。
コンテンツイジられようが配下ディレクトリになんらかのコンテンツ設置されようが
気がつかないと思うぞ
権威サーバー乗っ取られるのは、さすがに論外な気がする
サブドメイン型ホスティング使ってたら同居人に証明書発行されてるかも知れないと
さすがに仕様が悪いんじゃないか
アホは書き込み禁止で
だーかーらー
そーいう派手な乗っ取りをすると
の言うように気付かれやすいから
こっそりサブドメインを作って A レコードで別サイトに誘導するってのが
domain shadowing っていうのさ
これ以上反論したいならセキュリティ専門家とでも議論してくれ
んなもん分かってる
お前がいきなり
> 別にレジストラじゃなくてもDNSサーバー乗っ取ればいいわけで
> それ自体は昔からある手法
まるでアカウント乗っ取るよりサーバ乗っ取る方が簡単みたいな事言い出したから
i;;;」' __ __i
|;;| '・`, '・`{
(6|}. ・・ } 馬鹿は使うな！
ヽ 'ー-ソ
ノ、ヽ＿/
/, ヽ
ト,.| ト|
どんだけキチガイ多いんだよ。
LEは当該サブドメインの使用権しか確認してなくて
世間一般の認識ではサブドメイン用証明書はドメイン所有権確認してあるはずとなってるから
サブドメインへのHTTPS通信はドメイン所有者の責任があると認識されるが
が
LEはそう考えてなくて考え方のギャップでTMが因縁つけてるカンジか
これまでの考え方自体おかしいんでしょう。
存在確認とか、所有者確認とは別の仕組みにすべきって事の方が理にかなってるってのは誰にでも分かる事
世間の認識を歪めることになった元凶。
OVで始まった歴史的経緯があるからね
そこをすっ飛ばしたら議論にならない
あの警告出す事にオッケー出してる事にも疑問。
オレオレ証明書は、フィンガープリントの確認をしない限り、暗号化という意味でも安全ではないから
激しい警告を出すのは当然なんだが
例えば、安全でないアクセスポイント（クラッカーが運営）で無線LANを使っている場合、
オレオレ証明書のサイトを偽のオレオレ証明書に書き換え、www.example.com のサーバーへの接続を
クラッカーが運営するサーバへの接続（オレオレ証明書）に経路を書き換えることが可能
Let's Encrypt では二経路を改ざんしない限り、そういった悪用はできない。
証明書発行時にDNSのIP見てるので、
末端ユーザー ⇔ 無線LANアクセスポイント ⇔ ISP の経路だけではなく、
Let's Encrypt 証明書発行サーバ ⇔ DNSサーバ の経路も書き換えない限り、そういった不正ができなくなる
オリジナルのDNSサーバに毒入れできたら、Let's の証明書は取得できちゃうけど、それは困難
Let's の証明書取得時には、一般のユーザーが使うような毒入れ可能なDNSキャッシュサーバではなく
権限サーバに直接つないで照会かけてるだろうし
PKIの基礎学べば分かると思うけど、ユーザー（ブラウザ）が暗号化に使う公開鍵が
期待する通信相手のものであることが明らかでない限り、その暗号化自体が何の意味も持たない
つまり、ドメインの所有者・正規使用者の確認というプロセスを省略して単に暗号化だけにした場合（オレオレ証明書の場合）
その暗号化という行為自体が技術的に無意味になるのよ
何故かというと、単に暗号化するだけなら、通信を傍受・改ざんするクラッカーによって、正規の通信相手の公開鍵がクラッカーの公開鍵にすり替えられていたら
クラッカーが通信内容を傍受・改ざんできてしまう
Let's Encrypt のDV証明書は、ドメインの正規利用者の公開鍵であることを認証しているので
example.com というドメインを信用するならば、ブラウザのアドレスバーが
ttps://example.com/ で始まっていることとと ブラウザが警告を発しないことを確認するだけで、そのドメインの正規利用者と安全に通信できる
ってことで、「暗号化と所有者確認は切り分け」は、技術的に無意味（公開鍵のすり替えに対抗できない）のでやる意味なし
（公開鍵のフィンガープリントを電話とか郵送とか安全な方法で受け渡せば公開鍵のすり替えはできなくなるが）
Let's がやってるDNSベースでの認証は、安全な通信のために必要な最低限度の行為なので削ることはできない
オレオレ証明書を使ってるようなサイトをどうにかしようとなんて時間と手間の無駄だから誰もやらない
だから安全
その証明書をインポートしときゃいいじゃない
pip をアップグレードしろとか出てる
PIPなんて最初から入ってない。
前回は不要で今回から必要になったのか。
pip install -U pipさっさとしろよ
そのまま更新できた
ttp://askpc.panasonic.co.jp/info/160128.html CF-S8/S9/S10シリーズ、またはCF-N8/N9/N10シリーズ (新たな対象機種)
かなり古い機種も含まれているので、これで数年前のバッテリーが新品に蘇るぞ
パナソニックは神対応だな
……ところで、なんでこんな板にLet'snoteスレがあるんだ？
スレタイも読めない文盲乙
cronなどでの自動更新前提
レンタルサーバーだから自動処理出来ないってのなら、工夫すればできるはず。
ま、わからんならめんどい、って文句だけ言うしかないが。
これで一ヵ月毎とか２ヶ月毎に更新しとけば、短い有効期限も気にならないな
エラーになった時のリトライ考慮してないけど
まぁそん時は手動でいいや
証明書の有効期限 n 日前になったら更新させる
って処理にして cron で回す周期を数日おきにすれば
エラーがあってもまた数日後、次の実行時に処理出来る。
openssl x509 -checkend
これ使うと良いね。
この Web サイトのセキュリティ証明書には問題があります。
ttps://www.virustotal.com/ja/url/3a7f1e291d79d6ada135fe19e2153d723c165bbd019b4d66f70c9f973545caca/analysis/1454339116/ ttps://www.virustotal.com/ja/file/e68921ee4e47fe2a8b029df64dcd27d0cbc86e5b3fed78caf297a05a83b572c6/analysis/1454215745/ Qihoo-360 HEUR/QVM06.1.Malware.Gen
nProtect Trojan/W32.Chifrax.5
キモいな
SNI対応してないデバイス使うほうが悪い
まず、第一に、そのサイトの証明書を確認してみたが、サブジェクトの代替名が
DNS Name=ssl366616.cloudflaressl.com
DNS Name=*.2ch.net
DNS Name=2ch.net
となっている COMODO の DV証明書。
もう一度いうと、「COMODO」 の DV証明書なので、Let's Encrypt は無関係。
ついでに、その証明書はきちんと検証できるので、全く問題が無い。
ちなみに、その証明書自体は問題ないけど、2chはあちこちセキュリティガバガバなので全く信用できない。
例えば、jump.2ch.net は、
ttp://www.example.com/test.cgi?a=123&b=456#InPageLinkTest というリンクすらまともに処理できない
一応XSSは修正されたけど、エスケープ漏れに対して変なところで処理した結果、& を & に変換する処理が二重化されて二重エスケープでリンクが機能しなくなったり
ページ内リンクの # を処理できなかったりと、ガバガバ
そういうレベルのサイトなので、●のクレジットカード情報や個人情報漏洩したりとか、有料会員のパスワードがXSSやCSRFで漏洩したりとか、
レベルの低い問題を過去におこしまくっている
「＆ を ＆ａｍｐ； に変換する処理」とカキコしたら、HTML出力時に「＆ａｍｐ； を ＆ａｍｐ；ａｍｐ； に変換する処理」となり、
ブラウザには「＆ を ＆ａｍｐ； に変換する処理」と表示されるのが、適切なエスケープ方法だけど、2chは適切にエスケープするのではなく変な変換処理をかけているようだ
2chの有料会員になるときには、個人情報を一切渡さない方法（プリペイドカードや匿名ＶＩＳＡデビットなど）で、偽の個人情報で課金することを推奨する
荒らしはスルー
なんとかしちくりー
その後（発行された証明書をApacheでロードして接続テスト）が出来ないじゃん
ttps://community.letsencrypt.org/t/testing-against-the-lets-encrypt-staging-environment/6763 スクリプトの動作云々でそこまで求めるなら一週間またないとな。
更新処理のみに絞れば発行しすぎだろってエラーまで行けば制限外れれば更新は出来る。
気になるならログを見れば良いだけだし。
"Let's Encrypt certificate expiration notice"
Hello,
Your certificate (or certificates) for the names listed below will expire in 19 days (on 03 Mar 16 04:05 +0000). Please make sure to renew your certificate before then, or visitors to your website will encounter errors.
www.example.com
For any questions or support, please visit
ttps://community.letsencrypt.org/. Unfortunately, we can't provide support by email. 俺にも来たけど、サブドメイン足す前の物は間もなく切れるからだった。
3ヶ月って短いな。
ttp://www.symantec.com/security_response/writeup.jsp?docid=2010-021223-0550-99 大晦日に解散ライブを行い、フィナーレで照明を落とし
バイクに乗って森が登場して、キムタコに蹴りを入れて終了。
ゲーム 平安京エイリアン
荒らしなのでスルーよろしく
ワロタｗ
意外と賢い仕組みだわｗ
.
板違い（？）の上に、話をさえぎってしまいゴメンナサイ！(*_ _)人
でも、この板のユーザーさんにも有意義な告知かと思うのでカキコませてください。
★ 謝礼は十分いたします ★ アメブロなどのサイト制作ができる方！！
アメブロなどを使用してのサイト制作のできる方を早急に求めています！
私はリケジョやPC女子からはほど遠く、サイト作成にはまったく疎いのでとても不自由しています…(> <；)
そこで私に代わりサイトを作成してくださる方を求めてこの場をお借りしました。
■サイトの内容…
アダルト系、違法性、その他公序良俗に反するものではありませんのでご安心ください。
■サイト制作の仕様ベース…
アメーバブログで十分です。願わくばwordpressなどのブログ形式のサイトを希望します。
それに準ずるもので使い慣れたものがあれば別のものでも構いません。
■条件はありません…
技術さえお持ちでしたら、学歴・職歴等は一切問いません。
フリーター、ニート、高齢ニート、コミュニケーション障害をお持ちの方、引きこもりの方、中年失業者、長期無職等、歓迎！
■作業形態…
作業は在宅でやって頂くことになりますので、時間の指定は一切ありません。別のお仕事の傍らに…でもOKです。
■詳細をお知りになりたい方は…
下記メールアドレスまでご連絡ください。詳しく書いた返信文を差し上げます。
※真剣な告知です。冷やかしはご遠慮ください。
井 上
inoue1952w★gmail.com
迷惑メール対策のため＠部分を★にしてあります。
実際に送信する際には★を＠マークに変えてください。
.
.
> inoue1952w★gmail.com
> 迷惑メール対策のため＠部分を★にしてあります。
> 実際に送信する際には★を＠マークに変えてください。
はぁ？
お前の書き込み自体が迷惑メールだろｗ
問わないのはいいと思う。
だが歓迎しちゃいかんと思う。
永遠にβってやつ？
βとれてるよ
取れてないよ
公式見てみ
ttps://letsencrypt.org/ 「Get Started (Public Beta)」とある
パブリックβテスト中だ
ほんとだ、おっパブリックβだったね
ssしてれば見えるんじゃね？
ありがとうございました。
それを、squidのssl-dumpで使うことってできるんでしょうか。
これができたら、ブラウザにオレオレルートの登録が不要になると思うので、
便利だと思ったんですが。
ssl-dumpの場合、信頼されたCA証明書で動的にSSL証明書が発行されないとダメだし、LetsEncryptではCA証明書が払い出されるわけでは無いから無理じゃね。
レスありがとうございます。
ssl-bumpだと動的に作成した証明書を「自分でその都度、署名して自己証明書を新たに作成」しているってことですか。
ssl-bumpの設定段階には、さきにオレオレ証明書を作成することになっています。
そして、おっしゃるとおり、動作中は接続先サーバのドメインに応じて矛盾しない証明書を動的に作成するらしいです。
だとしたら、どうして、最初にオレオレ証明書を準備したんでしょうか。
自己証明の代わりに、Let's Encryptがその都度、署名してくれればいいんだけどなあ。
そういうスクリプトが提供されているのではないのか。
ということだろう？
「どうして」って、サーバ証明書を生成するのに必要だから作ることになっている
つーか、「LEがその都度署名」って、自分が管理しているわけでもないドメインも対象なんだろう？
そんなん無理筋過ぎる
ちょっと、おれおれ証明書と、おれおれ認証局とを混同したように書いてしてしまっていた。
おれおれ証明書は、おれおれ認証局によって署名されたものという認識で合うかな。
ところで、squidの組織がルートの通った認証局を構築してくれればいいのかな？
googleあたりがそういうのをやってくれないかな？
そんな証明書出すCAは瞬く間にCA証明書がブラウザから削除される
さようなら
スマホもPCも問題なくSSLになって喜んでたら
ウィルコムとauのガラケーだと証明書エラーで開けんかった…orz
ガラケーは諦めるか
sslのテストでA評価もらえるように設定したのでXPの古いIEも捨ててしまってるし
他のCAも今後新規発行はSHA-256強制となるから同様にガラケーではエラー
>ここで証明書もらって
これって、正しく言ったら、
自分で作成した公開鍵と自分情報に、ここで署名してもらって、証明書を作成してもらった。
ここで電子署名されるのは、公開鍵＋秘密鍵のハッシュ値？
それとも、公開鍵＋秘密鍵のハッシュ値＋自分情報？
> ここで電子署名されるのは、公開鍵＋秘密鍵のハッシュ値？
> それとも、公開鍵＋秘密鍵のハッシュ値＋自分情報？
両方不正解
認証局に送信されて電子署名されるのは公開鍵とCSRだけで、秘密鍵も秘密鍵のハッシュも認証局には送信されない
ttps://letsencrypt.jp/faq/#SecretKey 電子署名にはCAの秘密鍵が使われる（お前の公開鍵などをCAの秘密鍵で暗号化するのが署名）ので、電子署名作業はLet's Encryptのサーバでやる
電子署名後のデータ（お前が作成した公開鍵をCAの秘密鍵で暗号化したデータ）を
ユーザーのブラウザがCAの「公開鍵」で復号できたら正しい署名だとみなされる
何故ならば、CAの秘密鍵で暗号化したデータは対応するCAの公開鍵でしか復号できないわけで
CAの公開鍵で複合できたということはCAの秘密鍵で暗号化されたということになる ＝ 正規のCAによるデジタル署名ということになる
何の問題もないっしょ
1日1レスあるかどうか分からんような過疎スレなんだから
そうやって初心者排除していると、ただでさえ居ない人が更にいなくなって
便所の落書きどころか、廃墟の建物の壁の落書きになってしまうｗ
SSLに初めて手を出す人も多いでしょ
ってことだろ
解説というより解説サイトの紹介みたいな感じで
どうでもいいけどこのスレの勢いは3.8だ
うわべ位わかるようになるだろうに。
仮想マシンでアレコレやって「証明書はこうやって作られる」とまで自分自身で
学習できないようならこのスレ来ても意味ないと思われる。
テキトーにletsencrypt-autoコマンド叩いたら
いつのまにか証明書類が出来上がってて
ググって出てきたのをパクってテキトーにnginxに設定したら
自分のサイトがhttpsでアクセスできるようになっていて
すごいなぁと思った
細かいこと知ってなくてもコンセプト通り誰でも気軽にSSLできるね
Netcraft を名乗る bot から集中的にSSL接続が来た
本当にあの Netcraft の調査なのか、偽者なのかはわからんが
とりあえずブロックしといた
>認証局に送信されて電子署名されるのは公開鍵とCSRだけで、秘密鍵も秘密鍵のハッシュも認証局には送信されない
レスありがとう。
秘密鍵のハッシュもいっしょに、oreore認証局に渡されるって記事を、
WEBの記事で見たんだよなあ。ずっとさがしているけど、その記事が見つからない・・・
この下りは解釈の仕方だろうけど、認証局に送られて署名されるのは CSR (署名要求証明書) だけでしょ。
もちろん CSR の中には公開鍵の情報も含まれているから間違いでは無いような気もするけど誤解されそう。
> CSR (署名要求証明書)
まぁ、解釈の仕方で技術的な話ではないけど、CSR は Certificate Signing Request つまり署名要求なわけで、
「この公開鍵に署名してくださいねー」と認証局に送るための署名要求、つまり手紙のようなもの
で、認証局がやるのは、公開鍵に署名してその公開鍵がそのドメインに属することを証明することなんだから、
「認証局に送られて署名されるのは『公開鍵』」という説明が分かりやすくて合理的なのでは？
CSRは署名してください、っていう手紙に過ぎない
CSR (署名要求証明書) ってかいた括弧の中がおかしかった。これは訂正。
言っていることは分かるし伝わる。結果として署名された公開鍵がくるわけだしね。否定する所も無い。
つまり、考え方、合理性の求め方が人それぞれ色々あるんだなと感じた。
もっとも俺がおかしいだけなのかも知れないがｗ
CSR（含む公開鍵）が認証局に送られるけど、署名されるのは公開鍵だけっしょ
例えば、Let's EncryptのCAに下記のCSRを送ったとする
コモンネーム: 2cher-no-oresama.jp
組織名: 2cher Co LTE
部門名: BBS Service
市区町村名: Tubo-City
都道府県名: Osaka
国別番号: JP
公開鍵: 公開鍵情報グダグダと長文で列挙
すると、Let'sのCAはCSRの組織名・部門名・市区町村名・都道府県名・国別番号を全部無視（削除）して証明書を発行する
何故ならば、単なるDV証明書でドメイン名しか認証できないのでコモンネーム以外は無視・削除する（ジオトラストとかのDV証明書も同様）
ってことで、CAが署名するのはサーバの公開鍵だけだ
もしCSR全体を署名するとするならば、CSRの記載事項（組織名とか部門名）を認証局が改ざんできないことになるけど、
実際には認証局が勝手に変更したり認証していない項目を削除したりする
CSR に含まれる「公開鍵」に対し、DV 認証且つマルチドメイン対応だから CN 及び SAN の値以外を削除して署名する。
ということで。
大元に で俺が書いた引用部分
>認証局に送信されて電子署名されるのは公開鍵とCSRだけで
この部分への違和感は「署名されるのは公開鍵と CSR だけ」にあって、公開鍵は CSR に含まれるから
送信されるのは CSR だけでそこに含まれる公開鍵にのみ署名される
という事になる。
続きはPKI勉強会スレでも立ててそっちでやってくれ
誰でもみんな最初は初心者なんだから、多めに見てあげてください
スレ違いは他所でやれ
よく分かってないので質問させてください。
Google ChromeのURLの隣の鍵マークをクリックして接続タブをクリックすると、
「証明書の透明性に関する情報はサーバーから提供されませんでした。」
と表示されるんですが、解決策をぐぐるとApacheの場合はmod_ssl_ct、
nginxの場合はnginx-ctを組み込む解決策が出てくるんですが、
これは通常webサーバーのほうで対応する問題なんでしょうか？
ttp://news.valuessl.net/?p=1418 こういう有料のところのを見てみると証明書発行側で対応しているように見えるのですが。
つまりそのサイトを作った奴が信用できるかってことだからLet's Encryptの管轄じゃない
OV証明書やEV証明書なら出ないということですかね？
ということは、webサーバー側でモジュール組み込んだりして
対応しているのは本来の解決法ではないんですね。
SCTのdelivery方法は3種類ある
1) CAが証明書にSCTを埋め込む(X.509v3 extension)
これならweb serverに特に何か設定する必要はない。有料証明書のCT対応は基本これ
だがLEは証明書にSCTを埋め込んでない(し、そうする予定はないと明言)
2) web serverのTLS extension
つまりmod_ssl_ctやnginx-ct
なおLEはCT Log serverにsubmitはしてるから、ct-submitは必要ない
3) OCSP stapling
CAが対応しないとNGで、LEはいずれ対応するかも知れないが現状まだ
色々間違いすぎで知識が古い
分かりやすく説明ありがとうございました。
説明のおかげで解決策に納得できました。
現状では2)でしか対応できないということですね。
こういうのってどこで覚えるのか、素直に教えてほしい
① TLSサーバ証明書のemvedSCT拡張に含める
② TLSハンドシェイクのsigned_certificate_timestamp型TLS拡張に含める
③ TLSハンドシェイクのstatus型TLS拡張のOOSP staplingに含める
ググったところ、実際に対応実装があるのは ① のみ（それも対応ブラウザは Google ChromeだけI)で、
それ以外の方法は実装例がないそうだけど、②や③に対応している環境はあるのか？
貴重な情報サンクス
このスレにも神（本物のエンジニア）が居たようだ。。。
ttp://blog.tokumaru.org/2016/03/startssl.html 証明書取得時のWebフォームで、認証用メールアドレスのパラメーター（下記のDOM）を書き換えることで、
任意のメールアドレスでの認証が可能だったとのこと。
<input name=
<input name="ValidateEmails" type="radio" value="webmaster@example.com">
こういうWebアプリケーション製作の入門書にも載っているような低レベルな脆弱性があるとか、StartSSL は信用できん
やっぱ90日ごとの更新が面倒でも Let's Encryptの方がいいね
自動更新するようにシェル書いたらあと放置。
クライアントから送られてくるデータを信用してはいけないと、
教科書に書いてありますね。
残業だらけで寝不足になってくるとセキュアなコーディングなんて心がける余裕はなくなってくるんだよ
時間が無いと、オブジェクト指向どころか、関数にすべきところをコピペして一部編集してコーディング、
ググって適当にでてきたコードをよく読まずに無理やりつなぎあわせて、エラーが出た場所だけとりあえず修正して間に合わせ
とにかく急いで完成させるようになるの
勿論、プロなのでできる限り穴がないようにするが、ところどころ抜けるのはやむを得ない
睡眠不足で過労死するよりはマシだろう
一番のWebアプリケーションの脆弱性対策は、教育ではなく労働環境の改善だと思う
セキュアなコーディングのやり方をプログラマーが知らないのではなく、それに気を配る時間がないというのが現実
「美しいコード」「オブジェクト指向」「セキュアなコーディング」といった作者が拘りたいところに
時間を気にせずとことん拘れるから、場合によってはプロよりも良い物ができる
寝不足の中納期に無理やり間に合わせるような雑なコードとは違って、趣味のプログラミングなら
自分のやりたいペースでできるからね
スクリプトで回すから、一ヶ月毎に強制的に更新してればメール来ないんだろうけど
19日前と9日前にメール届いてる
なるほど
やっぱり隔月で更新でちょうどいい感じなのね
ありがと
Which host do you want to get a certificate for: m
Enter a host name: hogehoge.com
Enter a site path (the web root of the host for http authentication): d:\DATA\htdocs
System.ArgumentNullException: 値を Null にすることはできません。
パラメーター名:collection
場所 System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
場所 LetsEncrypt.ACME.Simple.ManualPlugin.HandleMenuResponse(String response, List`1 targets)
場所 LetsEncrypt.ACME.Simple.Program.Main(String[] args)
Press enter to continue.
とエラーとなってしまいます。どなたか解決策が分かる方はいらっしゃるでしょうか？
同じ事が起こった
一つ上のドメインにはアクセス来ないのに、
存在してないサブドメインに対するアクセスがあるね
とりあえず418返してるけど
Windows以外の環境で証明書作る
わざわざやりづらいWinでやる必要はない
毒入れ？
なんか狙われてるって？(笑)
418で草
ttps://www.google.com/teapot てっきり無効なステータスコードとしてエラーになるかと思ったら、
RFCで定義されたステータスコードだけあって、ちゃんと主要ブラウザでエラーにならず問題なく閲覧できるんだね
一部IEとかで404の時ブラウザ独自のエラー画面出すことがあるっぽいけど
普通は404でも403でも500でも何でもとりあえずサーバーから返されたHTML表示してるし
ttps://letsencrypt.jp/blog/2016-04-12.html ttp://gigazine.net/news/20160413-lets-encrypt/ -ne と != は違うから気を付けような！(笑)
板復帰(NG!:Gather .dat file OK:NOT moving DAT 592 -> 592:Get subject.txt OK:Check subject.txt 592 -> 592:fukki NG!)1.15, 1.04, 1.00
age Maybe not broken
参考になりそうなURL送っておきます
電磁波による拷問と性犯罪
ttp://denjiha.main.jp/higai/archives/category/%E6%9C%AA%E5%88%86%E9%A1%9E 公共問題市民調査委員会
ttp://masaru-kunimoto.com/ この方たちは集団訴訟の会を立ち上げてマスコミに記事にしてもらう事を目的に集団訴訟を被害者でしようという試みを持っている方達です
訴訟は50人集めてしようという事なのですが50人で訴訟をすると記事に書けるそうです
記事には原発問題を取り上げてテク犯被害を受ける様になった大沼安史さんらが取り上げて下さるそうです
大沼安史さんがテク犯に遭っているという記事
ttp://ameblo.jp/hilooooooooooooo/entry-11526674165.html 大沼安史の個人新聞
ttp://onuma.cocolog-nifty.com/blog1/4/index.html この方たちは電話相談等も受け付けている様で電話番号を載せている方達は電話かけ放題の契約をしていますのでこちらから電話して本人にかけ直してくれと頼むとかけ直してくれます
音声送信被害等を受けている「電磁波による拷問と性犯罪」の記事の水上さんは年金暮らしなので時間には余裕があるそうで宗教等に付随する集団ストーカー等の被害内容の話も聞いて下さいます
もう一人の電磁波犯罪には遭っていない国本さんという方は電磁波犯罪をしっかり理解されている方で年金暮らしの方なので長電話も大丈夫です
大沼さんはこちらのページからメールを受け付けておられる様です
ttp://onuma.cocolog-nifty.com/about.html 電話をかけたい場合は人によってはメールで電話番号を訊くと教えてくれると思います
この文章を見られた方は全文コピーをしてできるだけ多くの知り合いの被害者の方等にメールを送るなり被害者ブログに書き込むなりしていただければ大変有難いです
もし大勢の方に送る事が出来なければまだこの文章に触れていない知り合いの被害者に少しでも全文コピーで送っていただけるとその方が次の何人かの方に繋いで頂ける場合があり結果として大勢の方に見て頂く事が出来るはずです
ご協力よろしくお願い致します 👀
Rock54: Caution(BBR-MD5:f70dfdc711a7c6ae6accccb939f27fbf)
ttps://twitter.com/kohnosuke/status/686895442739634177 Windowsでやったことないけど、↓これ使ったら
ttps://github.com/Lone-Coder/letsencrypt-win-simple/releases 日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
日によっては複数回
は気にしないで
ttps://www.ssllabs.com/ssltest/ A+
おかしな挙動として判定されてテストが完走できないｗ
まず認証かけてて、一定回数以内にパスしないだけでFWでシャットアウトだから…
たまに自分も締め出されるｗｗｗ
confに許可する暗号と許可しない
暗号をずらずらかくと長たらしくてしょうがない
SSLCipherSuite HIGH:!aNULL:!eNULL:!MD5
SSLHonorCipherOrder on
これで十分やろ
ttps://mozilla.github.io/server-side-tls/ssl-config-generator/ confの見た目が汚くてなって直感的になに書いてあるか把握しにくい
というのはわかる
そこは自動生成したものを使うのでコピペではあるのだけれど
メールアドレスがアホみたいに大量に書いてある
こりゃオペミスで全アドレス流出ですかねwe've
余計な補完しなくていいのに
俺は晒されても問題ないアドレスでしか登録しないから別にいいけど
証明書の期限1日前まで放置しててもお知らせメールとかなかったし
今回のお漏らしメールも来てないし
ttps://community.letsencrypt.org/t/email-address-disclosures-preliminary-report-june-11-2016/16867 前代未聞というか、だいぶまずい気がするけどどう対応するんだろう
どうするってんだ？
別に問題はないけどどうするのかは気になる
SSL証明書なんだからドメインはだいたい公知、
ローカルパートは postmaster とか info とかその手のものなんじゃないの、普通。
途中で止めたから7200件くらい漏れたとか
どうやってアドレス変更するんだ。
むしろそれは問題だ
期限過ぎても仕様書が上がってこなかったせいで、程なくして企画ごとなくなったからへーきへーき
Ｆ
sudo yum update openssll 実行して sudo service httpd restart したら A+ になったわ
OpenVZのVPSだから、全体的にyum updateできないのよね
助かったわー n ∧＿∧
(ﾖ（´∀｀ ） Thanks!
Y つ
どのドメインをメインにしてどれをSNIにするか選べないのかしら
HSTSを有効にすれば多分A+になる
httpとhttpsで違うものが表示されるようにしてたらHSTSで酷い目にあったことならある。
今では反省してる
それに嫌がらせできる
そうそうそう言うこと
良さげなドメインゲット！→接続来ない(；´Д｀)
現役時代のアクセス層と跡地のアフィサイトのアクセス層が被る可能性は低い
ってことでpreload HSTSに登録しよう
そしたら全世界のChromeやFirefoxに効く
月極広告の広告主がリファラ取りたいと言ってきたときとか（HTTPS→HTTPはIEだと飛ばない）、
A8.net とかのSSL非対応のASP使いたいときとかに困る
結構リスク高いのでHSTSには慎重になった方がいいと思う、もちろんセキュリティ上は重要なんだけどね
時間0に設定すればいいだけ
アクセスするたびに時間更新されるしあくせすしないならそいつは相手する必要ないんだし
【Let's Encrypt、ほかのユーザーのメールアドレスを記載したメールをユーザーに送信】
ttp://security.srad.jp/story/16/06/16/0626258/ どっかの馬鹿CAみたいに秘密鍵漏えいさせたわけじゃないんだしｗ
ttp://tdrparkbgm.web.fc2.com/index.html クリックせずにスルーよろ
「東京ディズニーリゾートの音楽情報サイト|Tokyo Disney Resort PARK BGM Lists」
明らかに全く無関係
ただ単にクリックせず～って言われると本当に関係ないのか逆に気になっちゃうじゃないかｗ
ttp://internet.watch.impress.co.jp/docs/news/1008164.html > 今回の機能追加により、利用者はサーバー設定画面の
> 「SSL設定」から手軽にLet's Encryptの証明書を申請し、
> 発行および設定までを完了させることができる。
レンタルサーバー会社で初めてってわけではないみたいだが、
SSL対応の流れは止められないだろうし、管理者権限のない
レンタルサーバーでも導入できる環境が増えていくかな。
8割対応するけど、ごく一部のアンドロイドやSHA-2に対応したニンテンドー3DS
はIdenTrustのルート証明書がないが故にエラーが出るからなぁ
たかが3DSに対応する必要はあるんかというと、結構なアクセス数なんだよなぁ
ジオトラストのルート証明書を使用するRapidSSLのような有料証明書の方が3DSも対応するし
互換性でいうとほぼ完璧だから使い分けがいいと思う
それがだな、ゲーム系扱ってるせいか3DSからも結構アクセスしてくる
Let's Encrypt導入して4日後New 3DSで閲覧したら「証明書が見つかりませんでした」とエラー
吐いたから調べたらそもそも対応してなかったと聞いて、SSL化は断念したわ
あれ？理解してもらえなかった
お前みたいなヤツは世の中的には極少数だ
だから、一般人は気にせず導入して良い
ただ、「有料証明書の方が対応」というのは間違いで IdenTrust は有料証明書を販売しているかなり大手の認証局
あと、高い証明書の方が対応率が高いというわけでもなくて、クレジットカード業界の3Dセキュア認証ページなんかは、
古いブラウザの対応率が下がるのを懸念して EV SSL（アドレスバー緑のやつ）じゃなくてセキュリティレベルの低いOV証明書を使い続けたりもしている
調べたら3DSはルート認証局にかなり偏りがあってしかも少なく有料でも対応していないとこも多いね
ルート証明書のアップデートも事実上行われなくて放置だし、これは任天堂が悪いとしか言いようがない
任天堂は DS / DSi で 脆弱なWEP暗号を強要して世界中のWi-Fiのセキュリティレベルを下げたりと、問題が多すぎる
はっきり言って、任天堂の問題
数年後には3DSに入っているルート証明書の有効期限があちこち切れるので、弾かれる認証局はどんどん増えてくよ、任天堂はルート証明書のアップデートの面倒も見る気なさそうだから
3DSのゲーム攻略系サイトで、3DSのブラウザからアクセスできないとかは、ユーザビリティからして論外だろう
何よりもターゲットとなる環境でアクセスできる証明書を選ぶことが最重要
任天堂の糞ブラウザに合わせるしかない
さくらの長文野郎だろ！
3DSの攻略情報をスマホやPCじゃなくて3DSで見るの？
勿論大人も楽しむだろうけど、子供向けゲームソフトだってたくさん出てるし
普通は切り捨てると思うけどなぁ
ゲーム系で3DS切り捨ては有り得ない選択
（Google アナルティクスアクセス解析結果）
Chrome … 30%
Safari … 25%
IE … 10%
Android 標準ブラウザ … 8%
Nintendo 3DS Browser … 6%
Nintendo Browser … 6%
Firefox … 5%
Edge … 4%
Playstation Vita Browser … 2%
Safari (in-app) … 2%
任天堂系のブラウザが 1割以上を占めてるんだけど、これ切り捨てろと？
流石にそれは頭悪いと思う
そうですね
対応状況調べたりとか悩んだりとか格安業者探すのに無駄な時間を使うのもバカバカしいので、
明確に3DS対応している ジオトラスト クイックSSL プレミアムを3年分買いました
78,200円しましたが1カ月あたりにするとせいぜい2000円程度、AdSense+アフィ収入は月70万ぐらいあるのでこれぐらい痛くも痒くもないです
1. Chrome 65%
2. Internet Explorer 15%
3. Firefox 14%
4. Edge 2%
5. Safari 1%
3DS？何それ美味しいの？
続いて、以下より2つの中間CA証明書の（-----BEGIN CERTIFICATE-----） から （-----END CERTIFICATE-----）までをそれぞれコピーし、
3階層目を上に2階層目を下にテキストエディタに貼り付け、中間CA証明書ファイルとして任意のファイル名で保存します。
テキストエディタとか貼り付けとか言われても、専用サーバにTera Termで接続だと文字書き換えは簡単でもマウス使えないからコピペムズイ
テキストエディタがどうとか、Windowsサーバを前提にしてるのか？
どうやってインストールしたらいいかサポートに電話したら平日9:30-17:30じゃないと対応できないとか言われるし最悪
土日電話対応しないとかサービス業としてなってない
Let's Encrypt関係なくなるのでそろそろ退場しますがみなさん、ジオトラ○トはわけのやめたほうがいいです
Google Chrome 207,634
Firefox 24,388
Internet Explorer 6,042
Android Browser 4,572
Opera 4,313
Mobile Safari 945
Dolphin(Android) 411
Safari 751
UCBrowser(Nokia) 210
サポートに電話して聞かなきゃいけないほど無能だって自覚があるならそんなことやらなきゃいいのに・・・
これはひどいｗ
こんなヤツがSSL買う時代なんだね・・・
てかこいつはなんでSSLを導入しようとしてんだ？
GoogleのSEO対策のためだけか？
サイトによってそこまでブラウザが違うのか！
> サポートに電話して聞かなきゃいけないほど無能だって自覚があるならそんなことやらなきゃいいのに・・・
そんなにいうほど無能？
そりゃ、お前らみたいなパソコンオタクには勝てないだろうけど、文系の中ではパソコンできる方だよ
これでも専用サーバへのapache+php+mySQL+ワードプレスの構築は、Mysqlのインストール時にエラー出て鯖屋に遠隔でやってもらったのを除けば自分でできたんだよ
ただviはコピペが難しくて行数調べて 5yy みたいにうってpで貼り付けなきゃいけないんだけど
そのとき上書きされたり1行ずれたりしてなかなかうまくいかないしし、中間証明書の階層がどうとかと言われてもどっちが上からわからない
ジオトラ○トは、証明書の統合が必要なら最初からくっつけたのを送ってくれればいいし、コマンド1つで導入できるアプリとかを用意してほしかった
うん
IT系コンサルやってる知人に聞いた話ではPCからの検索だと順位への影響は1%程度だけど
スマホからの検索だともっと影響するらしい（Googleは広告強制注入したりする悪質なフリーWi-Fiスポットだらけの海外が基準でSSL推進らしい）
SSLだとA8のアフィ貼れなくなるけど、収入の大半がAdSense,Amazonアフィ,月極広告だからデメリットは少ないと考えた
リピーターよりも検索経由のアクセスの方が圧倒的に広告クリック率も広告クリック単価も高いしね
ゲーム機だとうちは一昔前PSPからのアクセスが結構あったな
viが難しいなら他のを使えばいいのですよ
Linux慣れてないならコンソール複数開いてnanoがいいんじゃないの？
ガラケーからのアクセスはどんなジャンルのサイトだろうと1%未満っしょ？
もう対応しなくていいと思う
あと3DSはどちらかと言えばスマホサイトに近いつくりで問題なく表示できるので
ガラケー向けよりスマホ向けコンテンツ（普通のレスポンシブデザイン）を配信するのが合理的
まあ、アクセスするユーザ数がふえるまではこのままでいいかな
実際、IdenTrustな環境なんてのは、3DS ・ Android 2 ・ Blackberry OS 10以下、ぐらいしか存在しない
XPのSP2以下で非対応なのはSHA-256非対応が原因だから別問題
ttps://community.letsencrypt.org/t/which-browsers-and-operating-systems-support-lets-encrypt/4394 Known not to work (based on
ttps://groups.google.com/a/letsencrypt.org/d/msg/client-dev/I-iFKihZ4Vo/kyw2EuaNlB0J1.4k) Blackberry OS 10, 7, & 6
Android 2.3.5 (HTC Wildfire S, Stock Browser)
Nintendo 3DS
Windows XP-pre SP3 - cannot handle SHA256 signed certificates
IdenTrustな環境 ⇒ IdenTrust非対応な環境
皆に迷惑なのでインターネットに繋がる機器を二度と作らないでいただきたいものだ
PSは新しい機種のくせに古いプロトコルバージョンしか対応しない欠陥品じゃんｗ
DSiはWEPじゃねーよｗｗ
な？
実質的にWEP強制だよ
【DSiのWPA対応がまるで意味を成していない件】
ttp://blog.goo.ne.jp/impreza98/e/b17140b653c27ac61366a134ab6c9262 うごくメモとブラウザのみの目的でDSiをWi-Fiに接続する人がどんだけいんの？
ゲームをネット接続しようとするとエラーが出るのでWEPにせざるを得なかった
Let's Encrypt の証明書と3DSのブラウザに互換性が無いというのは極めて重大な問題
Nintendoにルート証明書のアップデートを呼びかける必要がある
ttps://www.nintendo.co.jp/3ds/hardware/internetbrowser/list_pem_3ds.html 任天堂はルートCAの一覧をWeb上で公開していることだけは評価できるな
しかしIdenTrustは北米ではシェア結構あるのに、どうしてるんだろうか
大人は3DSのブラウザに期待していないし子供は何が原因だか判別できないからクレーム少なくてスルーなのか？
わかる。
だから「地味に」不便
相手側にやらせなきゃいけないしね……
JDKはバージョンアップ続けているんだから対応して欲しい
LINEのAPI試した人たちが阿鼻叫喚してた
そのためにごちゃごちゃやらなきゃいけない方がデメリットだ
というか、そんな一般的なこと言われて頭悪いとか反論してるバカさってどうよ
どうしてもそれが出来ない特定用途だというなら、そうかがんばれ、としか
未だに「一般的」でない古いIEへの対応どうするかなんて言ってるのに
個々のサイト運営を「一般的」かどうかで判断してもしょうがない。
1000万台以上普及してるんだから趣味のサイトならともかく
ゲーム以外の一般向けサイトでも影響について気にかけるのが当然だろう。
完全に無視してOKです
IE6サポートし続けろよ
ゲーム系じゃなくてもIE6ユーザーより3DSからのアクセスの方が圧倒的に多いんだけどね……
UserAgentだけ見るとIE6のアクセス結構あるけど、実態は単なるボット（メールアドレス収集とか掲示板にスパム投稿するボットとか）であることが多い
その証拠に、Apacheの生ログでは結構あるIE6のアクセスが、JavaScriptによるアクセス解析だと皆無になる
実際に仮想マシンにIE6入れて使ってみればわかるけど、GoogleやYahooを含めて大半のサイトがまともに表示されないから使い続けている人なんて現実的に存在するわけがない
勿論、ツイッターやフェイスブックもまともに動作せず
YahooもGoogleもフェイスブックもツイッターも見れないブラウザじゃあ実用上意味使い物にならないでしょ？
上記のサイトは3DSなら見れるので、IE6対応よりも3DS対応が優先なのは明らか
スマホ版やPC版はリッチでモダンなブラウザでないとダメだけどテキストベースのサイトは全てのブラウザで見れるので自サイトへの最低限のアクセス手段を確保
ガラケーサイトといってもテキストベースで超軽量なだけで普通のUTF-8なページだけど(UTF-8非対応なガラケーはさすがに捨てていいだろう)
let's encryptやモダンなTSL通信に対応してない端末も申し訳ないけどガラケーサイトで我慢していただく
SSLサーバー証明書の重要性と適切な証明書の選び方について
ttp://pub.sakura.ad.jp/event/160708/ さくらのセミナーはお菓子のおみやげくれたりクラウドクーポンくれるからお得感あるよな？
ってのは よりも更にレベルの低い人がターゲットだからな
root権限があるサーバの管理はもちろん、レンタルサーバすら自分で使ったことのない経営・営業関係の人が対象
このスレにいるような人は、間違いなく行っても退屈するだけだからやめた方が良い
たぶん、「アドレスバー緑だと安心感がありますね～ やっぱ EV がいいですよ～」とか言われるだけだろうな
EVとか銀行か政党くらいしか見たことないぞ。
> EVとか銀行か政党くらいしか見たことないぞ。
よっぽど観察力無いんだな。
お前らがアクセスしそうなところだと、
ttps://www.sakura.ad.jp/ ttps://twitter.com/?lang=ja とかもEV
某不倫サイトもEV
ttps://www.ashleymadison.com/app/public/index-jp2.p さくらのSSLなら、年5万円でEV取れるんで、商用サイトな取るのがお勧め
ttps://ssl.sakura.ad.jp/ githubはEVか。
任天堂への呼びかけはこちらへ
ttps://www.nintendo.co.jp/support/inquiry/inq01.html 導入までにかかった時間は、普段のサイト更新をやりながらの作業でしたが1日3時間×日曜日から木曜日までの5日間＝15時間 ＋ 電話かけて質問したりする時間 でした
さん、ありがとう
後で知ったのですが、認証局のサポートセンターではなく、専用サーバ業者の方に電話すれば、たいていのサーバ屋さんで1時間当たり1万円ぐらいでコンソール作業を代行してくれたようです
私の場合、自力で導入するのに15時間かかりましたが、プロなら1時間以内で通常インストールできるので1万円で証明書導入が可能だそうです
有効期限が3年の業者だったら、1万円払ってインストールしてもらえば3年使えるのでお得なので、最初から自力でやろうとせずにサーバ屋さんに依頼した方が手間がかからずよかったかもしれません
サーバ管理のプロではない一般人の場合、
・証明書は3年の業者から買う
・サーバ屋さんにコンソール代行でインストールしてもらう
というのが良さそうです
作業代行と証明書代って別じゃないの？
どこが自力なのかと小一時間
SSLの方がグーグルで上位表示されやすいんですよ
これはグーグルが公式で発表していることなので間違いありません
証明書がほしいのではなくhttpsやh2やりたい場合が多いでしょ
特にこんなサービスではね
それが不要なら格安系やLet'sのDVで十分
一般人は証明書の検証方法を知らないんだから（知っている人は1%も居ないだろうね、IE6のシェアより低いかも）、
今のブラウザのUI的にOVなんて中途半端で無意味
その他、日本語ドメインのサポートは8月31日までが11月30日まで、ECDSA中韓証明書サポートも年度末まで延期
ttps://letsencrypt.org/upcoming-features/ サボってるんじゃね？
このままドロンとか
お前の中ではな
まだ頭が眠ってるようで頭に入ってこない
結局何が変わるの？
ttp://knowledge.sakura.ad.jp/knowledge/5573/ Web鯖導入、ポート開放、証明書生成・参照、自動更新および
設定のバックアップまでの流れ。
エンジニア向けで10～20分の作業を想定しているので難易度は
低くはないだろうが、うまくはまれば15時間＋αの苦労を
せずに済むはず。
わざわざそんな手間暇かけて自分でやるとか、社会人からすると考えられん
そういう作業を自分でやるやつって、パソコン買うときも完成品買わずにBTOとか自作とかやるんだろうな
さくらなら、たった2万で「apache」や「Microsoft IIS」の
・SSL通信の利用に関するmod_sslのインストール
・CSR/秘密鍵の生成、
・証明書のインストール
を全部やってくれる
ttps://ssl.sakura.ad.jp/setup.html 勉強時間まで考えると外注に出した方が合理的だ
他にSSLのスレ無いんだしちょっとぐらいのすれ違いはやむを得ないんじゃね
この過疎板でSSL総合スレとか別スレ立てても殆どレスが付かず板汚しになるだけだしｗ
見てる人、みんな何かしらApacheとかphpとかある程度触った事あるイメージなんだけど
下手したらターミナル叩いたことない人もいるんじゃ・・・
昔はPerlとかphpとかでプログラミングする際にはローカルに実行環境用意する必要あったけど 今は普通にレンタルサーバでデバッグできるからね
現にVALUE SERVERとかさくらとかロリポとかで、cgi実行→エラー→修正→実行を数百回繰り返してもサーバ会社からクレームが来たりしないのでレンタルサーバとテキストエディタでphpプログラミングができる
プログラムが間違って無限ループしてプロセスが暴走したりしても、CPU使用率などがアカウントごとにきちんと制限・制御されているから他のユーザーに迷惑もかからんし、30秒とかで勝手にkillしてくれる
ちなみに10年ちょっと昔はそういうのは許されず、「他の利用者の迷惑になるので、開発段階のプログラムのテスト実行などにレンタルサーバを使用するな」とサーバ会社から警告メールが届いたりアカウントBANされた
当時はアカウントごとの負荷制御どころかSuEcecの導入すらままならず他のユーザのファイルにcgi経由でアクセスできるのが当たり前で、cgiが暴走したらサーバ全体のload average急上昇で大変なことになってた
その貴重なお時間を割いてまでこんなスレでレスバトルして下さるとは
>他にSSLのスレ無いんだしちょっとぐらいのすれ違いはやむを得ないんじゃね
自宅鯖板にあるからそっちでやれ
自作鯖板で専用サーバとかVPSにSSL入れる話とか、スレ違いではなくても板違いだろｗ
スレ違いも板違いも団栗の背比べだよ
自分で出来る奴はググってわからないところだけ2chで聞け
自作PCとか1時間も無くて作れるが？
お前はツクモとかドスパラとかの社員か？
何百台作ったらそんな早くなるんだ？
TLSの導入がhttpdの設定を含めて1時間でできるかどうかの方が重要
鯖とまともなネット回線とドメインくれれば一時間で終わらせられるわ
自己満足に浸りたのか？
確かにうちの鯖はCentOS入れてyum updateしたら1時間じゃ足りない・・・
意外な盲点だった
サードパーティ製のがいくらでもあるでしょ
CelM@1.46Ghz+256Mでつ
メモリ256MBって……
今時スマホですら3GBが当たり前だぞ？
サーバならCPUはXeon、メモリは最低32GB（普通は64GB）積むのが常識だろ
極限までデータベースをチューニングするよりも、DBとクエリキャッシュを丸ごと物理メモリに入れる設計の方が
開発人件費も節約できて合理的だわ
常識ってなんだろうな
スレチだからさっさと帰れよ
> 今時スマホですら3GBが当たり前だぞ？
一部のハイエンド機以外は2GBが一般的だしローエンド機では1GBもちょくちょくある
> サーバならCPUはXeon、メモリは最低32GB（普通は64GB）積むのが常識だろ
let's encrypt使う層とそんな化け物マシン使う業務層とはあんまかぶらないと思う
個人層の多いさくらVPSやconohaの1GBプラン同等が普及帯だと思うんですが
ラズパイや古いPCで自宅鯖もあるでしょうに
(釣られた?)
まあラズパイでもアップデートに1時間もかからんしメモリー256MBはさすがに卒業しないときつそう
> 常識ってなんだろうな
俺は社内でSEとして自社サーバの管理やってるし、転職3回もしたから広く業界全体のことを知っている
換言すると業界の「常識」を知っているのよ
そのうえで、ここ最近でメモリ32GB未満のサーバなんて見たことも無いので、メモリ32GB以上が常識だと書いているわけ
ttp://i.imgur.com/9CC0vpb.jpg はいはいそうですか
誰が業界なんて言ったんですかね
> let's encrypt使う層とそんな化け物マシン使う業務層とはあんまかぶらないと思う
> 個人層の多いさくらVPSやconohaの1GBプラン同等が普及帯だと思うんですが
なるほど、個人で使っている人もいるのか
弊社の場合、本システムの開発段階や、バックエンド鯖に導入してシステムの通信に使う証明書として使ってたから
個人が使う用途というのは想定してなかったわｽﾏﾝ
わかってて言ってるんだから相手する必要ない
自称業界人はすっこんでろって話です
今時物理サーバなんて流行らない
IIJですら専用サーバサービス終了するってよ
さっさと帰れアホ
お前は知らんかもしれないが、鍵ペアの生成とか検証にはある程度負荷がかかるもんだし
その過程の処理データはセキュリティ上の都合でSSD/HDDには保存不可（キャッシュやスワップ禁止）、揮発性メモリにのみおかれるように設計されているんだよ
一時的にでもHDDにスワップしちゃったら残留磁気などにより情報が漏れる可能性があるからね
勿論、完成した秘密鍵はSSD/HDDに設置されるわけだけど、それは話が別
おかれた秘密鍵はファイル単位で安全にワイプ消去が可能だけど、その鍵を生成する過程のデータの残骸をHDDにまき散らすのは不適切な設計なの
ってことで、Let'sのpythonクライアントがメモリが少ない環境で動かないのはやむを得ない
ん？俺は文句なんぞ言ってないぞ
こんな環境もあるって話をしただけでその話だした本人ではないし
最初はXAMPPのオレオレ証明書からはじめて、
この前EC2で初めてLet's~をいれてみた
俺環境の時にググりながら作った鍵ファイルとかと、手法が結構違うなーと思った
専鯖ユーザはラック借りるほどの規模じゃないんだからクラウドに巻き取るのもアリ
物理鯖が流行らないとまで言い切るのはおつむが足りない
一般人ごときが「アリ」だっておｗ
儲からない（流行らない）からサービス終了するんだよ
物理サーバはどんどん減ってる
現実を知らずに妄想も甚だしいわｗ
秘密鍵自作したい時ぐらい？
俺の客だと、ラックごと借りて、物理3台ストレージ2台で、その上に仮想4台が標準だから、
DCか現地に納品じゃなくて、仮想マシンだけ鯖屋から借りるって選択肢自体がありえないくらいだが。
鯖屋から同じ構成の物理サーバ借りる事は稀にあるけど。
ウェブなんかの安いシステムは知らんが。
物理鯖がなくなるなんて言われてたけど用途によると思う
?
秘密鍵は自分の側で作ってるだろ。CSRを送って署名されて返ってくる。
ぜんぶスクリプトがやってくれるが。
LetsでCSRを使う機会はないよ
ttp://qiita.com/TsutomuNakamura/items/e2e7be7c1f4d1638454d やっぱり今の所それぐらいですかね～。
ありがとうございました。
Internationalized domain names are not presently supported: example.コム
Punycode domains are not presently supported: example.xn--tckwe
質問スレを見つけることができず、ここへ投下させていただきました。ダメならすいません。
いくつかのデータセンターの専用サーバー(Debian/CentOS)には導入できたのですが、自宅サーバーで導入できず悩んでます。
他の質問サイトに投稿したのですが、回答がつかず、見かねた人が声をかけてくれたのですが現在お手上げ状態です。
ドメイン認証なので動的IPでも行けると思ってますが、固定IP必須ならその時点でアウトです。
●トラブル内容：自動でこけてるのでmanualでやっています。
# ./letsencrypt-auto certonly --manual --manual-public-ip-logging-ok -d #MyDomain# --server HTTPS://acme-v01.api.letsencrypt.org/directory
とりま、これで新規認証？を作りました。キーファイルを書き込めと出るので、ドキュメントルートに移動して
# printf "%s" sWwMGNwLSim# Keys here #TNWLCDSq67TvE > .well-known/acme-challenge/sWwMGN#Filename Here#Bi5yJhdTI
としました。その後、VPNで外部の環境からや、4G環境のスマートフォンなどから
#
ttp://#MyDomain#/.well-known/acme-challenge/sWwMGN#Filename Here#Bi5yJhdTI letsencryptで指示されているここへアクセスし、問題なく
中身である「sWwMGNwLSim# Keys here #TNWLCDSq67TvE」が表示されていることを複数の環境で確認しました。
しかしエラーで接続ができないといわれてしまいました。
「Failed authorization procedure. #MyDomain# (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to」
しかし、ルーターのファイヤーウォール記録にも、これへのリクエストと思われる記録はなく、(ファイヤーウォール切っても変わらず)
またサーバー側のアクセス記録、エラー記録にもこのファイルにも、アクセスしようとした記録がありませんでした。
このサーバーのIPは動的ですが記録上半年以上変わっていないので、DNSが反映されていないとも考えにくいなというところです。
何か思い当たる原因有りませんでしょうか。よろしくお願いします。
ttps://letsencrypt.org/getting-started/ 熟読しましょう
自宅鯖のOSくらい書きましょう
インストール
CentOSの場合
ttps://certbot.eff.org/#centosrhel7-other Debianの場合
ttps://certbot.eff.org/#debianjessie-other 証明書の取得
動いてるウェブサーバー止めて80と443が開いてることを確認したら
#certbot certonly --standalone -d example.com -d www.example.com
すいません、それで解決できればおそらく悩んでないです・・・ほんとすいません。
VPS(CentOS/Debian)や専用サーバー(WindowsServer/Debian/CentOS)で、同じドメインのサブドメインをいくつか登録していますが、そちらは何も問題なくLetsencryptのSSLを使えています。
なので違いは動的IPであり、ルーターを介している事、ぐらいかと思うのですが、ルーターにもサーバーにもアクセス記録は無く、
このドメインのDNS情報が正しく伝わっていないのではないか、と思うのが正直なところですが、他の監視サービスは問題なく監視されていて、それらのログは残っています。
OSはDebianです。
そのときにドメインがそのIPに繋がればいい
上位のルーターに何か問題があるのでは？
ルーターの設定をもう一度再確認してみます。
元々はGeoTrustのSSL証明書でSSL(443)でも平文(80)でもアクセスできる環境でして、
特にトラブルなく動いているためポート開放等も問題ないはずなのですが。。
原因不明すぎて悩みます。とりまもう一度ルーターの設定見直します。
すいません、煽りたいのは分かりますが、真剣に謎で困ってます。
Type: connection
Detail: Could not connect to
ttp://mydomain.com/.well-known/acme-challenge/#KEY FILE# と言われるが、外部接続テストサービスを使っても、私所有の他サーバーからcurlなどしても正常に開くことができるのです。
しかし、certbotは上記エラーを返すため、原因が分からない状況なのです。
日本語でOK
色々すいません、確かにそのドメインは相応しくなかったです
ttp://http://i.imgur.com/6MQH7CC.png">ttp://i.imgur.com/6MQH7CC.png (外部サーバーではOKの様子備考) とりあえずあまり一人で占有するのもよくないので一旦引こうと思います。
似たような事があれば経験されている方の俺もあった談が出てきてもおかしくないのですが、
出てこないという事は私の環境の問題で、何が悪いか見つけられていないだけ、のようなので、私宛の書き込みがなければROMります。
私宛になにか書かれていればすいません、書き込みます。
解決した際にはその油脂だけ投下しにきます。色々と申し訳ないです。
： 名無しさん＠お腹いっぱい。 [sage] 2016/07/31(日) 18:37:40.240
ところでドメインはIPv6のIP設定してる?(AAAAレコードある?)あったら外部からIPv6でもサーバーにアクセスできてる?
名前欄に数字突っ込むだけでもだいぶ整理つくのに
他の質問場所とマルチしてるくさいしいやだいやだ
やったほうがいいかもしれないがやらなくても全く問題ない
rate limitに引っかかってるのかなあ……
ttps://www.cman.jp/network/support/nslookup.html ssllabで見とけ
ssllabで見とけ
ノートンとverisignのマークが出るん？
こことは関係ない話
ここのssl入れると何がいいのさ？
も少し教えてくれよ。
別に俺はLet'sEncryptの営業マンでもなんでもないから
使いたくなきゃ使わなくていい
最近は社内LANアクセスだとSSLデコードかましてる企業が多くて、緑色バー(笑)の表示されないところも多いしびみょいような。
個人向けは依然として有効かもしれないけど。
シーマンのチェッカー、問題点が多すぎて迷惑なゴミチェッカーだから使わない方がいい
1つや2つじゃなくて、書ききれないぐらい問題があるゴミチェッカーで信頼性も低い
脆弱な暗号スイートの判定とかもおかしすぎる
悪いこと言わないから
ttps://www.ssllabs.com/ssltest/ 使え 確認方法は銀行に口座作る時みたいな感じでいいから
ホイホイ取れたらそれはそれで困る
本物というだけでなくEVSSLを取得できているという点の評価もあるわけだから
カルトへ向かう非難の矛先を逸らすこと。
国益に反することを言ったり、主張が食い違うもの同士の対立を煽ろうとするので放置し難いが、
主義思想についての洗脳を受けているわけではなく、フリをしているだけなので、
言い負かされてもダメージを負った様子もなく、論点をすり替えられるかスルーされる。
まともに相手をしてはならない。
まあどうせ大半の人は南京錠すら確認しないからいいかなとも思う
緑アドレスバーに「政治結社○○○○會[JP]」か…
逆にEV証明書は理論上暴力団でも取れる方が問題だと思うが
「六代目山口組[JP]」
「神戸山口組[JP]」
「稲川会[JP]」
「住吉会[JP]」
「五代目工藤會[JP]」
EVの審査はマニュアル通りに行われるから、取れるんじゃない？
それにEV証明書の目的は実在の組織とWebサイトの運営者を明確に関連付けることだから問題無し
ユーザーがその組織・団体を自分が信頼するかどうかを考えれば良いだけ
なりすまし対策に有効じゃん
「○○党○○県第○区選出衆議院議員 ○○○○[JP]」
「○○党○○県比例選出衆議院議員 ○○○○[JP]」
「○○党○○県選出参議院議員 ○○○○[JP]」
「○○党全国比例選出参議院議員 ○○○○[JP]」
「東京都知事 小池百合子[JP]」
「おおさか維新の会所属大阪府知事 松井一郎[JP]」
「東京都知事候補者 マック赤坂[JP]」
の方が理想的
確かEVは違った表示名は認められてないよね？
政治絡みはなりすまし防止の観点から個人でも認めた方がいい。
ttps://hogehoge.com uses an incomplete or invalid certificate chain. Check out your site at ttps://www.ssllabs.com/ssltest/ オレオレ証明書使うなｗｗ 嘘と思うならssltestしてこい
と怒られたんだけど(´・ω・`)
やっぱ互換性糞杉
ttps://hogehoge.com は不正な証明書を使ってるってどのブラウザでも表示されるぞ。 本当のドメイン書いたら低脳バレるし
そういうこと言ってるやつは質問者で遊んでるだけ
は良う分からんが
ケツの力抜けよとりあえずな。
例示には example.com 使う用にしような。
そもそも 実際どうなのよ？
現在opensslのs_clientを使用してクロスルートの検証をしています。
クロスルートが必要な古いルート証明書とクロスルートが不要な新しいルート証明書をそれぞれ別ディレクトリに格納してます。
それをCApathで指定してs_clientを実行すると、クロスルート利用はうまくいきますが、クロスルート無しはうまくいきません。
対象のサーバにはクロスルートと中間証明書両方入っている状態となります。
なお、同じディレクトリに新旧のルート証明書両方入れると、旧ルート証明書の方にchainされてしまいます。
opensslはバージョン1.0.1e Feb 2013を使ってます。
宜しくお願いします。
格安系SSLでもよっぽどいい加減な業者じゃなければ会員登録時に個人情報を求められるし、
支払が必要≒支払者の銀行口座・クレジット番号で明細に残る
提出用CSRにもチェック入る業者もある。内容が少しでも違ってたら発行しませんとかよくある。
格安系SSLでも悪用するには大きなハードルがある。
Let's Encryptはどうか？
発行枚数実質無制限、仲介業者なし、個人情報の提供なし、CSR不要（ファイル認証かDNS認証のみ）、
そもそも無料なため本人確認のしようがない。etc...
＋Torを使えば悪用し放題じゃね？
既に悪用されたケースがちらほらある。
ttp://http://security.srad.jp/story/16/01/10/1837213/">ttp://security.srad.jp/story/16/01/10/1837213/そのうち、Googlebotも証明書の種類で判定して、このサイトはそれ使ってるからダメだってなりそうな気もする。
： 名無しさん＠お腹いっぱい。 [sage] 2016/08/21(日) 19:47:24.790
> 格安系SSLでもよっぽどいい加減な業者じゃなければ会員登録時に個人情報を求められるし、
> 支払が必要≒支払者の銀行口座・クレジット番号で明細に残る
何言ってるんだか
その個人情報は全部出鱈目でも取得可能
「よっぽどいい加減な業者」がどこかは知らんけど、さくらのSSLのラピッドSSLすら実質匿名で取れるのを知らんのか
支払いも10万円以下なら、ATMから口座持ってなくても銀行振り込みできるし、振り込み名義は「ヤマダタロウ」とかいい加減に入力すれば弾かれない
誰が運営してるかがバレた時点でアウトなサイトでも取れるって話だろ
バージョンアップできないのよ。
認識が間違ってるわ
ドメイン認証の証明書は有料だろうが本人確認がない時点でLet'sEncryptと同じだよ
ドメイン認証は間違いなく消えてなくなる方向だよ
でも、同じように、高額のシマンテックの証明書とかは無くならないけど値段が下がるって事にはなるだろうね。
ttp://http://thehackernews.com/2016/01/free-ssl-certificate-malware.html">ttp://thehackernews.com/2016/01/free-ssl-certificate-malware.htmlFor a long time, malware authors purchased stolen SSL certificates
from the underground market and deployed them in their malvertising campaigns.
Fortunately, these certificates are eventually caught up and invalidate
by their legitimate owners.
However, with the launch of Let's Encrypt free SSL certificates,
malware authors don't even have to pay for SSL certificates anymore,
and can request one for free instead.
従来、ウイルス作者は不正な方法でSSL証明書を購入し、トロイの木馬付き広告を配布したがいずれも所有者によって無効化されている。
しかし、Let's Encryptのサービス開始でウイルスの作者はSSL証明書に金払う必要なくなり、更に自由に発行できるようになった。
犯罪者御用達SSL証明書、Let's Encryptｗｗｗｗｗ
こんな糞サービスやめた方がいい。絶対ｗ
： 犯罪者御用達 ぱよぱよちーん©2ch.net [sagete] 2016/08/21(日) 23:13:46.970
ttp://http://thehackernews.com/2016/01/free-ssl-certificate-malware.html">ttp://thehackernews.com/2016/01/free-ssl-certificate-malware.htmlFor a long time, malware authors purchased stolen SSL certificates
from the underground market and deployed them in their malvertising campaigns.
Fortunately, these certificates are eventually caught up and invalidate
by their legitimate owners.
However, with the launch of Let's Encrypt free SSL certificates,
malware authors don't even have to pay for SSL certificates anymore,
and can request one for free instead.
従来、ウイルス作者は不正な方法でSSL証明書を購入し、トロイの木馬付き広告を配布したがいずれも所有者によって無効化されている。
しかし、Let's Encryptのサービス開始でウイルスの作者はSSL証明書に金払う必要なくなり、更に自由に発行できるようになった。
犯罪者御用達SSL証明書、Let's Encryptｗｗｗｗｗ
こんな糞サービスやめた方がいい。絶対ｗ
： 名無しさん＠お腹いっぱい。 [sage] 2016/08/21(日) 23:28:48.680
ごく小さな代理店は。
SSLかかってたら安全なんて時代もとっくに終わってんだから、
無料だから濫用される、無料のがあるからうちのが売れない、とか言い訳探してないで、売る方法考えりゃいいのに。
・日本語ドメイン非対応（藁）
・たったの90日（藁）
・不正証明書作り放題（糞藁）
・不正利用されても無効化不可能（禿藁）
・ルート証明書はI'den Trustという無名認証局（禿藁）
・大手認証局が参入しないのは100%不正利用されるから（禿藁）
・犯罪の温床（寺藁）
・犯罪者御用達証明書（与太藁）
無料だからじゃなくて犯罪に利用されても無効化できない、
脆弱性だらけ、数十秒で作成可能とか
もはや外部攻撃された認証局と同じｗｗｗｗ
犯罪に利用されても、と言われてもなぁ。
そもそも認証じゃなくて、その名の通り、Encryptがメインだから。
そういう意味では認証局ですら無いだろ。
大手認証局がこう言う事しないのは、文字通り認証局だからだろ。
そら推せば良いだけなのに。
だから売れる物も売ることが出来ねえんだよなぁ、ボンクラって。
StartSSLでも同じようにできることなんだが、何言ってるんだこいつは
Let's EncryptでSSLを取得しようと思って何回か試したのですが、以下のようなエラーが出てしまい前にすすめません。
Detail: DNS problem: NXDOMAIN looking up A for hogehoge.mydsn.jp
DDNSのmydsn設定欄に何かしら設定をすればよいのでしょうか？
ちなみSSL化したい対象このサーバーはapacheリバースプロキシサーバーのバックエンドのサーバーです。
リバースプロキシサーバーに問題があるのでしょうか？
ご存じの方いらっしゃいましたらアドバイス頂けないでしょうか。
どうか宜しくお願い申し上げます。
難しいことせずに一旦80と443を取りたい鯖に向けちゃうのが早いよ
> mydsn.jp
とか夏の暑さで頭が逝っているのではないかと
向こうのスレの方には経緯をお伝えし、こちらで改めて質問させて頂きます。
DNS側でやることは何もないよ
普通にそのドメインでwebブラウザでページひらけるんだよね？
ttp://qiita.com/TsutomuNakamura/items/4166423699061e38d296 上記のサイトを参考に、順当に操作をつづけ
最後に
sudo certbot-auto certonly --webroot -w /var/www/html/owncloud -d hogehoge.mydsn.jp --email メールアドレス
のコマンドを打ちました。
環境としては、Windows2012R2のhyper-vで
・apacheでのリバースプロキシサーバー
・その配下に、apacheのwebサーバーを動かしています。
このwebサーバーをSSL化したいのです。
ちなみに、715さんがレスくれたように一旦、ルーターのポート80と443をwebサーバーに向けて、上記の操作を行ったのですが、
結果は同じでした。
またmydsn.jpってDDNSはあまりよろしくないんでしょうか？
何かご存じでしたら教えて頂けませんでしょうか。
>>freenom+cloudflareでラクチン管理&apiで自動化
ってちょっと調べてみたのですが、cloudflareがSSLを発行してくれると言うことはわかりましたがapiで管理と言う部分が
わかりません。
もう少し突っ込んでお話聞かせて頂ければ幸いです。
実際にサーバーを動かしているOSは両方ともCentos7になります。
ttp://hogehoge.mydsn.jp/ にアクセスして /var/www/html/owncloud/ の index読みに行ってる？
ログに残ると思うけど
cloudflareのDNS部分だけ使う
freenomで無料のまともなドメイン(example.tk等)がもらえるからそのネームサーバーをcloudflareにする
間違いなく操作しやすいからね
ddnsだとドメインごとの発行制限引っかかったりいろいろめんどくさいのでこの方法の方がいい
IP変わってもcloudflareのwebサイトで変えたら数分で切り替わってるし俺はそれがめんどくさいからその作業自動化してる
なあいい加減
mydsn.jp
に疑問を抱かないのか？
目見えてる？
思ったけど、それそのままなのかよ、まさかねえ
他の鯖ではうまくいったんですが、*****.mydns.jpのサイトだけ
Too many certificates already issued が出て証明書がもらえません
やはりダイナミックDNSでは使えないということでFAですかね？ぐぐってもわからなかった（取れてる人もいる）のですが
事実上無理ですよね、何度も試し続けて運良く取れてもまともに更新できないだろうし…
みたいにすればいい
ttps://publicsuffix.org/list/ 発行しない理由も明示され、あなたがそこに貼っているとおりなんだが…
DDNSで使えないのではない
1ドメインにつき発行する数に制限があり、mydns.jpはすでに上限に達しているということ
別途ドメインとって、それをDDNSで運用すればいいだけ
ベータの頃は、7日間に5回取得したらそれ以上取れなくなる制限あったけど
その上限未だあるんじゃないの
何回も取りなおしてない？
まあ数日経てばとれると思うよ
と環境によっては出てしまうけど、これはこういうもの？仕方ないのでしょうか
クライアントからアクセス時にそのエラーが出るってこと？
それはサーバソフトでの中間証明書の設定ミス以外考えられない
Let's Encrypt Authority X3 は IdenTrust からチェーンされてるはずだから、
「IdenTrust が信用できない」というエラーが出るならともかく「Let's Encrypt Authority X3 が信用できない」
なんていうエラーは出ないはず
ある一つのクライアントを除いて出ていないので、そのクライアントがおかしいのかなと思ったのですが
それもおかしいよな
でも鯖は普通にcert.pem, privkey.pem, chain.pemをApacheに読み込ませてるだけなので間違いようもないし
chain.pem を読み込ませているなら問題ないっぽいね
中間証明書を読み込ませないと、クライアントによってはエラーが出たりでなかったり不安定になるが
ttps://www.ssllabs.com/ssltest/ ここの結果どう？
Bになりました
特に致命的な問題はなさそうに見えますが
エラー出てないなら問題ない
クライアントがクソなんだろう
・Chrome49＋chainなし：証明書エラー
・Chrome52＋chainなし：OK
こんな感じだった
で調べれば？
新しいの作ってweb鯖側の設定まだ変えてなかったらエラー出てweb鯖起動できなくなったりする
上限まで使い切りたい
日に何度もアップデートあったし
EV証明のないサイトなんて
使う顧客は自分と関係者だけだからEV証明もいらん
いや、それはないだろ
それなのに余計な警告出されるのがクソウザイ
ttp://security.srad.jp/story/16/10/22/2318250/ 互換性の観点から言うと格安系より少ないし、特に法人向けでは需要がある。
その格安でサポートが受けれるかという疑問もあるがｗ
私の職場ではローカルアドレスのサーバーがあってこれのSSL証明書はブラウザで警告でなきゃ何でもとい。
Ｌｅｔｓは公開サーバー建てないと取れないから1000円程度の格安使っているよ。
つかローカルならSSL使う必要性すら無い気もするが、
社内のネットワークを管理してる人間すら信用ならないって事なのか？
社内にミラー鯖立てててそっから更新するんじゃね
テスト環境だけと本番と同じようにSSLで通信させたいとか色々あるだろ
推測で言っただけですはい
社内向けのドメインなら格安で取れば簡単か。
なるほど！
yahoo検索が常時SSL(常時HTTPS)となった模様
ttp://fast-uploader.com/transfer/7033455998374.PNG?key= 新しいプロトコル作ったのかよ
中華系は共産党の検閲絡みだからか？
一方、セキュリティ？何それおいしいの？の日本や韓国はスポンサーにならないだろう多分ｗ
ttps://www.generosity.com/community-fundraising/make-a-more-secure-web-with-let-s-encrypt できるの?
できんのだけど。。。
開発版インストールでできました。
ありがとう！
ttp://upup.bz/j/my44020gUjYtVhx-H5xOfQw.jpg 今年の11月からNEVERまとめが常時SSL(常時https)化
ttps://matome.na-ver.jp/odai/2147927345093318201 「Neverまとめ」が常時SSL化（WebサイトのHTTPS化）に対応へ - NAVER まとめ
ttps://www.wan55.co.jp/column/detail/id=390 Wikipedia「政府の検閲に対抗しデフォルトをHTTPSにする・・・特に中国、貴様だ」 [転載禁止]©2ch.net
1 : ネックハンギングツリー(家)@転載は禁止:2015/06/13(土) 22:12:29.34 ID:+n0FFgyp0 ?PLT(12345) ポイント特典
WikipediaなどWikimedia FoundationのサイトがデフォルトでHTTPSを採用…政府機関による検閲などを抑止へ
ttp://jp.techcrunch.com/2015/06/13/20150612the-wikimedia-foundation-turns-on-https-by-default-across-all-sites-including-wikipedia/ Wikipediaなどの重要なwikiプロジェクトをホストしているWikimedia Foundationが今朝(米国時間6/12)、
今後はすべてのサイトのトラフィックをHTTPSにより暗号化する、と発表した。同団体によると、
これにより各国の政府などがユーザトラフィックをモニタすることが困難になり、
またISPがWikipediaなどの記事を検閲することも難しくなる。
同団体は2013年に、サイトのアカウントを持つログインユーザのトラフィックに関してはHTTPSを実装したが、
そのとき、中国やイランなどトラフィックのHTTPS化が難しい国に関しては、
ログインユーザに対しても従来どおりのアクセスを認めた。
しかし今日のWikimedia Foundation(WF)の報告では、同団体はHTTP Strict Transport Security(HSTS)を
使用して、トラフィックをHTTPS破りから保護する、と言っている。
(略)
今日WFが発表した談話によると、"中国ではここ数週間、中国語WikipediaはHTTPとHTTPSの両方で、
多くのユーザにとってアクセス不能になっている。しかし、香港や台湾など一部の、
アクセスできているユーザにとっては、HTTPSがセキュリティの向上に資すると思われる。
また、中国でも英語版Wikipediaにはアクセスできるので、英語版の利用に関しては、
ユーザはHTTPSのセキュリティ効果に浴することができる"、ということだ。
(略)
【HTTP/2】常時SSL化について語ろう【TLS1.3】©2ch.net
ttps://matome.na-ver.jp/odai/2147714935661573701 ttps://matome.na-ver.jp/odai/2147565496820672501/2147565617221932203 itest.2ch.netもSSL化
【アットウィキ/atwiki】@wikiについて語る Part 16 [無断転載禁止]©2ch.net
証明書の更新などの作業の増加
ページ内で読み込めるスクリプトとか画像に多少制限がかかる(安全じゃない接続のは読み込めない)
一部のライブラリを古いのに入れ直すの面倒でギリギリまで待ったかいがあったｗ
個人＋高い互換性：RapidSSLとコモド(1.5千円)かFujiSSL
法人・団体：RapidSSL・ジオトラストクイックSSLプレミアム・OV証明書全般
法人（金融取引・通販以外）：EV証明書全般
法人（金融取引・通販等）：シマンテックEV証明書
こんな感じかなぁ
クイックSSLベーシックなるものはRapidSSLは値段は5倍以上する上、機能面では全く同じでメリット皆無
ttps://www.ssl-store.jp/geotrust-quick-ssl-basic/ SSL証明書によって検索結果が優遇されることってあるなら話は別だけど
今に限っては古いブラウザから閲覧できなくなるのと、HTTP接続のは読み込めないくらいじゃね。
SHA-1しか対応しないかSSL3.0まで対応するブラウザは全滅（特に2kとかサポート切れのOSはほぼ全滅）
そのうちTLS1.0も使用禁止になって、ガラケー全滅するかもしれない
パフォーマンスの低下もAES-NIやECDSAのお陰で殆ど感じないし、HTTP/2を使えばむしろ速いほう。
外部がいいならGoogleで十分だわ
No renewals were attempted. と出て更新されない。何がおかしいのでしょうか？
CentOS6です。ログにはDEBUG:certbot.renewal:no renewal failuresと出てます。
確かにHTTPS→HTTPではRefererが送られないけど、今時アクセスランキングのようなAPIがHTTPS非対応ってほとんどなくない？
だって、そのランキングシステムがHTTPSなサイトでまともに機能しないわけで、そんな状況放置するのは普通じゃない
一応、htmlに
<meta name=
<meta name="referrer" content="unsafe-url" />
って書いとくと、FirefoxとChromeだと HTTPS→HTTP でもReferer送られるようになるよ
IEには効果ないけど
>昔ながらの
って書いてるんだからhttpsなサイトなんて対象外なんだろ
HTTPSに対応することで、アクセス解析したときにHTTPSなサイトからのリンクされたことが分かるってメリットがあるよ
もしHTTPだとHTTPSなサイトからリンクされた場合に、Google アナリティクスとかのアクセス解析でも表示されなくなり、
ブックマークとかからの直接アクセス扱いにされるよ
with2.netなど他の所は非対応のまま
ランキングは投票URLが touhyo.cgi?siteno=000 みたいになってると?以降が暗号化されてカウントされないね
たまたま検索結果画面のHTTPS化とタイミングが重なったから誤解している人多いけど、
Google検索のRefererがとれなくなったのは、Google側がプライバシーにかかわるキーワードをサイト側に送らないように対策したから
技術的には検索結果をクリックした際に、特殊なスクリプトを含むリダイレクタを経由するようにして、そのリダイレクタのURLしか取得できないように対策した
キーワードはGoogle Search Console からとるしかなく、数の極端に少ないキーワードや個人情報を含む恐れのあるキーワードは取得できないようになっている
ttps://github.com/analogic/lescript このスクリプト使ってるんだけどちゃんとtoken見に来てくれない
ブラウザでアクセスすれば普通に見えるがアクセスログに自分とGoogleのBot以外出ておらずアクセス制限なんかもしてない
何か原因思い当たるのありますか？
それと他にphpだけで認証できるようなのありませんか？
何ヶ月も気付かなかったわ
終わったのは標準ブラウザってやつ
古いバージョンか？
Win7＋IE11,Chrome、Win10＋IE,Edge,Chrome、iOS＋Safari,Chromeは問題なかったが、
Android 7.1(Nexus5X)＋Chromeの55かな？で「このサイトは信頼できません）になった。
最新の中間証明書に入れ替えたら問題なくなったから、そういうもんだと思ってたんだけど。
ググるとAndroidでだけ証明書エラーってのが何件か引っかかったし。
ttps://letsencrypt.jp/faq/#Browser の > 過去に使用されていた中間証明書「Let's Encrypt Authority X1」と、予備の中間証明書「Let's Encrypt Authority X2」は Windows XP との互換性がありませんでした。
> 2016年03月25日以降は、Windows XP との互換性が高い中間証明書「Let's Encrypt Authority X3」、および予備の中間証明書「Let's Encrypt Authority X4」が使用されています。
あたりが影響してるんじゃない？
2016年3月25日に中間証明書が変わったらしいので、3月25日以降に取得した証明書は、それより古い中間証明書だとエラーになるかもしれん
中間証明書はブラウザによっては勝手にキャッシュする（証明書ストアに勝手に入る？）から、自分がエラーでなくても他の人がエラー出たりと検証が困難
なので、
ttps://www.ssllabs.com/ssltest/ でエラーが出ないか確認した方が良い ありがとう。XP云々との関連は分かんないけど、時期的には同じ感じなので何か関係あるのかな。
検証するにも環境に限りがあるから、そういうサイトも活用する方がいいね。
自分はSymantec Encryptなんちゃらいう検証サイトで見てみたわ。
sslabs.comでエラー無いんだけど、スマホでクロムで警告画面でて使えねーという
ひとが複数出ちゃう。
さてどうしたものか
ttps://youtu.be/quIHgwuF6r4 おしっこを出せと命令されたのにかわりに茶をだしたASKA
与党議員を盗聴している、本省の課長級以上の国家公務員の私邸を盗撮している、と言って
日蓮上人の正法を護持し、日本の真の国主であり平和の王者である池田先生と創価学会をネットで誹謗中傷していた奴ら、
おまえらは、全員ASKAと同じ精神障害ということで警察官に逆らう詐欺師と言う事にこれではっきりとなった。
警察官の３割強はわたくし達創価会員で占められている。
ASKAは必ず再逮捕され、拘置所内で自殺と言う事で間違いなく処理される。
おれたちは絶対負けない。
創価の敵対者達も必ず仏法の力で破滅する事になる。
ASKAの味方をする奴は全員統合失調の薬物中毒者と言う事にもうすでにもうなったんだから、
おとなしく観念しろ。
創価が与党議員を盗聴している、本省の課長級以上の国家公務員の私邸を盗撮している、
という疑惑を流している奴らも同罪ということになる。
池田先生は魂の指導者で日本の国主なのだということは、
全世界が認めていることなのだから、
もし仮に公務員や一般国民の生活をご照覧になって指導されたとしても
それは当たり前のことだ。
このスレにそんな馬鹿は居ないと思うがASKAに肩入れして警官や盗撮の悪口を言ってるやつは
IPアドレスから住居を突き止めて六道地獄を永久に廻る仏罰をくだしてやる。
内容はともかく、ここは Let's Encrypt のスレなんで、無関係な政治や宗教の主張はやめてくれないかな？
他にSSL/TLSのスレはないんで、他の認証局の話題ぐらいならいいけど、流石に政治はスレチすぎる
表現の自由が保証されているとか思ってるかもしれないけど、無関係なスレッドでの主張は反感を買って逆効果になるだけだよ
そしてそれらの内容を全世界に夢か何かで知らせるくらいできないと本物じゃないよね
こんなスレに書き込んでる時点で(笑)
ある程度年齢層の高い板は大体そうだよ
なぜスルーできないの？
Let's Encrypt使ってる商用サイトは詐欺と思えでおｋ？
ttps://www.gourmetmpic.com 10年じゃないとダメだのCOMODOはありえないだの
気にするからお前次第だ
お前の考え方が糞過ぎ
全然おkじゃねーよ
もっと勉強してこい
むしろDV証明に何万も出しているサイトの方が情弱で怪しいのでないか
そういうところを見て「怪しいな」って思う人はそもそも相手にしてないから大丈夫
それで使ってるサイトがとか言うのはアホかとしか思えない
だって高いところは単純な証明書ではなく信用を売ってるんだもの
その認識が正しくないから袋叩きにあっているんだと自覚しようか
ttp://echo.2ch.net//test/read.cgi/esite/1485225798/3-n?v=pc
【アットウィキ/atwiki】@wikiについて語る Part 17 [無断転載禁止]©2ch.net
3 : 名無しさん@お腹いっぱい。2017/01/25(水) 02:08:31.60
ttps://atwiki.jp/news/116 いつも@WIKIをご利用いただき誠にありがとうございます。
@WIKIサポートです。
以前より、https対応につきましては、お知らせさせていただいてますが、
@WIKIはhttps化を完了し、現在、http/httpsいずれも接続が可能になっております。
この度、さらなるセキュリティ強化対策として、
2017年1月30日午前10時を持ちまして
常時SSL化 (httpsのみによる接続) を適用させていただきます。
～～～～～～～～～～中略～～～～～～～～～～
なお、本件実施に伴い、現行のhttpsに非対応である一部の古いバージョンのブラウザやサポート終了のOS、
フィーチャーフォン(いわゆるガラケー)等につきましては、ご利用いただくことができなくなります。
大変恐縮ではございますが、現行のスマートフォン・OS・ブラウザ等をご利用いただくようお願い致します。
信用のためならDVじゃなくEVにしとけよ
ttp://ameblo.jp/staff/entry-12247397187.html アメーバブログの常時SSL化に伴う仕様変更について ...
ameblo.jp › staff › entry-12247397187
14 時間前 - 常時SSL化以降、ご利用可能なプラグインについて ... のハッシュタグ入力とテーマ設定の変更について · 【おしらせ】PCの最新版エディタにて一部改善のお知らせ · 【おしらせ】絵文字を追加いたしました。
webroot で、証明書ゲットして、apache, postfix, dovecot にインストール。うまく動いている模様。
あとは自動更新なんだけど、cron に
certbot renew --quiet --post-hook "service apache24 reload ; service postfix reload ; service dovecot reload"
で、いいのかな？
いちおう、--dry-run と --force-renewal でテストしたらうまくいっているみたいですが、
よく分かんないのが証明書の取得回数制限。
ttps://letsencrypt.org/docs/rate-limits/ １．１週間に２０ドメインまで
２．１週間にサブドメインは１００まで
３．同じドメインの更新は１週間に５回まで
４．あと、ひとつのIP からは証明書５００枚まで。
５．保留中（これよく分からない）のは３００枚まで
６．制限がかかった時は、１週間たつと解除される。
私は４つのドメインをSANを使ってひとつの証明書にまとめてます。
私の理解では例えば毎週日曜日に --force-renewal 使って更新しても制限にひっかからないと
思うんですが合ってますか？（勿論、決してお薦めでは無いだろうけど）
教えて下さい、エロい人
マニュアルには、毎日２回 renew がリコメンドされてるみたいだけど、
毎週はやりすぎにしても、毎月１回、 --force-renewal するほうが let's のサーバー負荷少ないんじゃね？
殆どの人は回数制限にひっかからないでしょうし。
更新しないようにしてたわ。それを cron で二日毎に回す感じで。
今は certbot がよろしくやってくれてるから force-renewal とかしなくても済んでるよ。
renewならローカルに保存されている証明書の有効期限が30日を切っていない限り
サーバには一切アクセスしないのです。
期限まで45日を切ったら強制更新するスクリプトを4日に一度cronで回してたけど
もう少しタイミングを後ろにずらせるのかな
サーバー１でSAN使って www www2 www3
と証明書を取得したとします。
後に
サーバー２で www2
とした場合は証明書は取得可能でしょうか？
サーバー１で取得したものが無効になったりするのでしょうか？
同じ証明書を使えばいいじゃない。
certbot renew --post-hook"なんちゃら"
を --dry-run や --force-renewal でテストして動作確認。
よくわかんないまま、毎日２回 cron で実行するようにした。
毎日、２回、メールがうざい。ので、--quiet を追加。
今度は、本当に期限切れ１ヶ月前にちゃんと動作してくれるんだろうか？と不安になる。
で、毎週１回 cron にして、--quiet を削除。
（今ここ）
みんな、どうしてるの？
p.s.
ところで cron で６０日に１回とか、７５日に１回ってどうやるの？
やろうと思ったんだけど、あり？どうやるんだろうと考え込んでしまった。ｗ
確認方法ある？
スクリプトで期限までの残りをチェックして閾値以下になったら強制更新
これを数日に一度実行するのが気持ち的に楽なんだよ
その時に強制更新かけて、通知メールが来る前に処理しちゃう
サブドメインの分をSANS使わずにやってると、メールがウザいでしょ
ドメイン持ってない漏れには関係ないけど、趣味で試行錯誤するのは楽しい
仕事となると期限が発生するからゴメンだけどね
30円くらいでドメイン取得できるぜ
どうせその30円のは一年しか使えないんだから
どうせDonateもしてないんだろうし。
スーパーの試食も無料だから全部食うようなヤツらだろうな
/var/log/letsencrypt/ 以下のログって黙っていると無限増殖するんですよね？
すごい才能だな
certbot使ってない？
certbotがでローテーションはやるが古い世代の削除をやらないだけ。
そうなんですよね。みなさん、ログのお掃除してます？
昭和生まれでフロッピーディスクとか使ったことある世代の人間なのか？
参考までに、俺の VPS のApache が吐いているログファイル "www.example.com-ssl_access_log" は、1日200万PVで、1日あたり 2.7GB にもなる (UserAgent名も書き出しているから容量多いっぽい)
だけど、パフォーマンス上の問題は全くおきていないぞ
/var/log/letsencrypt/ のログを見たところ、1日あたり 50KB 程度だった
毎日cronで回して、1年で 18.25MB、10年そのサーバを運用しても 182.5MB にしかならない
つまり、certbot のログは、一生貯め込んでも全く問題がないと言える
10年ため込んでも200MBにもならないログの容量の心配をするのは、老害もいいとこである
せいぜ次の更新までぐらいでOKだろう
なんか「必要のないメール貯めてどうする。要らないメールは見たら消せば良い」と言ってる老害みたいだな
俺のGmailアカウントは1度もメール消したことないし、今チェックしたら34万通貯まってたが、これから一生メールを削除することはないだろう
過去のメールやログは、何かに役立つときが来るかもしれないから念のため取っておくというのが今主流の考え方だと思う
容量の問題じゃないからメールとの比較も的外れだ
サーバ管理者には向かない性格してそうだな
ログを安易に消しちゃう方がサーバ管理者に向いてないよ
例えば、正常に動いているように見えて実は不具合が発生していたことに気が付いた場合（ログにもエラーが記録されていない）ようなとき、
過去にも同様の問題が発生していたのかどうかの情報が役に経つこともある
ログ全検索で、5年ぐらい前にも同じエラーが発生していたことが分かり、そっちのログがヒントになって問題が解決したこともある
生ログには問題を解決するのに役立つ情報が含まれている場合ね
今回初めて発生した問題なのか、過去に気が付かなかっただけで同じ問題が発生したことがあったのかが重要になることもあるから、
やはりログは原則削除すべきではない
例外は、WebサービスのPOSTデータの生ログなど、容量が膨大になり保管が困難な場合
勿論、役に立たないデータというわけではなく、例えば数年ぶりにログインしたユーザーからデータが損傷しているというクレームがあったとき、
数年前のPOST生ログがあれば復旧可能なこともあって役には立つわけだけど、容量が膨大になるときは保管コストが高いので消さざるを得ない
POSTデータの生ログで復旧するようなシステムってデータベースで設計しろよとｗ
保管コスト以前に膨大な量のログから異常見つけるコスト考えろって
アホか
過去のログなんてのはいつから問題が発生していたか程度分かれば問題ない
証明書の期間が3ヶ月なんだからそれ以上は残しても無駄
仲良くしようぜ。
> 証明書の期間が3ヶ月なんだからそれ以上は残しても無駄
いや、証明書の期間過ぎてもログは使い道あるだろ
例えば、Certbotって仕様が色々複雑でSANのエリア拡張がどれにかかるのかとか
サブドメイン列挙したときにどれがメインのドメイン名でどれがSAN扱いなのかとか
色々よくわからない点あるじゃん
過去のログとっとくと、昔ああいうコマンド打った時こういう証明書が発行されたな、とか色々わかって便利
「無駄」がどうのと言い出すのなら、1日数十キロバイト程度のログをどうするのかをいちいち考える時間が一番無駄
気にせず放置してログはそのまま保存しとけばいいだけ
ログが万が一漏えいしたときのリスクとか的外れなことは言い出すなよｗ
root権限でしかアクセスできないログが漏えいする時には、もっと重要な秘密鍵もとっくに漏えいしてるわｗ
大した必要もないのに下らんこと気にする方がリスクが高いな
メモれよ
馬鹿か
そんなに暇なんか
どうせ同じエラーしか出力されていないだろうし、エラー内容ググればすぐに解決するだろ
レアすぎる要求なんだろうな。
そうじゃなくたって公式以外の実装はいくらでもあるのに
/usr/local/にpython2.6一時期入れてみるよ。
年季の入ったＣｅｎｔOS5管理者を舐めるなよ！
今月でサポート終了だよね＞CentOS5
さい
踏み台にされたときの言い訳も用意した方が良いよ
俺のせいじゃないって
内部に自分以外のログインユーザーがいたりしなきゃ問題ない。
kernelより上のサーバー周りはほとんどソースからビルドしてるし。
CentOSといいつつ、その機能はほとんど使ってない…
ffftp ではオレオレ証明と同じ扱いになる。
3ヶ月で証明書は変わるし使えないって事？
じゃ sftp でも良いからあらかじめ証明書をダウンロードなどしないで本当に相手なのか確認できる方法があるの。
・FTPSクライアントのホスト名にはIPアドレスじゃなくて、ドメイン名で入れてる？
Let's Encrypt は IPアドレス に対する証明書じゃないのでIP入力ならオレオレ扱いになるのは当然
・FFFTPがFTPS対応かはつかってないので知らんけど、仮に対応だとしても小規模のフリーソフトレベルのソフトが
Mozillaのように独自の証明書ストアを持っているとは思えない
Chromeとかと同じようにOSの証明書ストア（IEとかEdgeと共通）を使ってると考えるのが自然
ってことでLet's の証明書でエラーでるならベリサインとかシマンテックとかジオトラストの証明書でも
同じエラーが出ると思う
それを言ったらhttpsでもIPでアドレスでつなげばオレオレで良いって話じゃないか。
ブラウザの警告の話なら確かに出るけど
そもそもどうしたいの？
ただ警告消したいの？
その通りだな
証明書を新規取得時に、下記の3つを全て確認してくるEV証明書こそまともな証明書だよ
・登記全部事項証明書（登記簿謄本）の原本の確認
・帝国データバンクの情報の確認
・タウンページ記載の電話番号への架電
Let's Encrypt をはじめとした各種DV証明書はほんとゴミ
認証作業が機械化されている DV証明書で金をとる糞業者は滅びるべき
DVは「平文」で通信されるDNSとか、「平文」のHTTPに認証用ファイルを乗せるとかを担保にしているので、
信頼性が全くない
ゴミというかそれらを省いてるからでしょ。
どれを使うかはホストした人が選べばいいだけ。
ttp://internet.watch.impress.co.jp/docs/news/1051510.html ttps://security.srad.jp/story/17/03/26/064241/ 「Chrome 64で279日以内の証明書しか受け入れないようにするとの提案を行った」模様
GeoTrust、Thawte、Verisign、Equifax も Symantec
使っている人が多い RapidSSL も GeoTrust なので、Symantec発行の証明書扱い
Google Chrome だと、大手認証局の証明書の有効期間も約9か月までに制限されそうなので、
自動更新が容易な Let's Encrypt の方が有利になるな
有償の証明書よりも利便性が高まるという皮肉な事態
ttps://goo.gl/8by4rX これは嫌だなー。。本当なの？
なんでかわかりますか？
Windowsのクロムでみるとちゃんとアドレスが緑になってくれるのに。
もし入れるとしたら、何をどう入れれば
なんかわからんけど解決。
危険の警告じゃなくて、証明書インストールしますか？というダイアログが出る
端末は去年買った3台とも。
ここはお前の日記帳じゃない
をやり直して、現在はエラーが出ていません。
中間証明書は自動でインストールされる xxx.xxxxx.com-all.pfx に含まれているのでしょうか。
.pemのほうはいくつか生成されていて、-chainというやつがそれっぽいですが、.pfxは一個しか
ないけれど、上のファイルとほぼ同じ大きさのファイル。
An unexpected error occurred:
AttributeError: 'tuple' object has no attribute 'add'
Please see the logfile 'certbot.log' for more details.
指示に従って、certbot.log なんかを見たりして、ググったところ
py-configargparse
が、11 だと certbot は動くけど、12 になるとエラーとなることが分かった。
調べると、確かに昨日 12 にアップデートしてたので、とりあえず、１１に戻したら
動くようになった。
まぁ、certbot 側か configargparse 側のどちらか（あるいは両方）が近いうちに対処すると思うけど
とりあえず、これで１時間ほど使ったので、メモ代わりに残しておこうｗ
ttps://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html これでサブドメイン毎に証明書を分けなくても、
証明書から他のサブドメインがバレるって事はなくなるな
今みたいな「そのドメインを管理している証明」の方式が使えるのだろうか。
あるドメインでアクセスできる場所に申請者がミシルシを置けるなら、そのサブドメインは
どれでもOKみたいな？
*.sub.example.comが登録できるわけではないだろ
少なくともSSLのワイルドカードの扱いはそういうものです。
なるほど、じゃあワイルドカードｷﾀｰって人はそこまで多くなさそう
ttps://tools.ietf.org/html/rfc6125#page-27 6.4.3. Checking of Wildcard Certificates
え？？本当に理解してるか？
サブドメインごとに登録が必要なのがドメインにつき一つでいいんだぞ？
自分でドメインとってる人は嬉しいだろうけどね
別にddnsのサブドメインでいいやって人には恩恵なさそうな流れだったからね
> 別にddnsのサブドメインでいいや
ああそんな人がいることを考えてなかった
Rootで動くクライアントソフトを定期的に回さないといけない仕様ぽいんだけど
ほんとに、こいつ信用しちゃって大丈夫なん？
やや怖い
っていうシンプルな仕組みにしなかった理由が知りたいところ
クズがサイト作って放置するからだよ
1ドメインあたりの数の制限ではなく、Googleのunsafeドメインに引っかかってるのかな。
The client lacks sufficient authorization :: Error creating new authz :: "xxx.example.jp" was considered an unsafe domain by a third-party API. Skipping.
悪意あるサイトだと判明したらcert revoke できるから
