はてなブックマーク

ユーザーとエンドユーザーの間の通信を暗号化するには、SSL証明書を購入してサーバーにインストールし、証明書を使用してこれらの通信を保護するようにWebサイトを構成します。 SSL接続は、エンドユーザーのブラウザがWebサイトにアクセスする際に開始されます。開始の最初の段階でハンドシェイクが行われます。 このハンドシェイク過程で、ブラウザとサーバーの暗号化に利用する情報が交換され、検証が行われ、ブラウザとサーバー両方の基準を満たすセッションキーが作成されます。 セッションキーが作成されると、エンドユーザーとサイト間の通信の残りの部分がセッションキーで暗号化されて通信が保護されます。 歴史的に、セッション鍵をネゴシエートする最も一般的な方法は、RSA公開鍵暗号方式です。 RSA公開鍵暗号方式では、ブラウザは作成したセッションキーパラメータをサーバーの公開鍵を使用して暗号化し、サーバに送信します

ハンドシェイクとは SSL/TLS通信でサーバーを認証し、「公開鍵」と「秘密鍵」を使って「共通鍵」を共有する過程を「ハンドシェイク」と呼びます。 SSL/TLSセッションは、常に「ハンドシェイク」から始まります。 「ハンドシェイク」は、平文のメッセージ交換から始まり、https通信を確立するために欠くことのできないプロセスです。 SSLサーバ証明書を検証し、通信しているサーバーが真に意図したサーバーであるかの検証を行います。 サーバーがクライアントを認証する場合は、クライアント証明書を利用してクライアント認証が行われる場合もあります。 サーバーが認証されると、プリマスタ シークレットの交換、セッション キーの共有の手順に進みます。 このセッション キーが「共通鍵」となります。 RSAサーバ証明書のハンドシェイク

OCSP StaplingでOCSP情報をサーバー上にキャッシュし、サーバー証明書情報と共にブラウザに提供することができます。 オンライン証明書状態プロトコル：OCSPとは オンライン証明書状態プロトコル：OCSP (Online Certificate Status Protocol) は、CRLプロトコルに代わりSSLサーバ証明書の失効をチェックする、現在主流のプロトコルです。 CRLもOCSPも証明書が失効していないかどうかを確認するために使用されます。 CRLプロトコルでは、証明書の発行数の増加とともに潜在的にサイズが増加する「SSL証明書の失効情報ファイル」をダウンロードします。このファイルには、認証局ごとのすべての失効証明書のシリアル番号と失効日が記載されています。 CRLプロトコルの問題点は、証明書が失効していないことを確認するのに時間がかかり、結果的にSSLネゴシエーション

Apacheでのクライアント認証はBASIC認証が有名ですが、より安全な認証方法が、クライアント証明書を利用する方法です。 以下で、クライアント証明書利用設定の入門部分を紹介しますが、最初のポイントは、以下の2点です。 BASIC認証はhttpプロトコルでも利用できるが、クライアント証明書利用認証はhttpsプロトコルでのみ利用できる クライアント証明書の中間証明書、root証明書を「SSLCertificateChainFile」として認証を受けるサーバーで指定する必要がある 最も基本的なクライアント証明書利用設定 Apacheでのクライアント証明書利用設定は httpd.conf ssl.conf などのApacheの設定ファイルで行います。 設定ファイルの名称や位置はApacheのバージョン、利用環境によって異なりますが、httpsのVirtualHost設定を行っているファイルで行

Hypertext Strict Transport Security（HSTS）とは Hypertext Strict Transport Security（HSTS）は、WebブラウザにTLSの使用を強制するポリシーメカニズムです。 WebブラウザがHSTS指定されているWebサイトにアクセスすると、Webサーバーは次回からhttpsアクセスするようにWebブラウザに通知します。 こうして、HSTSはすべての通信がクライアント側のセキュアなトランスポート層を介して行われることを保証することにより、TLSのより効果的な実装を可能にします。 HSTSは、特に中間者（MiTM）攻撃防止に有効とされています。 HSTSは2012年にRFC 6797で規定されています。 HSTSを設定する 構成要素 Strict-Transport-Security　ヘッダーを構成するフラグは「max-age」

以下で、IISでのクライアント証明書利用設定の入門部分を紹介しますが、最初のポイントは、以下の2点です。 IISでクライアント証明書を利用する場合、あらかじめIISサーバーにクライアント証明書を登録する必要があります。 IISサーバーにSSLサーバー証明書がインストールされていない状態でもクライアント証明書を利用したクライアント認証は可能です。 IISサーバーに登録するクライアント証明書情報を準備する IISサーバーに認証を受けるすべてのクライアント証明書を登録する必要があります。以下の手順でクライアント証明書情報を取得します。 クライアント証明書がインストールされているPCで「スタート」ボタンをクリックし、検索ボックスに「certmgr.msc」と入力して Enter キーを押します。「certmgr」が表示されます。 ※クライアント証明書を Firefoxのみで利用する設定になっている

