質問 Microsoft IISからエクスポートしたPKCS#12形式(.pfx)から、秘密鍵と証明書をエクスポートする方法を教えてください。 必ずお読みください 本文書の内容によって生じた結果の影響について、弊社では一切の責任を負いかねますこと予めご了承ください。 本文書は基本的な構成を想定しています。お客様のシステム環境や構成、設定状況などにより、手順や画面表示が変わることがあります。アプリケーション及びツールごとの仕様及び設定手順等のご不明な点は、製品のマニュアルをお読みいただくか、開発元にご確認ください。 Trust Lifecycle Managerではベンダーを問わず利用中のSSL/TLS証明書を一元管理できます。直観的な管理コンソールから自動更新、ユーザ管理、レポート、カスタム更新案内メールなどが設定可能。 回答 Microsoft IISからエクスポートされたPKCS#12
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 では「暗号化」「改ざん検知」「認証機能」を実現するために、SSL通信を開始する一番最初の部分（SSL/TLSハンドシェイク）に様々な技術を組み合わせています。 今回はこの「SSL/TLSハンドシェイク」の部分を解説します。 SSL/TLS ハンドシェイク図解 まずは簡単ですが SSL/TLS ハンドシェイクの部分を図にしました。 こうやってみると複雑そうなことをしているように見えますができる限り分かりやすく解説します。 SSLハンドシェイクで何をしているのかというと、 どの暗号化スイート（どの暗号化アルゴリズム）を使うのか一致させる データの暗号化に使用する鍵を確立させる 認証をする ということをやっています。 ①【クライアント側】使用可能な暗号スイートを提案する クライアントは、サーバーに Client Hello メッセージを送信してセッションを開始します。 「Clie
本家のストーリにもなっているが、認証局として知られる「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の人が出てきて、この再販業者からの発行を停止し
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
概要 HTTPSはend-endの暗号化をするため、エンドポイント以外では暗号化内容をデコードすることができません。自社アプリであれば、デバッガなどで当然暗号化される前、もしくは暗号化されて到着したデータをエンコード/デコード前後にアクセスできますが、他社製アプリやOSの通信などは、一般的には何がやりとりしているか、うかがい知ることはできません。wiresharkでは可能ですが、暗号化に使っている鍵を解析するために、サーバ証明書に含まれる公開鍵と対になる秘密鍵が必要です。 今回は中間者攻撃と呼ばれる手法を使って、httpsのトラフィックをデコードしてみます。 なぜ復号できるのか？ 上図はSSL暗号化通信が始まるまでのサーバとクライアントのやりとりをおおざっぱに示したものです。サーバ証明書は公開鍵を含み、公開鍵で暗号化したものは秘密鍵でしかデコードすることはできません（公開鍵暗号方式）。それ
Hitclub nổi bật như một biểu tượng trong làng game đổi thưởng trực tuyến, liên tục góp mặt trong các bảng xếp hạng thương hiệu đáng chú ý nhất năm 2025. Với sự hội tụ của hàng loạt siêu phẩm đổi thưởng đỉnh cao, nền tảng này khẳng định vị thế vững chắc trong cộng đồng game thủ và ngày càng chinh phục người chơi nhờ chất lượng vượt trội cùng trải nghiệm độc đáo. XEM THÊMGiới thiệu cơn sốt mang tên
各種ブラウザの 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 対策]
PostgresのViewを変更すときに気をつけることをまとめました。 Viewの更新について変更方法は２つあります。 １．Create OR Replaceで作成し同じくCreate OR Replaceで変更する ２．DROPして再度作りなおす １番が正攻法な気がしますが、公式ドキュメントに下記のような仕様があります。 「このコマンドでは、同じ名前のビューが既に存在している場合、そのビューを置き換えます。 新しい問い合わせは、既存のビュー問い合わせが生成する列と同じ列(つまり、同じ順序の同じデータ型の同じ列名)を生成しなければなりません。 しかし、そのリストの最後に列を追加しても構いません。 出力列を生成する計算をまったく異なるものにしても構いません。」 https://www.postgresql.jp/document/10/html/sql-createview.html なので
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
こちらでは初めまして、大阪で孤軍奮闘中の桶谷です。<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から公式見解はこちらで
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.
昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。 僕もちょっとそういうケース見かけました。 なんか Yahoo! Japan がポカしちゃったの？とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。 が、今回のケース、Yahoo! は全く悪くない！ プライバシーフリークはどうかと思うがな！！ では早速、今回起こったことを、振り返ってみましょう。 Yahoo! API にアクセスできなくなった Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用
興味をそそられたので読んでみました。 インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 作者: みやたひろし出版社/メーカー: SBクリエイティブ発売日: 2013/12/27メディア: 大型本この商品を含むブログ (4件) を見る 本書の内容は、ネットワークの物理的なレイヤーから、ネットワークプロトコルの概要、セキュリティ(主にSSL)や負荷分散や可用性の確保など、幅広い内容に及んでおり、それぞれの分野が網羅的に書かれています。各技術についても、すぐに古くなりがちな個別の実装の詳細に入るのではなく、プロトコルや設計ポリシーなど基礎的、基本的なところがしっかりと記述されており読み応えがあり、また数年単位で長持ちする知識が得られます。 例えば、第1章の「物理設計」では、機能分散や冗長化まで考慮された、具体的な機器の構成例まで図にしてあり参考になりますし、機種選定の方針までも
若者のプロトコル離れが叫ばれて久しいが、最近プロトコルは非常にホットな分野である。 目まぐるしく進化するWebに合わせ、プロトコルの世界も着実に進化している。 今までブラウザでは出来なかった事が出来るようになり、Webサービスをより安全に使えるようになった。 そしてWebのパフォーマンスを大きく改善するためにHTTP2.0も議論されている。 Webを支えるプロトコルとして、大きく分けて３つに分けられるかと思う（私の勝手なイメージ、正確な図ではありません） Webアプリケーション ブラウザが今まで出来なかったことを出来るようにしたり、Webアプリケーションの認証・認可などの機能を提供するプロトコルなど。JSやサーバサイドプログラミングで利用したりする。 WebSocket (http://tools.ietf.org/html/rfc6455) ブラウザとWebサーバの間でソケット通信を行う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く