Memo

メモ > サーバ > 各論: SSL証明書 > SSLの導入

■SSLの導入
■大まかな流れ 1. 秘密鍵を作成する 2. 秘密鍵をもとにCSRを作成する 3. CSRをもとに証明書を発行する(SSL証明書を購入する) 4. 発行された証明書を、秘密鍵とセットでサーバに組み込む 証明書を発行する際、その内容が妥当かどうかはルート証明書の公開鍵が使われる ルート証明書の秘密鍵が流出するとすべてのSSL証明書の再発行が必要になって影響が大きいので、中間証明書を間に挟む ルート証明書は通常ブラウザに組み込まれているが、中間証明書は組み込まれていない よって証明書とともに、中間証明書もサーバに組み込む必要がある ルート証明書の秘密鍵は、攻撃による流出を避けるためオフラインで管理される ■SSL用に鍵を作成する
# cd /etc/httpd/conf/ # openssl genrsa -des3 -out ssl.key/refirio.net.20170417.key 2048 … 秘密鍵を生成 # openssl req -new -key ssl.key/refirio.net.20170417.key -out ssl.csr/refirio.net.20170417.csr … CSRを生成 Country Name (2 letter code) [XX]:JP State or Province Name (full name) []:Tokyo Locality Name (eg, city) [Default City]:Shibuya Organization Name (eg, company) [Default Company Ltd]:refirio.net Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:refirio.net Email Address []:refirio@example.com # openssl rsa -in ssl.key/refirio.net.20170417.key -out ssl.key/refirio.net.20170417.key … 秘密鍵からパスワード削除 # openssl rsa -in ssl.key/refirio.net.20170417.key -pubout > /path/to/public.20170417.key … 秘密鍵から公開鍵を生成する場合(参考までに。今回は不要)
これで秘密鍵とCSRを作成できた SSL証明書を購入する際は、このうちCSRの情報を登録する 購入が完了すると、証明書と中間証明書を入手できる 今回はそれぞれ refirio.net.20170417.crt と refirio.net.20170417.ca として保存するものとする
# cd /etc/httpd/conf/ # vi ssl.crt/refirio.net.20170417.crt … 入手した証明書を配置 # vi ssl.crt/refirio.net.20170417.ca … 入手した中間証明書を配置
一例だが、以下のようにしてApacheに組み込む 証明書関連の設定以外や設定箇所は、あくまでも一例
# vi /etc/httpd/conf.d/virtualhost.conf … Apacheの設定ファイルから各ファイルを指定
<VirtualHost *:443> ServerName refirio.net DocumentRoot /var/www/vhosts/main/html ErrorLog logs/ssl_error_log TransferLog logs/ssl_access_log LogLevel warn SSLEngine on SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile /etc/httpd/conf/ssl.crt/refirio.net.20170417.crt … 証明書を指定 SSLCertificateKeyFile /etc/httpd/conf/ssl.key/refirio.net.20170417.key … 秘密鍵を指定 SSLCertificateChainFile /etc/httpd/conf/ssl.crt/refirio.net.20170417.ca … 中間証明書を指定 <Directory "/var/www/vhosts/main/html"> Options Includes FollowSymLinks ExecCGI AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost>
# systemctl restart httpd … Apacheを再起動
完了したらブラウザからアクセスし、証明書の有効期限を確認する 以降では、このSSL用のファイルについて詳細を確認する ■SSHでの認証用に鍵を作成する場合(参考までに。SSL証明書には不要)
$ cd $ ssh-keygen -t rsa … 鍵タイプRSAの鍵を作成 $ cd /home/refirio/.ssh $ cp id_rsa.pub authorized_keys $ chmod 600 authorized_keys
認証用に id_rsa (秘密鍵)と id_rsa.pub (公開鍵)が作成される 同じ場所に authorized_keys が配置されていることがあるが、これは認証済みの id_rsa.pub が記録されるファイル アクセス元で id_rsa.pub を作成した場合、その内容を authorized_keys に追記しておけばアクセス元に id_rsa.pub は不要 (アクセス元が一つなら、authorized_keys と id_rsa.pub の内容は同一になる) id_rsa はアクセス元のどこに置いても大丈夫だが、セキュリティ上パーミッションを0600にしておかないと使えない これで秘密鍵 /home/refirio/.ssh/id_rsa をダウンロードして、接続時に鍵ファイルとして指定すれば、 SSHで refirio ユーザとして鍵認証で接続できる Linuxコマンド【 ssh-keygen 】認証用の鍵を生成 - Linux入門 - Webkaru https://webkaru.net/linux/ssh-keygen-command/ ssh公開鍵認証を実装する - Qiita https://qiita.com/HamaTech/items/21bb9761f326c4d4aa65 ■セキュリティビット数について 鍵を作成する際に2048という数を指定しているが、これがセキュリティビット数 脆弱性の知られていない共通鍵暗号を破るには、攻撃者はパターンを総当たりに試す必要がある この試行回数を基準として、2のべき乗として尺度にしたものがセキュリティービット数 例えば64ビットの場合、2の64乗(1844京6744兆737億955万1616)パターンの鍵を持つことになる なお公開鍵暗号はその性質から、秘密鍵のビット数で表現できる数値のすべてが鍵になるわけでは無い 暗号スイートの暗号強度と、公開鍵のビット数の設定、及びRSAとECDHEでサーバ負荷の比較 - Apache 2.4系でHTTP/2対応サーバを構築してみるテスト。 https://http2.try-and-test.net/ecdhe.html なお、2の2048乗を計算すると以下になる 無量大数が10の68乗なので、もはや名前がつかない巨大な数になる 32317006071311007300714876688669951960444102669715 48403213034542752465513886789089319720141152291346 36887179609218980194941195591504909210950881523864 48283120630877367300996091750197750389652106796057 63838406756827679221864261975616183809433847617047 05816458520363050428875758915410658086075523991239 30385521914333389668342420684974786564569494856176 03532632205807780565933102619270846031415025859286 41771167259436037184618573575983511523016459044036 97613233287231227125684710820209725157101726931323 46967854258065669793504599726835299863821552516638 94373355436021354332296046453184786049521481935558 53611059596230656 ■SSL証明書の安全性と有効期限 RSAは、桁数が大きい合成数の素因数分解問題が困難であることを安全性の根拠とした暗号化方式 例えば二つの素数の積「19 × 37 = 703」を求めることは容易だが、素数の積から二つの素数「703 = 19 × 37」を求めるには総当たりで計算するしか無い 桁数が少なければ計算は難しくないが、桁数が多くなると計算に時間がかかる とは言え時間をかければ計算できるので、SSL証明書には通常1年の有効期限が設けられている コンピュータの性能向上の影響で、SSL証明書の有効期限は徐々に短く設定されるようになっている またSSL証明書の署名に不備があったなどで大量の証明書を失効せざるを得ない場合、 有効期限は短ければ短いほど影響範囲は少なくて済む 有効期限は今後も短くなっていく可能性がある 証明書の差し替え作業を機械的にできるようにするか、自動更新できるようにするなどの検討が必要 何度も短縮し過ぎ?!SSL証明書の有効期間がどんどん短くなる理由とは? | さくらのSSL https://ssl.sakura.ad.jp/column/shortened-ssl/ ■量子コンピュータについて 上記のように、共通鍵暗号を破るにはパターンを総当たりに試す必要がある 現在のコンピュータではこの総当りを現実的な時間で行えないため、これが安全性の根拠となっている ただし現在は量子コンピュータが研究されていて、これが実用化されると現在のSSL通信は解読されてしまう可能性がある SSL通信も量子コンピュータの前では無意味に? 今から備えるべき「耐量子コンピュータ暗号」とは - ITmedia NEWS https://www.itmedia.co.jp/news/articles/1911/15/news072.html 量子コンピュータによる暗号解読を防ぐためには、規格が定まり、導入可能になったらすぐに導入すること とされている

Advertisement