Ubuntuでは、証明書の署名に使用する秘密鍵(nginxで使用)の最適な場所は/etc/ssl/private/
にあるようです。
この answer は、証明書を/etc/ssl/certs/
に入れる必要があることを追加していますが、安全ではないようです。 .crt
ファイルは安全に保管する必要がありますか、それとも公開と見なされますか?
.crtファイルは、接続するすべてのものに送信されます。それは公開されています。 (chown root:root
およびchmod 644
)
秘密鍵の場所に追加するには、適切に固定するとともに、そこに保管してください。 (chown root:ssl-cert
およびchmod 640
)
秘密鍵ファイルを適切に保護する限り、どこに置いてもかまいません。 公開証明書は公開されています;保護は必要ありません-サーバー権限など。
答えを拡大するために、デフォルトの場所/etc/ssl
は使用しません。
バックアップなどの理由により、すべての鉱山を別の場所に保管する方が簡単です。
Apache SSLの場合、私は/etc/Apache2/ssl/private
または/etc/
の同様の「ルート領域」に保管します。
この投稿はUbuntu(Debian)+ Apacheを対象としていますが、ほとんどのシステムで機能するはずです-
特定の構成(Apache/nginx/etc)でアクセス許可を適用し、場所/パスを更新するだけです。
SSLキーファイルが正しく保護されている場合(ディレクトリとファイル)、問題ありません。メモに注意してください!
Sudo mkdir /etc/Apache2/ssl
Sudo mkdir /etc/Apache2/ssl/private
Sudo chmod 755 /etc/Apache2/ssl
Sudo chmod 710 /etc/Apache2/ssl/private
注:chmod 710
はUbuntuでssl-cert
グループをサポートします。(コメントを参照)700
に対する/etc/Apache2/ssl/private
への権限の設定も正常に機能します。
publicwww ssl証明書と中間証明書を
/etc/Apache2/ssl
に入れます
PUTprivatessl key(s)in/etc/Apache2/ssl/private
Sudo chown -R root:root /etc/Apache2/ssl/
Sudo chown -R root:ssl-cert /etc/Apache2/ssl/private/
注:
ssl-certグループがない場合は、上の行で 'root:root'を使用するか、2行目をスキップしてください。
公開証明書
Sudo chmod 644 /etc/Apache2/ssl/*.crt
秘密鍵
Sudo chmod 640 /etc/Apache2/ssl/private/*.key
注:
Ubuntuのssl-certグループのため、グループの権限はREAD(640)に設定されています。 「600」も問題ありません。
Sudo a2enmod ssl
(最後の段落を参照)*
Sudo nano /etc/Apache/sites-available/mysiteexample-ssl.conf
Sudo a2ensite mysiteexample-ssl
# ^^^^^^^^^^^^^^^^^ <-Substitute your ".conf" filename(s)
Sudo service Apache2 restart
または
Sudo systemctl restart Apache2.service
*これも問題を超えていますが、デフォルトのApache SSLサイト構成ファイル(Sudo cp /etc/Apache2/sites-available/default-ssl.conf /etc/Apache2/sites-available/mysiteexample-ssl.conf
)を良い出発点としてコピーできます/シンプルな(Ubuntu/Debian)Apache /で通常使用されるデフォルトのディレクティブ/ディレクトリの例/ SSL「conf」ファイル。通常、自己署名SSL証明書+キー(スネークオイル)、CAバンドル、および特定のSSLサイトで使用される一般的な ディレクティブ を指します。
コピーした後、新しい.confファイルを編集し、必要に応じて上記の新しい情報/パスで追加/削除/更新してから、Sudo a2ensite mysiteexample-ssl
を実行して有効にします。
ここでの答えはすべて問題ないようですが、問題の1つが見つかったことに言及したいと思います...中間ファイルまたはルートを使用して証明書を連結し、チェーンファイルを作成する必要がある場合は、しないでください = /etc/ssl/certs
に入れます。c_rehash
を実行すると、ルートまたは証明書内の中間物が原因で、証明書へのハッシュシンボリックリンクが作成される場合があるためです。
その後、証明書の有効期限が切れて証明書を削除し、c_rehash
を再実行するかどうかわからない場合は、/etc/ssl/certs
ディレクトリのハッシュシンボリックリンクが壊れている可能性があり、奇妙なことが起こり始めますローカルマシンがSSL経由で自分自身に接続しようとし、検証対象のルートが見つからない場合。たとえば、curlを使用して、突然次のようになりました。
curl: (60) SSL certificate problem: unable to get issuer certificate
/etc/ssl/certs
にあった古い.crtおよび連結された.pemファイルをクリーンアップした直後。
少なくともチェーンを別の場所に保存すると、この問題を回避できます。証明書とチェーンを保持するために/etc/ssl/local_certs
を作成することにしたので、/etc/ssl/certs
にあるCA証明書の混乱からそれらが失われることはありませんでした。
個々のファイル/ディレクトリのアクセス許可がchown root :0 private.key
やchmod 600 private.key
のように設定されていて、rootだけが読み取ることができれば、実際には危険な場所はありません。あなたが言うように、CSRと証明書ファイルはそれほど敏感ではありません。
これらの権限があれば、あなたが言及するパスと/ usr/local/sslは問題ないはずです。
場所が正しい:
/etc/ssl/certs/
for .crt
ファイル/etc/ssl/private
for .key
ファイル所有者は両方でroot:root
でなければなりません(必要に応じてSudo chmod root:root <file>
を使用して変更します)。
権限:
644
for .crt
ファイル600
for .key
ファイルこれはnginx
で機能します。