CRL（証明書失効リスト） CRLには失効した証明書のシリアル番号と失効日が記載されています。 認証局（CA）は、失効した証明書のリストCRL(Certificate Revocation Lists)を公開し、このリストのURLを、あらかじめサーバー証明書に記載しておきます。 サーバーが提示した証明書を受け取ったブラウザ等のクライアントは、その証明書がCRLに掲載されていないかを検証します。 サーバーが権威ある認証局によって発行された証明書を提示し、それが有効期限内のものであっても、その証明書だけでは証明書の有効性は確認できません。 証明書の発行後にその証明書が失効している可能性があるためです。 証明書の失効は、秘密鍵が漏洩した場合や、間違った手続きのもとに発行された証明書であることが判明した場合などに行われます。

ニュースソース：Google Security Blog ※以下の文章は、Security Through Transparencyを要約したものです。 2017年1月12日、Googleは公式セキュリティブログで、メッセージングのセキュリティのための新しい暗号技術Key TransparancyのディレクトリをGitHubで公開したことを公表しました。 現在はオープンソースのプロトタイプの段階にあります。 Key Transparancyは、Googleの証明書の透明性（Certificate Transparency）プロジェクトとCONIKSをベースに開発されました。 Googleは、信頼できないサーバーを介した情報通信において、安全性を確立するだけではなく、それをインターネット規模のソリューションに発展させる必要性を感じたことから、受信者のためのジェネリックな公開鍵を開発したと述べ

世界最大のサイバーセキュリティ企業であるSymantec（以下シマンテック）と、暗号化ソリューションの大手プロバイダであるDigiCert Inc.は2017年8月2日（現地時間）、DigiCertがシマンテックのウェブサイトセキュリティ事業及びそれに関連するPKIソリューションを取得する契約の合意を発表しました。 DigiCert（デジサート）は、拡張性の高いソリューション、業界をリードする顧客サポートの提供や、業界のベストプラクティスの向上に重要な貢献をすることで、高い評価と高い顧客ロイヤリティを誇っています。 シマンテックのウェブサイトセキュリティ事業及び関連するPKIソリューションを製品に追加することで、DigiCertは次世代のグローバルウェブサイトセキュリティをリードする驚異的な才能と経験を手にし、IoTの成長機会を活用してSSL市場に新しいアプローチをもたらす能力を得るでしょ

ニュースソース：TEXT/PLAIN 以下は 2017年3月10日に公開されたThe Latest on Certification Authority Authorizationを要約したものです。 自己署名証明書を利用しているサイトにChromeでhttpsアクセスした場合、「Your connection is not private」のエラーが表示されることがあります。 原因は証明書のSubjectAltName（SAN）が正しく設定されていないことです。 1997年に成立したX.509v3は、証明書がドメイン名とのバインディングを示す方法として、SubjectAltName（SAN）にDNS名またはIPアドレスを設定する方法、または証明書のsubjectにコモンネーム（CommonName）属性を設定する方法を定めました。 問題は、コモンネームには不明確性があり、そのサポートは、

2017年9月8日以降、認証局（CA）には、証明書発行プロセスでDNSのCAAレコードの確認が義務付けられました。Ballot 125 – CAA Records (passed) DNSのCAAレコードへの登録は必須ではありませんが、CAAレコードを登録しておくと、証明書の誤発行防止につながります。 ドメインの管理者がDNSのCAA (Certification Authority Authorization) レコードを利用し、ドメイン名とサブドメインに対して証明書を発行できる認証局 (CA) を指定できます。 証明書発行を依頼された認証局 (CA) はドメイン及びサブドメインのCAAを確認し、証明書を発行できる認証局 (CA) が異なる場合は、証明書を発行せず、ドメイン管理者に誤った発行申請があったことを報告します。

SSLサーバ証明書のインストールに必要な .PEMファイルを作る .PEM SSL サーバ証明書作成手順 X.509証明書の拡張子 .pemは、Base64で符号化された証明書です。.pem SSL サーバ証明書（連結SSLサーバ証明書）では複数のサーバ証明書を1ファイルに連結させることができ、SSLサーバ証明書のインストール用によく使われます。 .pemファイルを使うサービスによって、必要とされる内容が異なります。.pemファイルに必要な内容については、利用するサービス（アプリケーション）のインストールガイドを参照ください。 証明書チェーンの全てを含む場合

opensslプライベートキー復号化 CSR作成時に、PEMフレーズ（PEM phrase）を指定して秘密鍵を暗号化し、保護することができます。 しかし、そのままの状態で利用すると、apache等のサーバーでは起動のたびにPEMフレーズ (PEM phrase) の入力を求められます。そのため、暗号化された秘密鍵は復号化して使うのが一般的です。 復号化した秘密鍵はroot以外は読めない状態で保存してください。 PEMフレーズ（PEM phrase）で暗号化解除 以下のopensslコマンドを実行すると、PEMフレーズ（PEM phrase）が要求されます。 # openssl rsa -in ssl.pk -out ssl.pk openssl rsa コマンドは、プライベートキーからデフォルトの暗号化を取り去り（decrypt）、Apache Webサーバー等のアプリケーションが利用でき

