再発行 SSL証明書
お問い合せ先： ケープコッド株式会社 所在地 〒359-0001 埼玉県所沢市下富1043-109 TEL 04-2942-5899 FAX 04-2942-5899 E-mail sales@onlinessl.jp お客様のご利用中のSSLサーバ証明書の秘密鍵・証明書が、HDDのクラッシュ等何かのトラブルにより失われた場合、またはシステム・メンテナンス等でシステム環境が変更となった場合、無料で再発行の手続きが行えます。 1.プロフェッショナルレベルGeoTrust証明書の再発行 以下のSSLサーバー証明書において、期限内であれば再発行が可能です。 QuickSSL QuickSSL Premium True BusinessID True BusinessID Wildcard 申し込みフォームより、必要事項をご記入の上 新しい"CSR"（Certificate Signing Req
CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
Heartbleed Bug
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private network
ImperialViolet - Apple's SSL/TLS bug
Yesterday, Apple pushed a rather spooky security update for iOS that suggested that something was horribly wrong with SSL/TLS in iOS but gave no details. Since the answer is at the top of the Hacker News thread, I guess the cat's out of the bag already and we're into the misinformation-quashing stage now. So here's the Apple bug: static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bo
SSL/TLSライブラリの正しい使い方（もしくは、コモンネームの検証について）
スマホアプリの市場拡大に伴い、直接SSL/TLSライブラリを使用するプログラムを書く機会も増えてきている今日この頃かと思います。 SSL/TLSライブラリを使う際には、接続確立時にサーバの認証を正しく行う必要があります。具体的には、クライアントプログラムで以下の２種類の検証を行うことになります。 SSL/TLSライブラリがサーバの証明書の検証に成功したこと サーバの証明書に含まれるコモンネーム注1が接続しようとしたサーバと同一であること 前者については、OpenSSLの場合はSSL_CTX_set_verifyの引数にSSL_VERIFY_PEERを指定するなどして、ライブラリ側で処理を行わせることが可能です（証明書の検証に失敗した場合はSSL_connectがエラーを返します）。 一方、後者についてはSSL/TLSライブラリによって差があり、検証機能を有効にするために特別な呼出が必要だっ
SSL Labs: Stricter Security Requirements for 2014 | Qualys Security Blog
Today, we’re releasing a new version of SSL Rating Guide as well as a new version of SSL Test to go with it. Because the SSL/TLS and PKI ecosystem continues to move at a fast pace, we have to periodically evaluate our rating criteria to keep up. We have made the following changes: Support for TLS 1.2 is now required to get an A. If this protocol version is not supported, the grade is capped at B.
OpenSSL is written by monkeys
Hi POODLE! And this is absolutely not the last one... I have been getting a ton of requests to make more comments so here goes. I told you so, la la la, I told you so! Joking aside, this is the worst security bug I have ever dealt with. Who knew that running crypto was worse than not running it at all? This is NOT the last catastrophic bug lurking in this code. Buyer beware, this will happen again
SSL/TLS の暗号アルゴリズムの決定メカニズムをパケットレベルで追いかけてみる - /dev/null blog
楽しいことを見つけると寝食を忘れてのめり込んでしまう、プラットフォーム・グループの坂井です。 最近は SSL/TLS のプロトコルを調べるのが楽しくて、RFC のドキュメントや関連書籍を読み漁っています。 SSL/TLS で通信するためには、クライアントとサーバの両者でどの暗号アルゴリズムを使うか決めなくてはなりません。ブラウザの種類やバージョン、サーバの設定や実装など、様々な要素から暗号アルゴリズムは決定されます。 暗号アルゴリズムの決定メカニズム 暗号化通信が開始されるまでにはハンドシェイクプロトコルに則った処理が行われますが、暗号アルゴリズムの決定は最初の 1 ターン目で決まります。 クライアントが利用可能な暗号アルゴリズムの一覧を送信 (Client Hello) サーバは送られてきた一覧から使用するアルゴリズムを決定 (Server Hello) クライアントは自分が使える暗号ア
TLS Protocol Version 1.2
ネットワーク WG Request for Comments： 5246 廃止： 3268, 4346, 4366 更新： 4492 分類： Standards Track このメモの位置づけ 本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。 このメモの配布に制限はない。 要旨 本書は、TLS（Transport Layer Security）プロトコルのバージョン 1.2 を規定する。TLS プロトコルは、インターネット上の通信セキュリティを提供する。このプロトコルは、クライアント／サーバアプリケーションが盗聴
Brian Picciano - Namecoin, A Replacement For SSL
We're running a kickstarter campaign to get cryptic.io, an encrypted online storage service, off the ground. Click here to check it out and lend your support! At cryptic.io we are creating a client-side, in-browser encryption system where a user can upload their already encrypted content to our storage system and be 100% confident that their data can never be decrypted by anyone but them. One of t
HTTP/2.0のALPN利用に伴うSSL負荷分散装置の不具合にご注意下さい - ぼちぼち日記
1. はじめに、 ただ今IETF-88@バンクーバーの開催が真っただ中です。スノーデン事件の余波もあり、インターネット技術（特にセキュリティ関連）の議論は熱くなっています。 ちょうど今朝未明（バンクバーでは11/5朝）に HTTP/2.0の標準化を進める httpbis ワーキンググループとセキュリティエリアの合同セッションが開催されました。合同セッションでは、ヘッダ圧縮技術(HPACK)のセキュリティや、HTTP接続(HTTPSではない）で通信の暗号化を行ったらどうか、といった興味深い議論が行われました。このうち将来HTTP/2.0の展開に重要な ALPN(Application Layer Protocol Negotiation) は、このミーティングで最終的な仕様を確定させる段階での議論でした。議論の中で、ALPNの導入によってブラウザから既存の実サービスへの接続に(少なからず)影
Security/Server Side TLS - MozillaWiki
The ordering of cipher suites in the Old configuration is very important, as it determines the priority with which algorithms are selected. OpenSSL will ignore cipher suites it doesn't understand, so always use the full set of cipher suites below, in their recommended order. The use of the Old configuration with modern versions of OpenSSL may require custom builds with support for deprecated ciphe
TLS - The Wireshark Wiki
This wiki has been migrated to https://gitlab.com/wireshark/wireshark/-/wikis/home and is now deprecated. Please use that site instead. Transport Layer Security (TLS) Transport Layer Security (TLS) provides security in the communication between two hosts. It provides integrity, authentication and confidentiality. It is used most commonly in web browsers, but can be used with any protocol that uses
SSL: Intercepted today, decrypted tomorrow | Netcraft
[September 2013: The Netcraft extension — for Firefox, Google Chrome, and Opera — now displays whether or not PFS is supported] Millions of websites and billions of people rely on SSL to protect the transmission of sensitive information such as passwords, credit card details, and personal information with the expectation that encryption guarantees privacy. However, recently leaked documents appear
Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010
As can be seen, Android 2.2.1 came with a set of AES256-SHA1 ciphers first, followed by 3DES and AES128. Android 2.3 significantly reduced the security by removing AES256 and putting the broken RC4-MD5 on the prominent first place, followed by the not-so-much-better RC4-SHA1. Wait... What? Yes, Android versions before 2.3 were using AES256 > 3DES > AES128 > RC4, and starting with 2.3 it was now: R
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fadis on Twitter: ""GnuTLS: 重大なバグ、僅かな実害" 新たに見つかった不具合は致命的だが、GnuTLSは以前から残念なSSL/TLSライブラリとして知られており、殆どのソフトウェアはOpenSSLを使っているため実害は限定的であるとする記事 http://t.co/3ya2SvMibG"
GnuTLS: Big internal bugs, few real-world problems
Testing OCSP Stapling | UNMITIGATED RISK
TLS “Secrets” / Whitepaper presenting the security implications of the deployment of session tickets(RFC 5077) as implemented in OpenSSL
RFC 5878: Transport Layer Security (TLS) Authorization Extensions