[[PageOutline]] * [http://cert.startcom.org/ StartCom Free SSL Certification Authority] * [http://cryst.tv/experiment/StartComFreeSSL_Certificate/StartCom_Free_SSL_Certificate.html StartCom Free SSL Certificate] * [http://blog.le-coeur.net/archives/403 SSL 無料 認証機関 (CA) StartCom 使用方法 | 頭脳外部メモリー 「独学で趣味を満喫」] * [http://d.hatena.ne.jp/int128/20090117/1232124815 OpenSSLの証明書作成スクリプト(CA.sh)を理解する - GeekFactory] = how to secure = * [https://www.ssllabs.com/ssltest/ Qualys SSL Labs - Projects / SSL Server Test] * wikipedia:Transport_Layer_Security#Dealing_with_RC4_and_BEAST > The best choice is to only allow TLS 1.1 and TLS 1.2, but Firefox only supports TLS 1.0 and SSL 3.0 and Opera and Internet Explorer have support for TLS 1.1 and TLS 1.2 disabled by default. In most web servers, only one cipher can be assigned as the preferred cipher. Choosing RC4 is still the best choice for TLS 1.0, but not for TLS 1.1 and TLS 1.2. Choosing AES (CBC cipher) is secure for TLS 1.1 and TLS 1.2, but not for TLS 1.0 due to the BEAST attack. * [http://blog.yjl.im/2013/12/disabling-tlsssl-rc4-in-firefox-and.html YJL: Disabling TLS/SSL RC4 in Firefox and Chrome] = mod_ssl = * mod_ssl の設定 * [http://d.hatena.ne.jp/kiririmode/20081214/p1 mod_ssl のディレクティブ - 理系学生日記] = SSL 証明書の作り方 = == with ubuntu hardy == * install openssl * /etc/ssl/openssl.cnf /usr/lib/ssl/misc/CA.sh を適宜変更 * 対象は 0.9.8g-4ubuntu3.7 -> [2] * 修正箇所は -> [3] * CA.sh を使った場合、カレントディレクトリに「demoCA」というディレクトリが作られる * 違うディレクトリ・ファイル名にする場合は、45行目前後を変更する (今回はデフォルトのまま) {{{ CATOP=./demoCA CAKEY=./cakey.pem CAREQ=./careq.pem CACERT=./cacert.pem }}} === rootCA === * この作業はルート認証局を作る時に一回だけ行う * rootCA: $ sudo /usr/lib/ssl/misc/CA.sh -newca {{{ Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:Ibaraki Locality Name (eg, city) []:Tsukuba Organization Name (eg, company) [Internet Widgits Pty Ltd]:Private CA for mitty.jp Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:Private CA for mitty.jp Email Address []: }}} * ここで、「Organization Name」は後で作るサーバ証明書とは違う物にしておく * 「Common Name」はサーバ証明書ではサーバのFQDNだが、ルートCA証明書の場合はドメインでなくて良い * rootCA: $ sudo openssl x509 -inform pem -in ./demoCA/cacert.pem -outform der -out ./demoCA/cacert.der * ブラウザインポート用のルートCA証明書(任意) === 新しい証明書 === * newserver <= 新しいSSL証明書を作成したいサーバ * rootCA <= ルートCA証明書を保持しているルート認証局サーバ * Country -> C * State or Province Name -> ST * Locality Name -> L * Organization Name -> O * Organizational Unit Name -> OU * Common Name -> CN * newserver: $ sudo /usr/lib/ssl/misc/CA.sh -newreq {{{ Enter PEM pass phrase: <= type password (1) Verifying - Enter PEM pass phrase: <= retype it ----- Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:Ibaraki Locality Name (eg, city) []:Tsukuba Organization Name (eg, company) [Internet Widgits Pty Ltd]:mitty.jp Organizational Unit Name (eg, section) []:laboratory Common Name (eg, YOUR name) []:lab.mitty.jp <= (2) Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: <= type nothing An optional company name []: Request is in newreq.pem, private key is in newkey.pem }}} * (1) ここでtypeするパスワードは実際には使用されない * (2) Common Nameに実際に使用するFQDNを入れるが、「*.mitty.jp」の様に指定するといわゆる「ワイルドカード証明書」になる。 * ルートCAへ送付する、サーバ証明書リクエストファイルとサーバ秘密鍵を作成 * newserver: $ sudo openssl rsa -in ./newkey.pem -out ./newkey.pem {{{ Enter pass phrase for ./newkey.pem: <= type password (1) }}} * (1) -newreq の時と同じパスワードをtype * サーバ秘密鍵からパスフレーズの削除 (Apacheが起動する際にパスフレーズを聞かれなくてすむようにする) ==== 新しい証明書への署名 ==== * newserverからrootCAへnewreq.pemをコピーする。この時、コピー先はrootCA上でdemoCAがあるディレクトリにすること。 * rootCA: $ sudo /usr/lib/ssl/misc/CA.sh -sign {{{ Enter pass phrase for ./demoCA/private/cakey.pem: <= type rootCA's password (1) Signed certificate is in newcert.pem }}} * (1) ルートCAを作った際の秘密鍵のパスフレーズをtype * サーバ証明書がnewcert.pemとして作成される * rootCA: $ sudo openssl x509 -in newcert.pem -out newcert.crt * サーバ証明書から必要な部分だけを切り出す === 作成物 === * ./newkey.pem サーバ秘密鍵 * ./newcert.crt サーバ証明書 * ./demoCA/cacert.der (作った場合)サーバ証明書に対するルートCA証明書 === 参考 === * [http://www.aconus.com/~oyaji/www/certs_linux.htm SSL用証明書の作成(Linux編)] * [http://tkns.homelinux.net/memo/mandrivalinux10.1/openssl.html Memo of the OpenSSL] * [http://d.hatena.ne.jp/rudeboyjet/20070124/p1 Debian etchでSSL - よしだメモ] * [http://www.shitomi.jp/ubuntu804/apache.html Apache (Webサーバー)/Ubuntu 8.04] * [http://tdiary.ishinao.net/20070222.html#p02 (SSL)(バーチャルホスト) SSLで名前ベースのバーチャルホスト - いしなお!(2007-02-22)] * [http://ash.jp/sec/openssl.htm OpenSSLについて] opensslコマンドの引数について * [https://www.verisign.co.jp/ssl/help/csr/capache_new.html Apache + OpenSSL CSR生成手順 (新規)|CSRの生成|日本ベリサイン] * [http://d.hatena.ne.jp/shammer/20091029/1256837992 OpenSSLで証明書を承認する - Shammerism] * [http://d.hatena.ne.jp/int128/20090117/1232124815 OpenSSLの証明書作成スクリプト(CA.sh)を理解する - GeekFactory] = misc = * [http://old.nabble.com/How-to-pass-a-Client-Certificate-through-a-Reverse-Proxy-td9368919.html Nabble - Apache HTTP Server - Users - How to pass a Client Certificate through a Reverse Proxy] {{{ [warn] Proxy client certificate callback: (servername:443) downstream server wanted client certificate but none are configured }}} * > It seems as if the reverse proxy isn't passing through the client certificate from the browser. I realise that it is possible to setup the reverse proxy with a client certificate, but I need the client certificate to come from the client's browser. * Yes, because a client can only send its certificate by using encrypted and SIGNED connection, and only the client can sign the certifikate so server can trust it. The proxy does not know the clients private key, otherwise the connection would not be secure (or not in the way most people know that).