wiki:TipAndDoc/ssl

  1. how to secure
  2. mod_ssl
  3. SSL 証明書の作り方
    1. with ubuntu hardy
      1. rootCA
      2. 新しい証明書
        1. 新しい証明書への署名
      3. 作成物
      4. 参考
  4. misc

how to secure

  • ​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.

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証明書

参考

misc

  • ​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).
Last modified 7 years ago Last modified on Jun 21, 2018 2:04:59 AM