開発サーバでソフトを動かすときにサーバ証明書が必要になるときってありますよね。 今話題のHTTP/2を試すにはSSL通信が必須だったりしますし。 もちろんOSやソフトについてくるサンプル用の証明書でもSSL通信はできるけど、証明書が検証エラーになるわけでブラウザの警告画面が鬱陶しいし、検証エラーを無視するための設定変更をする必要がある場合もあります。 かといって、わざわざ開発サーバのためにSSL証明書は買えないし…。 そんなときの救世主がLet's Encryptで、無料で正規のSSL証明書を発行してくれるありがたい存在です。 しかし、Let's EncryptでSSL証明書発行するためにはドメインがDNS登録されている必要がありますので、社内(組織、自宅)内の内部で使ってる"abc.localdomain"みたいなドメインには対応してません。 結局、自前でLocal CAを運営する必要が
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
2020年2月にApple社が「2020年9月1日以降に発行されるSSLサーバ証明書で、有効期間が398日を超える証明書をSafariでは無効とする」という発表を、グローバルサインブログで紹介しました。本日はその続報を紹介します。 その後、ブラウザベンダーのアナウンス CA/Browser Forumでは、SSLサーバ証明書の有効期間を398日未満とする、基本ルール(Baseline Requirements)を盛り込むよう、投票に向けた議論を重ねている最中ですが、2020年6月23日にオンライン会合の場で、GoogleやMozillaも相次いでAppleのアナウンスに同意するかたちで、9月1日以降に発行されるSSLサーバ証明書で、398日を超える証明書は無効化することをアナウンスしました。 これは、CA/Browser ForumのBaseline Requirementsの要件にかかわ
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか? 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
2018年3月と10月に多くのSSLサーバー証明書がChromeとFirefoxで無効化ベリサイン/シマンテック系のSSL/TLSサーバー証明書が、次のスケジュールで無効化されることが、すでに決まっています。 対象のサーバー証明書の発行元: SymantecGeoTrustRapidSSLThawte無効化スケジュール: 2018年3月15日ごろ: Chrome 66のベータ版で、上記発行元が2016年6月1日より前に発行した証明書を信頼しないようになる2018年4月17日ごろ: Chrome 66の通常版で、上記発行元が2016年6月1日より前に発行した証明書を信頼しないようになる2018年9月13日ごろ: Chrome 70のベータ版で、上記発行元が発行した証明書すべてを信頼しないようになる2018年10月23日ごろ: Chrome 70通常版で、上記発行元が発行した証明書すべてを信頼
Googleは、シマンテック発行のSSL証明証に対し、厳しい処罰を検討しているという。 シマンテックまたはその証明書の再販業者がSSL証明書を不適切に発行したという重大な事件について、Googleは厳しい処罰を検討しています。 提案された計画は、会社にすべての顧客の証明書を置き換え、それを持っているユーザーの拡張された検証(EV)ステータスの認識を停止することです。 シマンテックは、2015年のNetcraft調査によると、ウェブ上で使用される3つのSSL証明書のそれぞれについて約1つを担当し、世界最大の商用証明書の発行者となっています。数年にわたり買収した結果、VeriSign、GeoTrust、Thawte、RapidSSLなどの以前のスタンドアロン認証局のルート証明書を管理しています。 SSL / TLS証明書は、ブラウザとHTTPS対応のWebサイトとの間の接続を暗号化し、ユーザー
「Google Chrome」で、HTTPのサイトを「安全でない」と示すマークが表示されるようになる。 2017年1月より「Chrome 56」で、パスワードやクレジットカード情報を送信するHTTPサイトに、安全でないことを示すマークが表示される。赤色のアイコンではなく、灰色でシンプルに「Not secure」と表示する。 その後のいずれかの時点で、Googleはその警告を拡張する。最初は、HTTPページが「安全でない」ことを示す警告がシークレットモードで表示されるが、最終的に、すべてのHTTPページに対し、破損しているHTTPSページと同じ赤い三角のアイコンで安全でないことを表示するようになる。 「Chromeでは現在、HTTP接続に対して中立的なマークを表示している」とChromeセキュリティチームのEmily Schechter氏は述べた。「これでは、HTTP接続の安全性が本当に欠如
[これは Mozilla のセキュリティエンジニア Tanvi Vyas 氏のブログ記事 No More Passwords over HTTP, Please! を同氏の許可を得て翻訳したものです] Firefox 46 Developer Edition は、HTTP ページ上でログイン情報の入力を求められた場合、開発者に警告を行います。 ユーザ名とパスワードの組み合わせは、ユーザの個人データへのアクセスを管理する手段です。Web サイトはこうした情報を注意深く扱い、パスワードは HTTPS のような安全な (認証、暗号化された) 接続を通じてのみ要求すべきです。しかし残念なことに、HTTP のような安全でない接続でユーザのパスワードが扱われている例が 非常に多く 見られます。このプライバシーとセキュリティの脆弱性を開発者の皆さんに知らせるため、最新の Firefox Develope
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
サイト制作では問合せフォームだけHTTPSというのはよくありがちだけど、まとめ記事がなかなか見つけられなかったので、自分で記載します。尚WordPressで使うフォームは国内でよく使われている『ContactForm7』にしました。 共有SSLはよくない まずは、SSL(HTTPS)対応する為に証明書の種類について調べてみました。独自ドメインが必須でなければ共有SSLが安くよいみたいです。例えばさくらレンタルサーバのドメイン(sample01.sakura.ne.jp)で既定サイトしか使わないのであれば、コストもかからずこれが良いと思います。ただ、独自ドメインでSSL暗号化を使いたいのであれば証明書をベリサインやGEOトラストの方で別途取得した方が良いです。 共用SSLサーバの危険性が理解されていない .htaccess のみで1ページをSSL対応する 独自ドメインの証明書によるWordP
SSLの認証局とか証明書とか勉強し始めはホント難いよね このへんのSSL/TLSの仕組みって勉強し始めの頃は凄く難しく感じるのよね。分かりやすく解説してくれてるサイトってあんま見たこと無いし。 んで、 >>300,304 みたいなことは僕も昔考えたことあったわー、と懐かしみを覚えたのでレスってみた。 証明書を発行できるかどうかは証明書のフラグで決まっている、という >>303 の指摘も重要よね。 以下2chスレより引用 丁寧過ぎると評判のレスをしてるID:UyEJo1f2が僕なわけだがw 2chだとそのうち倉庫に行っちゃうかもしれないのでここにメモ。 【認証局】SSLに関するスレ 2枚目【ぼろ儲け】 http://hayabusa6.2ch.net/test/read.cgi/mysv/1286532904/298-309 298 :DNS未登録さん:2013/05/31(金) 13:31
こんにちは検索サービス開発4チームの崔珉秀と申します。 インフラやシステムとの連携や統計のバックエンドを担当しております。 モバイルのウェブ環境はPCのウェブ使用環境とは色々な違いが有ります。 ネットワークの速度だけではなくバッテリーの効率を考えた仕組みなど、PCに比べリソースが十分ではないためモバイルブラウザの動作が異なっていることも有ります。 今回はモバイルのウェブApplicationにおけるSSL関係の性能に関する工夫の内容をQ&A形式で解説していきます。 Q. 何が問題でしたか? A. モバイルクライアント(iPhone, Android)のアプリケーションからのHTTPリクエストの応答時間に遅延の問題が有ります。 最初はweb access logからのslow response(1秒以上)のHTTPリクエストが結構ありました。 そのHTTPリクエストをprotoc
前のエントリで書いたように、b-casは用途を広げた時に前提条件が変わってしまったために、小さな「あってはならないこと」が起きただけで、手当ての方法が無くなってしまいました。 では、これと同じような見方で、インターネットそのものに「あってはならないこと」が起きた時どうなるか、について書いてみたいと思います。「インターネットそのもの」と言っても、一般の人が目にする「インターネット」の中でセキュリティをしっかり守らなければいけないのは、オンラインショッピングの時に使われる「SSL」という通信方式です。 アドレスが「https://」で始まるサイトにアクセスすると、そのアドレスの横に鍵の形の「安心マーク」が表示されます。オンラインショッピングで決済の画面やクレジットカード番号を入れる画面では必ずそうなっていると思いますが、これが今「SSL」を使っているよ、「SSL」がうまく動いているよというお知
「体系的に学ぶ 安全なWebアプリケーションの作り方」を読んでいたら、とっても気になる記述が。 サーバー証明書のうちドメイン認証証明書は比較的価格が安く、購入のハードルが低いものですが、ドメイン認証証明書には無料のものがあります。イスラエルのStartComという企業は、無料のサーバー証明書を発行しています。IE、Firefox、Google Chrome、Safari、Operaの最新版で証明書エラーなく使用できます。IE6でもアップデートが当たっていれば使用できます。 日本の携帯電話には対応していないようです。しかし、今までラピッド SSL が年間2,100円で最強だと思っていたけど無料のものがあるとは。気になったので、ちょっと調べてみました。 以下の画面が StartCom のサイトです。画面の赤枠のリンクをクリックすると次の画面が表示されます。 そうすると、SSL 証明書の製品紹介
銀行やカードのサイトなど、SSL使っているすべてのページで「セキュリティ証明書に問題がある」という警告が出てページが表示できなくなった、という相談を受けた。 Vista+IE8でウイルスバスターの最新版が入っている環境。 他のページの表示などは問題なく、警告を無視してそのまま開いてやるとページが表示できるため、インターネットの接続自体やSSLの通信には問題が無いことはわかった。 ウイルスバスターのパターンファイルも最新に更新されており、そちらの問題はなさそうな感じではあった。 IE8だけで問題が起こるのかと思い、Chromeをインストールしてもらって試してみてもやはり同様の警告が出た。というわけでIE8に依存する問題ではないことは確認できた。 となるとあと考えられるのは、なにかウイルスにでも感染しており中でドメイン情報を書き換えられてたりして証明書の認証が通らない?とか最悪パターンを想定し
SSL証明書を作成する際に作る、CSR(署名リクエスト)と秘密鍵ですが、そのペアを誤ると当然使い物にならなかったりします。 オレオレ証明書の場合はやり直しがききますが、認証局に申し込むSSL証明書の場合は、取り返しのつかない事態にもなりかねません。 また、複数のFQDNのCSRを作る場合、作業場所や操作を意識しながら行わないとどの秘密鍵とCSRがペアなのかわからない事態にもなってしまいます。 ここでは、申し込む前にきちんとCSRと秘密鍵のペアが正しいかを確認する方法を書いておきます。 まずは、秘密鍵とCSRを作成してみます。 この辺りの手順は、各認証局のマニュアルページにも書かれていたりするのであまり詳しく書きません。 # openssl genrsa -rand /dev/urandom -des3 -out private.key 1024 2048 semi-random bytes
こんにちわ。モバイルディレクターの飯田瞬です。 ウェブディレクターの中には、SSL サーバ証明書が必要なウェブサイトの構築を担当した人は少なくないと思います。 今回は SSL サーバ証明書を取得するにあたり、ディレクターが知っておいた方が幸せになれる必要最低限な事項を簡潔にまとめてみました。 割愛している部分もかなりありますが、詳細まで突っ込むと1エントリーでは収まりきらないため、何卒ご理解いただければと思います... 【01】SSLサーバ証明書って何だろう? SSL を一言でまとめると、住所やカード番号などを暗号化して第三者が傍受してもデータの改ざんや盗聴を防ぐといった技術が SSL です。 SSL サーバ証明書というのは、その SSL の暗号化技術を利用するサーバの身元を、第三者である認証局が保証することを示すものです。この証明書の中には SSL でクライアントとサーバ間の通信を暗号化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く