中間CA証明書はCertCentralよりダウンロードしてください。 参考:サーバIDインストール手順 (-----BEGIN CERTIFICATE-----) から (-----END CERTIFICATE-----) までをコピーし、そのままテキストエディタに貼り付けます。 中間CA証明書保存例 貼り付け完了後、中間CA証明書ファイルとして任意のファイル名で保存します。 例: intermediate.crt 保存した中間CA証明書ファイルを設定ファイルで指定します。
中間CA証明書はCertCentralよりダウンロードしてください。 参考:サーバIDインストール手順 (-----BEGIN CERTIFICATE-----) から (-----END CERTIFICATE-----) までをコピーし、そのままテキストエディタに貼り付けます。 中間CA証明書保存例 貼り付け完了後、中間CA証明書ファイルとして任意のファイル名で保存します。 例: intermediate.crt 保存した中間CA証明書ファイルを設定ファイルで指定します。
デベロッパーツールと Wireshark のキャプチャーを紐づける方法を紹介します。 手順 (Chrome で試しています) 1. Chrome を起動し、「その他のツール」から「デベロッパーツール」を起動します。 2.「ネットワーク」タブに移動し、タイトルの列を右クリックし「接続 ID」にチェックを入れます。 *タイトルが表示されていない場合は、任意のサイトを開き HTTP の接続を実施すると表示されます。 3. 新しいタブで chrome://net-export を開き (Edge の場合は edge://net-export で開けます。)「Start Logging to Disk」をクリックします。 4. ログを保存するために、任意のパスを開きます。 5. Wireshark でパケットキャプチャーを開始します。 6. デベロッパーツールのタブで、キャプチャーしたいアクセスを実
設定前の準備 まず、SSL復号化ができているかどうかを確認するため、トラフィックログのフォーマットを変更します。 Monitor > ログ > トラフィックへ移動し、左上にカーソルを当てると、下矢印が表示されるので、クリックします。すると、カラムという文字が表示されますので、復号化にチェックを入れます。 以下のように、復号化のカラムが追加されます。先頭に配置されますので、ドラッグにより好きなところに配置してください。今回は復号化のテストに使用するので、先頭に配置します。 端末からGoogle、Twitter、Youtubeへアクセスしてみます。復号化されていない(no)であることが確認できます。 自己署名ルートCA証明書(Self-Signed Root CA Certificate)作成 今回は、エンタープライズCAによって署名された証明書ではなく、Paloaltoが自己署名した証明書を
最近ではSSL Decryption(復号)機能は殆どのUTM/Proxy製品が対応していると思います。Palo Altoの場合、SSL Decryptionに3種類の方式があるため、要件に応じて使い分ける必要があります。 (1) SSL Forward Proxy 一般的なSSL Decryption機能であり、ClientからServer向けのSSL通信上にProxyとして存在します。サーバ証明書をPalo Altoが再署名(発行元、RootCAとして署名)するため、クライアントのWebブラウザにPalo Altoの証明書をインポートしなければなりません。また、TAPモードでは使用出来ません。 #公的証明書をインストールすればクライアントのWebブラウザにインストールしなくてもよいとマニュアルには書いてあるんですが出来ないらしい、、Palo自体に証明書自体入りませんでした。 (2)SS
WebサーバのHTTPS化において、SSL/TLS周りの各種設定はどう選択するべきか(2016年度版)SecuritySSLHTTPSTLS 公開HTTPSサーバを立てるときに悩む点の一つが、SSL/TLS周りの設定です。 SSL/TLSや暗号周りの知識がないと適切な設定を選ぶのは難しい そもそも設定が何を意味しているのか読み取れない 「推奨される設定」が各種サイトでいくつも、微妙に違うものが紹介されていて、どれが良いのか選べない とりわけ暗号が関連する選択肢は呪文めいていて、専門知識を持たないWebエンジニアにとっては、なかなか難しいものがあると思います。 筆者もSSL/TLSの専門家ではありません。 専門家でないなりに極力信頼できそうなソースや実例を参考にしつつ、まとめました。もともとは自分用調査資料集のような記事です。 すごく長くなってしまいました(若干力尽きている)。 TL;DR
AES-CTRの時に出てきたDTLSについて調べてみた。DTLSはRFC4347になっているようなので、それを読んでみた時の各章ごとのメモ(意訳?)です。 RFC 4347 Datagram Transport Layer Security 1. Introduction TLSは広く普及しているけどTCPのような信頼性があるチャンネル上でしか使えない。しかし最近ではSIPやゲームのようにUDPを使うことも多くなってきた。このようなケースでは今一つな選択肢しかない。一つ目はIPsecだが、これは使える用途が限られている。二つ目は自分で作ることだが、セキュリティのことを考えると大変でありTLSのように楽ではない。 そのためdatagramでもTLSのようなものがあるのが望ましい。ここではDTLSというTLSに似せて作ったプロトコルについて記載する。 2. Usage Model カーネルの変
御社の常時SSL (TLS) への対応はお済みですか。というわけで本稿ではRFCで標準化されているプロトコルのうち、SSL (TLS) に対応済みのものを列挙していきたいと思います。 用語の定義 本稿では、以下の用語を使います。 Implicit TLS (暗黙のTLS) TCPコネクション開始と同時にTLSセッションがいきなり始まる方式です。httpsなどはこれです。平文通信用と暗号通信用に別々のポートを割り当てる必要がありますが、そのぶん低レイテンシーを実現できます。 Explicit TLS (明示的TLS) TCPコネクションが確立すると、最初は平文で通信が始まり、そこからTLSへ移行する方式です。STARTTLSとか、そんな感じのコマンドが用意されているのがこれです。特徴としては、平文通信と暗号通信を同じポートでカバーできます。平文で始まって暗号へ切り替わるという手順を踏む分、レ
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書(1)』と『#5 X.509 証明書(2)』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名(前提知識) この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
Google Chrome で自組織のCAで署名したSSL証明書のサイトにアクセスすると NET::ERR_CERT_COMMON_NAME_INVALID エラーメッセージが表示される - Windows Google Chrome で自組織のCAで署名したSSL証明書のサイトにアクセスすると NET::ERR_CERT_COMMON_NAME_INVALID エラーメッセージが表示される現象について紹介します。 現象の確認 自組織のCAで署名したSSL証明書を利用したWebサイトを作成します。作成したWebサイトにMicrosoft Edgeでアクセスします。Webページが表示されます。 Internet Explorer でアクセスします。こちらも問題なくページが表示されます。 しかし、Google Chromeでアクセスするとエラーになり、下図の画面が表示されます。"NET::ER
If you are having a problem with your SSL certificate installation, please enter the name of your server. Our installation diagnostics tool will help you locate the problem and verify your SSL Certificate installation.
仕事でTLS関連のトラブルがあったが全然基礎知識がなかったので1から学んだ。この記事は特にTLSの仕様を解説したいわけではなくどこを参照してまだかメモっておく。僕が解説するよりそっちを参照したほうが確実。 まずSSLとTLSの違いすらわからないレベルだったのでウィキペディア読んだ。 Transport Layer Security - Wikipedia ウィキペディアがいいのは常に更新されているところで、例えばPOODLE攻撃とか比較的最近のトピックも網羅されている可能性が高い。ウィキペディアで得た知識だけでPOODLE攻撃がわかるかというと微妙だけどインデックスは貼れる。 今回の問題はハンドシェイクに問題があるとわかっていたのでハンドシェイクの詳細が知りたい。ウェブ上の記事だと SSL/TLS(Part.1) (1/3):不正アクセスを防止するSSL/TLS(2) - @IT が一番詳
$ curl -s -v --sslv3 https://example.com 1> /dev/null * Rebuilt URL to: https://example.com/ * Trying 93.184.216.34... * Connected to example.com (93.184.216.34) port 443 (#0) * SSL peer handshake failed, the server most likely requires a client certificate to connect * Closing connection 0 おっと、SSLハンドシェイクで通信に失敗したようですね。SSL3.0はPOODLE脆弱性問題があります。ちゃんとexample.comでは無効にしているようですね。以下のようにTLS1.2ではきちんとできました。Di
本ページの情報は2019年4月時点のものです。 2015年5月、独立行政法人情報処理推進機構(以下、「IPA」という。)では、暗号技術評価プロジェクトCRYPTREC の活動を通じ、オンラインショッピング、インターネットバンキング、ネットトレードなどのサービスで使用するSSL (Secure Socket Layer) /TLS (Transport Layer Security) プロトコルの適正な利用促進を目的として、SSL/TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするため、SSL/TLS暗号設定ガイドライン (以下「設定ガイドライン」という。)を公開しました。 その後、一般に販売されているSSL/TLSを利用するアプライアンス製品(以下、SSL/TLSアプライアンス製品という)の設定方法等への要望が多数寄せられたため、SSL/TLSに関してどの
3rdに引っ越しました。 2010/12/31 以前&2023/1/1 以降の記事を開くと5秒後にリダイレクトされます。 普段の日記は あっち[http://thyrving.livedoor.biz/] こちらには技術関係のちょっとマニアックな記事やニュースを載せます。 Windows2000ネタ中心に毎日更新。 MicrosoftのTLS 1.2サポートに関する発表のフォローアップとして、Windows Embedded POSReady 2009およびWindows Embedded Standard 2009のTLS1.1 / TLS 1.2のサポートが、2017年10月17日現在ダウンロードできるようになりました。 お客様の環境でこれらの新しいプロトコルのサポートに対する強い要求があることを認識してこのサポートを提供しています。 Windows Embedded POSReady
各ブラウザや、OpenSSL・BoringSSLといった暗号ライブラリ、ミドルウェアのTLS1.3対応が進んでおり、実際に通信できるところまで来ている。 標準化としても大詰めを迎えている。 前回のIETFより話題に上がっている、TLS1.3に関するDC内での復号を目的とした議論について、新しく「TLS 1.3 Option for Negotiation of Visibility in the Datacenter」という拡張仕様が出ている。 これが割りと盛り上がっているので簡単に整理する TLS1.3 拡張仕様の話に入る前に、簡単にTLS1.3の現状について触れる。 TLS1.3は、0-RTTハンドシェイクのサポートといったパフォーマンスの改善と、多くのセキュリティ改善が入ったTLSの次期バージョンである。 仕様としても長い間議論されており、draft-21まで出ている。ラストコールま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く