証明書の OU（組織単位名）は非推奨へ、来年からは利用禁止に
OU（組織単位名）利用禁止の背景 パブリックなサーバー証明書の要件を定める業界団体 CA/Browser フォーラムにおいて、証明書のサブジェクトに含まれる「OU（組織単位名）」について見直しが行われた結果、2022 年 9 月 1 日以降に発行する証明書から利用禁止となることが、投票により可決しました。 なお、OU の利用禁止後も発行済みの証明書には影響がなく、継続してご利用いただけます。 これまで OU には、証明書の「O（組織名）」に関連する一般的な部署名等の値が許容されてきましたが、一方で証明書の O と関連がない不正な値での証明書発行のインシデントが報告されるなど、その利用や審査方法について議論されてきました。 しかし、OU を適切に審査する方法の確立には至らず、約 1 年の猶予期間をもち、2022 年 9 月 1 日以降に発行されるサーバー証明書についての OU の利用が禁止さ
SSL/TLSサーバ証明書、コードサイニング証明書 | 国内最安値DigiCert（デジサート）正規代理店
本ページに記載されているCSRの作成方法は、基本的な構成を元にしています。 システム環境等の設定状況により、手順や画面表示が異なることがあります。 アプリケーションやツールなどの仕様や設定手順等でご不明な点がある場合は、それらのマニュアルをご確認いただくか、開発元にご連絡ください。 ※この手順によって生じた影響や結果について、弊社では一切の責任は負いかねます。 Apacheをはじめとする、opensslコマンドでCSRを作成するサーバーの場合、このウイザードがご利用いただけます。 このウイザードはJavaScriptを利用しています。お使いのブラウザでJavaScriptを使えない設定にしている場合は、JavaScriptが利用できる設定に変更してください。
NginxでSSL (その勘所)
SSL証明書発行まではApacheでSSL(その勘所)と全く同じ。SSLs.comでの証明書の種類選択もApache2用で良い。 と、いうか証明書の種類にNginxという選択肢がない(2015年12月現在) SSLサーバ証明書 例えばSSLs.comで購入するとSSL証明書はComodoやGeotrustからメールで送付されて来る。そのメールにRapidSSLの場合は本文に、PositiveSSLの場合は本文(Web Server CERTIFICATE以下)と添付ファイル(ZIPファイル中の申請したホスト名orドメイン名.csrという名前のファイル)の両方にSSLサーバー証明書があるので/usr/local/etc/nginx/ssl/example/にserver.crtというファイル名で保存。(path/ファイル名は任意) SSLサーバー証明書の例 -----BEGIN CERTIF
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
crypto policy - とみぞーノート
crypto policy SSLの設定をしていたら、Fedora21からcrypto policyというものが導入されていたのを知った。 crypto policyにより、各アプリケーションで個別に設定していた暗号設定を、システム全体の設定として定義し、各アプリケーションからそれを参照するようにできる。システム内の各アプリケーションの暗号関連のセキュリティレベルを、まとめて管理するために開発されたもののようだ。 Fedora23でcrypto policyに対応しているソフト／ライブラリは以下のもの(man update-crypto-policies参照)。 GnuTLS library OpenSSL library OpenJDK Libkrb5 BIND OpenSSLでのcrypto policyの参照 例えば、OpenSSLでcrypto policyの設定を参照するには、P
[CSR生成] nginx + OpenSSL（新規・更新） | GMOグローバルサイン サポート
更新のお客様 nginxをご利用の場合は、前回ご利用いただいたCSRでも更新可能ですが、セキュリティのためにも毎回鍵を作り直していただくことをお勧めいたします。 コマンドの準備をします。 OpenSSLがインストールされているか確認してください。 # openssl version nginxの confのパスに移動してください。 # cd /etc/nginx/ opensslのバージョンが確認できない場合、以下をご参考ください。 opensslコマンドが利用できないようです。 秘密鍵を生成します。ここで入力するパスフレーズを忘れてしまうと使用することができなくなります。 更新または乗り換えのお客様nginxの仕組み上、秘密鍵を上書きしても、リスタートしない限り影響はありませんが、上書き後の復旧はできませんので、既存のファイルに上書きをしないようご注意ください。秘密鍵のファイル名には、そ
Chromeで信頼されなくなるSymantec発行のSSL証明書かどうか判定・確認する方法
SSL証明書が「信頼されない」とHTTPSサイト表示時にエラーが生じる 最初に「SSL証明書が信頼されない」とはどういうことか説明しよう。 Chromeに限らずWebブラウザは、HTTPSのWebサイトに接続する際、SSL証明書が正当なものかどうか検証する。もし有効期限や共通名（コモンネーム）、発行元（認証局）などに何かしら異常が見つかった場合、アドレスバー左端のアイコンやブラウザペインにその旨のエラーを表示してエンドユーザーに知らせる。 この状態ではHTTPSによる暗号化は信頼できず、通信中に盗聴や改ざん、なりすましの被害を受ける危険がある。 つまり、近い将来、Symantecの認証局から発行されたSSL証明書を組み込んであるWebサイトに対し、Chromeで閲覧したエンドユーザーにはこうしたエラーが表示されるようになる、ということだ。Webサイト運営・管理側としては何としても避けるべき
5分でわかる正しい Web サイト常時 SSL 化のための基礎知識
Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな～ と思って書いてみた、恒例の （？） 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL
サーバーの処理を肩代わりする「オフロード」とは？ (1/3)
本連載では、ロードバランサーや帯域制御装置、WAN高速化装置などで用いられているアプリケーショントラフィック管理の技術について解説している。前回はQoSやキャッシング、ロードバランサーなどの技術を紹介したが、今回はサーバーの処理を肩代わりするオフロードの機能について見ていく。 サーバーの処理を肩代わりする 「オフロード」の必要性 ロードバランサーや統合的トラフィック管理装置を導入しても、アプリケーションの処理自体はサーバーに依存している。 ロードバランサーをレストランの給仕に例えれば、給仕さんはシェフ（＝サーバー）の作業を見ながら注文を振り分けているだけで、シェフの仕事自体を担っているわけではない。素材を切ったり、焼いたり、盛りつけたりするのはあくまでシェフの仕事なのだ。そのため、全体の処理能力を向上させるには、やはりシェフの人数を増やすしかない。とはいえ、お客さんも美味しくて見栄えもよい
SSL/TLS 20年の歩みと動向～ - JPNIC
昨年2014年は、SSL（Secure Sockets Layer）とTLS（Transport Layer Security）というプロトコルがリリースされてから20年が経過し、HeartBleedやPOODLEなどの脆弱性でも話題となった年でもありました。今回の10分講座では、SSL/TLS暗号通信プロトコルの動向を紹介します。 SSL/TLSとは SSL/TLSは最も普及している暗号通信プロトコルの一つで、TCP/IPの4レイヤーモデルのトランスポート層とアプリケーション層との間に位置するため、広く使われているHTTPばかりでなく、SMTPなど任意のプロトコルを安全に送受信する目的で使用することができます。特にWebにおいて暗号通信機能を提供できるようになったことにより、オンラインショッピング、オンラインバンキングやユーザー認証を必要とする各種オンラインサービスの普及に重要な役割を担
HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
オレオレ認証局の適切な運用とName Constraints - kazuhoのメモ置き場
オレオレ認証局が忌避されるべきものとされてきた理由は、X.509 PKIが保証する安全性は、最も信頼性が低い認証局（trusted root）のそれに等しいからです。 しかし、X.509 v3以降ではName Constraintsが導入され、「特定のドメインに対してのみ証明書を発行可能な認証局」を定義できるようになっており、同constraintをcritical key usage extension*1として宣言したルート証明書を安全な経路で配布、インストールすることができれば、上記のようなX.509 PKIの系全体に対する影響は発生しないことになります*2。 ここで問題になるのは、どの程度のウェブブラウザがName Constraintsに対応しているのか、という点になりますがhttps://news.ycombinator.com/item?id=5194103によると、Chro
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
SSL証明書のインストールチェックはどのサイトを利用すべきか - このブログはURLが変更になりました
先日ツチノコブログでクロスルート証明書の確認にIE6を使ってる話が紹介されてた。 確かに実機で確認するのは大事なのだが、SSL証明書が正しくインストールされているかチェックしてくれるサービスがいくつかある。 それで確認すればいいんじゃね？と思って調べてみたが、実はクロスルート証明書まで調べてくれるサービスは少ない。また各社チェックしてくれる内容が結構違う。 そこでオススメのSSL証明書チェックサイトを3つ厳選してみた。 Qualys SSL Labs SSL Server Test クロスルートを含む複数のチェインを表示してくれるのは試した限りここだけだった。 また、クロスルート以外にも脆弱なプロトコルや暗号アルゴリズムを使用していないか、BEAST、CRIME、Lucky13、BREACHなどの攻撃に対して対策されているかなども調べてくれる。 グレード表記や項目別スコア表示もあり。最低限
Tポイントツールバーを導入するとSSL通信の履歴までもが盗聴可能になる
twitterなどでTポイントツールバーの利用規約が話題になっています。このエントリでは、Tポイントツールバーを実際に導入して気づいた点を報告します。結論として、当該ツールバーを導入すると、利用者のアクセス履歴（SSL含む）が平文で送信され、盗聴可能な状態になります。 追記(2012/08/10 20:10) たくさんの方に読んでいただき、ありがとうございます。一部に誤解があるようですが、ツールバーが送信している内容はURLだけで、Cookieやレスポンスまでも送信しているわけではありません。URLを送信するだけでも、以下に示す危険性があるということです。 追記終わり 追記(2012/08/13 23:50) ポイントツールバーにバージョンアップがあり、WEB閲覧履歴の送信がSSL通信に変更されました。従って、WEB閲覧履歴が盗聴可能な状況は回避されました。本日22:50頃確認しました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設定マニュアル | JPRS
SSLストア 【RapidSSL 1,620円 Symantec 53,000円 GeoTrust 11,880円】
https://www.digicert.co.jp/welcome/pdf/wp_ssl_negotiation.pdf
SSL/TLSの基礎と最新動向