www.example.com と www.example.net のような異なるドメイン名を持つホスト名であっても、1枚の証明書でカバーすることができます。 ワイルドカードサーバ証明書の場合は、【同一のドメイン名のすべてのホスト名】に対応しています。しかし、 www.example.com とwww.example.net のような異なるドメイン名を持つホスト名は、Subject Alternative Names（サブジェクトの別名）を使わない限りカバーできません。

ここでは、OpenSSLを使ってコンピュータ上でCSRと秘密鍵を作成し、取得したサーバ証明書と秘密鍵を合成して.pfxファイル証明書を作成する方法について説明します。 OpenSSLでのCSR作成手順 利用中のコンピュータでOpenSSLコマンドを使ってCSRを作成します。 CSRの作成と同時に秘密鍵も作成しますので、安全性が確保されたコンピュータで作業してください。 CSR作成に必要な情報 CSR作成には以下の情報が必要になるのであらかじめ用意してください。 国名 (Country Name) – 法人の登記国名コードを記載します。日本の場合はJPです。 都道府県名 (State or Province Name) – 法人の登記簿謄本に記載された都道府県名をローマ字で記載します。 法人所在地 (Locality Name) – 法人の登記簿謄本に記載された都市名をローマ字で記載します。

Forward Secrecyとは 過去の秘密データを守る 暗号化されたデータの盗聴 盗聴されたデータは、SSLで暗号化されていればそのままでは解読されることはありませんが、暗号化する際に使用した鍵が入手できた時のためにそのまま保存されている可能性はあります。 NSA・米国国家安全保障局による盗聴疑惑が話題になりましたが、国家機関であれば暗号化された全インターネットデータも保存することが可能です。 実際に、暗号化鍵が露呈される事件も起こっています。2014年にも、有名なOpenSSLに重大な脆弱性（Heartbleed）が見つかっています。（HeartbleedについてはOpenSSL Heartbleed（心臓出血）脆弱性へのDigiCertの対応をご参照ください。） このような事態が起こった場合、バグフィックスを行ったうえで新しい秘密鍵を設定すれば、それ以降の通信データの安全性は確保で

ホーム＞ サポート＞ CSR作成方法＞ opensslでマルチドメイン証明書用のCSRを作成 opensslでマルチドメイン証明書証明書用のCSRを作成 本ページに記載されているCSRの作成方法は、基本的な構成を元にしています。 システム環境等の設定状況により、手順や画面表示が異なることがあります。 アプリケーションやツールなどの仕様や設定手順等でご不明な点がある場合は、それらのマニュアルをご確認いただくか、開発元にご連絡ください。 ※この手順によって生じた影響や結果について、弊社では一切の責任は負いかねます。 マルチドメイン証明書を使うと、ひとつのサーバー証明書で複数のホスト名を有効にすることはできます。これはワイルドカード証明書とは異なり、www.hoge.jp と www.hoo.jp のような全く異なるホスト名を有効にする技術です。 全く関係のないドメインがこの証明書を使うことは適

ビジネスに必須の電子メールのほとんどは、通常、ネット上で傍受可能な平文で通信されています。 中間者による改竄の可能性もあります。また、そもそも「送信者が本当に本人かどうかわからない」なりすましメール問題もあります。 これらは暗号化技術によって防ぐことができますが、これまでその利用はなかなか進んできませんでした。 しかし、2014年4月現在500万社以上の企業が導入しているGoogleのクラウドベースのビジネス向けツール「Google Apps」において主要なアプリケーションである「Gmail」が接続方法を常時HTTPSにするようになったことで、傍受や改ざんを防ぐことのできる電子メールの暗号化は、TLS/SSL利用への大きな流れに乗ったといえるでしょう。 暗号化が進まなかった背景と今後の展望 Microsoft ExchangeがTLS/SSL利用を推奨し、Unix系サーバーでもほとんどのメ

SSL証明書ファイルのエンコードタイプとopensslでの変換方法 X.509証明書ファイルとPKCS証明書ファイルのタイプと変換方法 X.509証明書ファイルのエンコードタイプ X.509証明書のエンコードタイプのうち、よく使われるものとその代表的ファイル拡張子は以下です。 拡張子は随意に決めることができるため、必ずしも以下の拡張子が使われるわけではありません。 エンコードタイプ ファイル拡張子

証明書を リーズナブルに 取得できる 正規代理店 RMSはDigiCert（デジサート）の正規代理店です。 DigiCert SSL/TLSサーバ証明書, コードサイニング証明書等の、 デジタル証明書の取り扱い実績は国内最長！ 2021年度「DigiCert Partner of the Year for APAC」を受賞いたしました。 企業・組織の商標ロゴ表示で「なりすましメール対策」「ブランディング」 「Brand Keeper（ブランドキーパー）」専用サイトをオープン 2021年7月12日にGoogleが適用を開始したメール新標準:BIMIと、DigiCertが提供開始するロゴマーク用の電子証明書新基準の電子証明書:VMCの実装・運用をサポートする新サービス 「Brand Keeper（ブランドキーパー）」の専用サイトを開設しました。 「Brand Keeper（ブランドキーパー）」