Unable to verify leaf signature
I'm using node.js request.js to reach an api. I'm getting this error [Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE] All of my credentials are accurate and valid, and the server's fine. I made the same request with postman. request({ "url": domain+"/api/orders/originator/"+id, "method": "GET", "headers":{ "X-API-VERSION": 1, "X-API-KEY": key }, }, function(err, response, body){ console.log(err); console.
SSL/TLSの解説 【Part.2】 SSL/TLS ハンドシェイクの内部構造【図解】
SSL/TLS ハンドシェイク図解 まずは簡単ですが SSL/TLS ハンドシェイクの部分を図にしました。 こうやってみると複雑そうなことをしているように見えますができる限り分かりやすく解説します。 SSLハンドシェイクで何をしているのかというと、 どの暗号化スイート（どの暗号化アルゴリズム）を使うのか一致させる データの暗号化に使用する鍵を確立させる 認証をする ということをやっています。 ①【クライアント側】使用可能な暗号スイートを提案する クライアントは、サーバーに Client Hello メッセージを送信してセッションを開始します。 「Client Hello」です。 クライアントはサーバーのWebサイト（https://www.yahoo.co.jp など）にアクセスをします。 その際にクライアントは、クライアントがサポートしている暗号スイート一覧をサーバーへ送信します。
Comodo CAがサーバ証明書を関係のない第三者に発行、大問題に | スラド セキュリティ
本家のストーリにもなっているが、認証局として知られる「Comodo」のアウトソース先の証明書販売業者が、mozilla.com用のサーバ証明書を関係のない第三者に発行してしまう事件が発生したようだ（eWeekの記事「SSL Certificate Vendor Sells Mozilla.com Cert to Some Guy」、mozilla.dev.tech.cryptoグループに掲載されている事件の経緯）。 これをやらかしたのは「Certstar」というComodoの再販業者のようだ。StartComのEddy Nigg氏がこの再販業者に対してmozilla.com用のサーバ証明書の取得を試みたところ、何の本人確認手続きもなしに証明書が発行され手に入ってしまったのだそうだ。mozilla.dev.tech.cryptoでは、Comodoの人が出てきて、この再販業者からの発行を停止し
SSL証明書を発行する企業が証明書を偽造する悪質なアドウェア「Privdog」を販売していたことが判明
COMODO Internet SecurityなどのPC向けセキュリティツールの開発や、SSL証明書の発行を行うComodoが販売していたソフトウェアの「Privdog」は、Lenovo製PCにプリインされているアドウェア「Superfish」よりも悪質なアドウェアで、HTTPSのセキュリティを完全に破壊してしまう危険性があるということが、ドイツ人ジャーナリストのHanno Böckさんのブログ内で明かされました。 Comodo ships Adware Privdog worse than Superfish - Hanno's blog https://blog.hboeck.de/archives/865-Comodo-ships-Adware-Privdog-worse-than-Superfish.html Lenovo製のノートPCにプリインストールされているソフトウェア「V
JmeterでHTTPSをMITM Proxyとして使い暗号通信内容をぶっこ抜く - Qiita
概要 HTTPSはend-endの暗号化をするため、エンドポイント以外では暗号化内容をデコードすることができません。自社アプリであれば、デバッガなどで当然暗号化される前、もしくは暗号化されて到着したデータをエンコード/デコード前後にアクセスできますが、他社製アプリやOSの通信などは、一般的には何がやりとりしているか、うかがい知ることはできません。wiresharkでは可能ですが、暗号化に使っている鍵を解析するために、サーバ証明書に含まれる公開鍵と対になる秘密鍵が必要です。 今回は中間者攻撃と呼ばれる手法を使って、httpsのトラフィックをデコードしてみます。 なぜ復号できるのか？ 上図はSSL暗号化通信が始まるまでのサーバとクライアントのやりとりをおおざっぱに示したものです。サーバ証明書は公開鍵を含み、公開鍵で暗号化したものは秘密鍵でしかデコードすることはできません（公開鍵暗号方式）。それ
歌うキツネ : 各種ブラウザの SSL 3.0 プロトコル を無効にする
各種ブラウザの SSL 3.0 プロトコル を無効にする その1. 有効/無効の状態の確認 | その2. 有効/無効の設定 | その3. DROWN/FREAK/Logjam について その1. 有効/無効の状態の確認 Webブラウザの SSL/TLS プロトコルバージョンの、有効/無効の状態を確認をするWebサイトの例。 QUALYS' SSL LABS にアクセスする。 SSL 3 が無効の状態の例。（画像はクリックで拡大します。） SSL 3 が有効の状態の例。（画像はクリックで拡大します。） その2. 各種ブラウザの SSL/TLS の有効/無効の設定 IE | Firefox | Google Chrome | Opera 15 以降 | Opera 12 まで | Safari | Vivaldi Internet Explorer Microsoft: [POODLE 対策]
RMS-099のブックマーク - はてなブックマーク
発達障害について ～発達障害傾向を持つ社員を指導する時のポイント～ 会社から相談を受けた時の一例 本人は発達障害の傾向について気づいていないこともある 「社員のAさんが少し心配です。」 「なぜですか？」 「他の社員と違うんです。」 「どんあところが違うんですか？」 「例えば・・・ 暗黙のルールや社会人としての常識がわからない、話したことをすぐに忘れる、周りと協力することができない、スケジュール管理ができない、注意したらパニックになる、空気が読めない、何回指導しても自分のやり方を変えない、etc. これは障害なのでしょうか。 本人は発達障害の傾向について気づいていないこともある 会社から相談を受けた時の一例 「指導の仕方に問題はありませんか？」 「＃＄％＆＊！！ちゃんと指導しています。 パワハラもしていないし、これまで同じようなことはありませんでした！！！ 本人に困っていることがないか聞いて
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
OpenSSLの脆弱性への対応方法（AWSサービス/OSごと） - サーバーワークスエンジニアブログ
こちらでは初めまして、大阪で孤軍奮闘中の桶谷です。<br /> 現在、話題になっているOpenSSLの脆弱性への対応方法をまとめてみました。 ※随時更新中。最終更新 2014/04/11 12:29 OpenSSLに脆弱性、クライアントやサーバにメモリ露呈の恐れ http://www.itmedia.co.jp/enterprise/articles/1404/08/news038.htm こちらに今回の脆弱性についての説明動画があります http://vimeo.com/91425662 The Heartbleed Bug http://heartbleed.com/ 対応を行わないとクライアント/サーバ間の通信が悪意のある第三者に覗かれる恐れがあり、痕跡を残さずにトラフィックの内容、ユーザーID/パスワードなどが盗まれてしまう可能性があります。 AWSから公式見解はこちらで
Symantec SSL Toolbox
Check your CSR Remove cross certificates View browser warnings Check certificate installation Search certificate logs Check your SSL/TLS certificate installation Enter the URL of the server that you want to check.
Y!J API が止まった日 - GlobalSign の Root 証明書切れから学んだこと - OAuth.jp
昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。 僕もちょっとそういうケース見かけました。 なんか Yahoo! Japan がポカしちゃったの？とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。 が、今回のケース、Yahoo! は全く悪くない！ プライバシーフリークはどうかと思うがな！！ では早速、今回起こったことを、振り返ってみましょう。 Yahoo! API にアクセスできなくなった Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用
AWSユーザーにもお勧めできる「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門」 - stanaka's blog
興味をそそられたので読んでみました。 インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 作者: みやたひろし出版社/メーカー: SBクリエイティブ発売日: 2013/12/27メディア: 大型本この商品を含むブログ (4件) を見る 本書の内容は、ネットワークの物理的なレイヤーから、ネットワークプロトコルの概要、セキュリティ(主にSSL)や負荷分散や可用性の確保など、幅広い内容に及んでおり、それぞれの分野が網羅的に書かれています。各技術についても、すぐに古くなりがちな個別の実装の詳細に入るのではなく、プロトコルや設計ポリシーなど基礎的、基本的なところがしっかりと記述されており読み応えがあり、また数年単位で長持ちする知識が得られます。 例えば、第1章の「物理設計」では、機能分散や冗長化まで考慮された、具体的な機器の構成例まで図にしてあり参考になりますし、機種選定の方針までも
Webを支えるプロトコル - ASnoKaze blog
若者のプロトコル離れが叫ばれて久しいが、最近プロトコルは非常にホットな分野である。 目まぐるしく進化するWebに合わせ、プロトコルの世界も着実に進化している。 今までブラウザでは出来なかった事が出来るようになり、Webサービスをより安全に使えるようになった。 そしてWebのパフォーマンスを大きく改善するためにHTTP2.0も議論されている。 Webを支えるプロトコルとして、大きく分けて３つに分けられるかと思う（私の勝手なイメージ、正確な図ではありません） Webアプリケーション ブラウザが今まで出来なかったことを出来るようにしたり、Webアプリケーションの認証・認可などの機能を提供するプロトコルなど。JSやサーバサイドプログラミングで利用したりする。 WebSocket (http://tools.ietf.org/html/rfc6455) ブラウザとWebサーバの間でソケット通信を行う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PKCS#12（pfx）形式から、秘密鍵、公開鍵形式への変換方法
Next step, AWS! ～ OpenSSLのバージョンをアップデートする。｜ゆゆ｜note
Comodo SSL Checker - SSL/TLS Certificates Checker Tool
SSLv3 Poodle Attack Check
Qualys SSL Labs - Projects / SSL Client Test
Firefox/Google Chromeの標準接続方式を“HTTPS”へ変更する「HTTPS Everywhere」NOT SUPPORTED
OpenSSLの“出血バグ”を抱えているサイト、「.jp」ではHTTPSサイトの45％ 