CentOS6でLet’s Encryptを使おうとするとpython2.7が入らずに詰まる | PCがあれば何でもできる！
無料でSSL証明書が発行できると話題のLet’s Encrypt。 先日、CentOS6のサーバに試しに入れてみようとしたところ、python2.7が入らずに詰まってしまいました。 最初に OSはCentOS 6.7で、gcc, git, nginx以外ほとんど入っていない状態。 導入の参考にしたのはこちらのサイト。 nginxの設定など細かく書いてくださっているので、非常に参考になります。 光の速さのWEBサーバー(nginx)をlet's encryptでSSL化及びHTTP/2化。ついでにセキュリティ評価をA＋にする。 – Qiita 現象 Gitでclone後、letsencrypt-autoを叩くと、必要なものが自動でインストールされるわけなのですが、virtualenvがなくて止まります。 $ git clone https://github.com/letsencrypt/l
LINE Bot API の HTTPS Callback は Amazon API Gateway を使うと簡単便利安価で最高 - おともだちティータイム
追記 (4/15) 現在は Let's Encrypt の証明書が利用できるようになっているようです。なので「https で Callback が受け取れない」と言う理由のためだけに Amazon API Gateway を使う必要も無くなりました。 LINE Bot API は Callback URL が https のみで、しかも Let's Encrypt や StartSSL と言った無料の証明書が使えない。どうにか安価で Bot を動かしたいとなると Heroku のようなドメインを指定しなければ Wildcard 証明書が割り当てられている PaaS を使うのが一般的でしょう。 しかし Heroku は外に抜ける IP アドレスがどんどん変わっていくので、 Bot API の IP Whitelist に登録することが出来ない。仕方無いので Heroku に rack-rev
自堕落な技術者の日記 : 様々なサーバーのPOODLE SSLv3脆弱性(CVE-2014-3566)対策のまとめ(更新3) - livedoor Blog（ブログ）
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 もくじ 1. はじめに 2. SSLv3を無効化できる場合のサーバー対策 2.1. Apache HTTPD Server + mod_ssl 2.2. Apache HTTPD Server + mod_nss 2.3. nginx 2.4. lighttpd 2.5. Microsoft IIS 2.6. (訂正)Apache Tomcat (Java JSSE) 2.7. Node.js 2.8. IBM HTTP Server 2.9. Amazon Web Services 2.10. その他のサーバー 2.11. SSLv3 を無効化するリスク 2.12. OpenLDAP 3. 諸般の事情で SSLv3 を有効にせざるを得ない場
OpenVPN設定 - 鍵と証明書の作成
OpenVPNでは、サーバー、クライアントともに鍵と証明書を使って認証処理を行います。では、サーバー、クライアントの鍵と証明書の作成方法をご案内しましょう。 ※ 以下の手順は必要なときにその都度行えますが、ログインごとにvarsコマンドを実行してから各手順を行なってください。varsコマンドによる環境変数の設定はログアウトでリセットされます。 1. OpenVPNサーバー用の鍵と証明書の作成 OpenVPNサーバーの鍵と証明書を作るには build-key-server コマンドを実行します。引数としてこの証明書に使用する共通名（Common Name）を設定します。 [root@localhost 2.0]# ./build-key-server server Generating a 1024 bit RSA private key ..........................
RSA鍵、証明書のファイルフォーマットについて - Qiita
RSAの公開鍵暗号技術を利用するためには、鍵や証明書のファイルを扱う必要があるため、そのファイルフォーマットについて理解しておく必要があります。 実際、いろんな拡張子が登場するので、それぞれの意味を理解していないとすぐにわけがわからなくなります。そんなときのために備忘録をまとめてみました。 ファイルの拡張子の注意点 .DERと .PEMという拡張子は鍵の中身じゃなくて、エンコーディングを表している デジタル暗号化鍵やデジタル証明書はバイナリデータなのですが、MD5のハッシュ値のような単なる 値 ではなく、データ構造をもっています。.DERや .PEMはそのデータ構造をどういうフォーマットでエンコードしているかを表しています。そのため、.DERや.PEMという拡張子からそのファイルが何を表しているのかはわかりません。暗号化鍵の場合もあるし、証明書の場合もあります。 .DER 鍵や証明書をAS
八丁堀の旦那 » Apache+OpenSSLによる CSRの作成とSSL証明書インストール
■CSR作成 まずは、CSRの作成手順ですが、結構いろいろと説明しているサイトがあるのですが、どれも微妙に違うところがあってわかりにくかったので、私が実際にやったやり方を記録しておきます。 ちなみに、今回の私の環境は、さくらインターネットのVPSで、CentOS5+Apache2の環境です。 証明書は、RapidSSLでapacheとOpenSSLはインストールしてある状態です。 さて、まずはじめにCSR作成の途中で入力しなければならない次の項目についてあらかじめ準備しておきます。 コモンネーム sample.jp confまでのパス /etc/httpd/conf/ 秘密鍵ファイル名 samplejp.2011.key 秘密鍵ファイル名(パスフレーズ) samplejp.2011_withpass.key CSRファイル名 samplejp.2011.csr 証明書ファイル sample
CentOS6などで俺俺CAとSHA2証明書を作るときのメモ - Qiita
参考 - Redhatのガイド：https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Virtualization/3.3/html/Developer_Guide/appe-Certificates.html ここよりも参考になりそうなQiitaの記事がありました： http://qiita.com/mako10z/items/ef15372d4cf4621a674e Motivation 普通はオフィシャルな文書を見ればいいのだけど、RHEL6互換のOSでは署名のアルゴリズムがSHA1がデフォルトとして/etc/pki/tls/openssl.cnfに記載されているため、明示的に指定する必要があるので、備忘としてメモ。 CentOS7へ移行してもいいのかもしれませんが、まだ試していません。 CAから作り直すケー
Logjam Attack対策
HTTPSというかTLSで新しく見つかった脆弱性が話題になっている？ので対策をしてみた。 Diffie-Hellman 鍵交換に関する脆弱性に対する攻撃の様でLogjam Attackという名前だそうです。 TLS接続の暗号強度を512にビット下げられてしまうので盗聴されやすくなるとのこと。 SSL/TLSをサポートするトップ100万ドメインのうち、約18%にこの脆弱性があるということなので結構影響範囲大きそうです。 取り敢えずDHグループを2048ビット以上で作成するのとDHE_EXPORTを拒否にすれば良いようです。 ただし、Apache2.4系やNginxは素直にそれで良いようですが、Apache2.2はダメそう。 Apache2.2の場合は以下のようにDHEを無効にするという対策にしました。
CentOS6＋NginxでECDHEを有効にしてForward Secrecy取得までのメモ - 不意に何かを残すブログ
昨日は鍵共有を甘く見て爆死したためCentOS＋NginxのサーバーをWindows環境に対応させてみる。 RPMに慣れていた都合上、主なサーバーにCentOS6を使っている。 CentOS/RHEL6.4では2013年10月時点で、標準のOpenSSLは1.0.0、Nginxは1.0系が導入される。Nginxには公式リポジトリもあるが、openssl-1.0.0を前提にビルドされている。 これらはコミュニティサポートのあるRPMで提供されているものの、NginxでHTTPSサーバーを建てようとすると、TLSはv1.0 まで、対応cipherはDHE-RSA-AES-SHAまでになり、QualsysのSSLテストでは色々と指摘される。 問題点 既存のパッケージで対策不能なのは、TLS1.2対応（兼BEAST対策）とRSA鍵共有。 BEASTは未対策のブラウザがTLSv1.0以前のCBCモー
Logjam Attack 対策を行う : アジャイル株式会社
Webサーバ確認 The Logjam Attack に、 Logjam Server Test のリンクがあります。 ここでサーバの脆弱性テストが行えます。 Guide to Deploying Diffie-Hellman for TLS Guide to Deploying Diffie-Hellman for TLS の Test A Server 欄にチェックしたい サーバのURLを入力し、[ Go ] ボタンをクリックします。 Insecure DHE_EXPORT が No になっていない ( Supported! の ) 場合、Logjam 脆弱性の影響を受ける事になります。 No の場合でも、DHE が 2048 ビット未満の場合には警告表示がなされるようです。 この場合、同ページ下に対策 ( 後述 ) が記されるので、サーバの要件等に従って対策を行うか検討しましょう。
エラーコード: ssl_error_weak_server_ephemeral_dh_key - 今日も頑張りました。
*****.jp への接続中にエラーが発生しました。 SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (エラーコード: ssl_error_weak_server_ephemeral_dh_key) 受信したデータの真正性を検証できなかったため、このページは表示できませんでした。 この問題を Web サイトの管理者に連絡してください。 先日まで見られていたのに、突然ページが見られなくなった。 どうもFirefoxのバージョンが変わって、セキュリティが厳しくなったせいらしい。 スマホでつないだら、 「このサイトのセキュリティ証明書には問題があります ×この証明書は信頼できる認証機関のものではありません」 とかってアラームが出た。（Android2.3.3） で
Logjam Attackについてまとめてみた - piyolog
Diffie-Hellman（DH）鍵交換の脆弱性を使ったTLSプロトコルに対する攻撃「Logjam Attack」に関する情報をまとめます。 脆弱性概要 脆弱性の概要情報は次の通り。 愛称 Logjam Attack (攻撃手法の愛称) Webサイト https://weakdh.org/ アイコン 無し CVE CVE-2015-1716(Microsoft) 発見者名 次の合同チームにより発見 フランス国立科学研究センター(CNRS) フランス国立情報学自動制御研究所(INRIA) Microsoft Research ジョンズホプキンス大学 ミシガン大学 ペンシルバニア大学 Logjam Attackの概要 Diffie-Hellman（DH）鍵交換の脆弱性。この脆弱性を用いて中間者攻撃が行われている環境において、TLS接続を512bitの輸出グレード暗号にダウングレードし、通信経
SSL証明書のKEYファイル・CSRファイル・CRTファイルのチェック方法 - install memo
SSL証明書の発行プロセスでは、KEYファイルとCSRファイルを作ることになります。また、証明書会社からはCRTファイルが送られてきます。これらが正しいかどうかをチェックする方法を紹介します。 KEYファイルとは KEYファイルというのが正式名称だとは思えませんが、ここではSSL通信に利用する公開鍵暗号系の秘密鍵ファイルを指します（おそらく公開鍵情報も含んでいるんだと思いますが、このあたりはよくわかっていません）。 秘密鍵ファイルは次のようなヘッダ・フッタを利用します。 -----BEGIN RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----下記のようにすれば、KEYファイルが正しいかどうか確認できます。 $ openssl rsa -in ssl_example_jp.key -check -noout verify OK $ CSRファ
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
SSL証明書をSHA–1からSHA–2に更新する際にはご注意を！ | さくらのナレッジ
現在SSL証明書の署名アルゴリズムがSHA–1からSHA–2へと変更になる過渡期となっています。今後はSSL証明書の新規取得や更新を行う際にはSHA–2の証明書を取得することになると思いますが、いつも通りの慣れた作業と思っていると、思わぬところでハマるかも知れません。 今回は実際に更新作業をした経験を踏まえて取得/更新作業の注意点について簡単にまとめてみました。 そもそもなぜSHA–2に移行する必要があるのか？ 署名アルゴリズムがSHA–1の証明書は非推奨となり、ゆくゆくは廃止となる流れとなっています。基本的にSHA–1の証明書は2017年1月1日以降使えなくなると考えてよいでしょう。そして2016年12月31日までにSHA–2に移行する必要があります。 詳細はここで説明すると長くなりますので、次のようなSSL証明書の発行元のサイトの解説を参照してください。 SHA–1証明書の受付終了とS
5分でわかる正しい Web サイト常時 SSL 化のための基礎知識
Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな～ と思って書いてみた、恒例の （？） 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Auto renew SSL Certificate with Certbot(Let’s Encrypt)
Let'sEncryptの取得&自動更新設定してみた(CentOS7.1&Apache2.4.6) - Qiita
ApacheのSNIについて [がらくたネット]
XOOPSでユーザ登録やログイン画面等だけSSL対応する.htaccess - Qiita
