だから私は2つのWebサーバー(古いWebサーバーと新しいサーバー)を管理します。古い URL は古い URL を使用し、新しい URL は新しい URL を使用し、両方とも内部的に署名されます。
既存の証明書にあるHTTPS証明書が期限切れになって確認してみたところ、1ヶ月残りましたが、認証機関が内部マシンなので無効であると認識されました。
ただし、類似した内部署名証明書を持つ新しいサーバーは、他の内部機関によって署名されても有効であると見なされます。
新しい証明書は問題ありませんが、古い証明書ではない理由を見つけようとします。新しい証明書に私が認識しないいくつかの魔法があります。たとえば、署名チェーンの最終的な親証明書は、私のCAでよく知られている証明書の1つですが、.crtを要求すると表示されません。 )または署名チェーンに慣れていない内容があります。 (内部)parent.crtが私のUbuntuクライアントのCA証明書に追加されました。
UbuntuデスクトップまたはCentosクライアントでどのcliコマンドを使用して把握できますか?新しい.crtが機能する理由が証明書がデスクトップにインストールされているためである場合、その証明書がインストールされている場所を見つけることができます(そして他のCentosシステムにコピーするにはどうすればよいですか)。
両方のサーバーのチェーンを識別しようとすると、openssl s_client -connect -showcerts
最終的に内部署名機関CNになります。証明書をダウンロードして実行しましたが、openssl verify -verbose -issuer_checks
認識する親権限は表示されません。 www.google.comで同じタスクを実行し、おなじみの「GeoTrust Global CA」親エントリを取得したので、ローカルCA証明書に内部親権限を追加したいのですが、どうすればわかりますか?
すべての場合に最終権限があると報告されたCNはDNS名ではないため、どこかでその.crtをダウンロードできません。私が持っているのは新しいURLにある.crtのコンテンツだけなので、openssl
次から証明書を検索できます。明らかに、親.crtを使用するCNは私のローカルCA証明書にありません。おそらくopensslが有効であると結論付けるために内部的にこれを行っているのでしょうか?
編集:私のChrome(libnss3)証明書にマスターキーが追加されているようです。 Chrome外でサポートされるように同じマスターキーを追加するために必要なもの(例:cliのphpとopenssl)
答え1
誰かがより良い答えを考えることができる場合は、そうしてください。しかし、私が見つけた最高の答えは次のとおりです。 http://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html
/usr/share/ca-certificates
私のUbuntuデスクトップでは、これが証明書のデフォルトの場所であることがわかりましたが、私が探している場所は、私のキーチェーンの親ホスト名と一致する名前を /usr/local/share/ca-certificates
使用して検索して見つけました。find -iname "*<NAME>*"
また、私のデスクトップのChromeは証明書を有効であると認識していましたが、一部のCLIツール(opensslを含む)はそうでないことも発見しました。そのため、libnss
ChromeがCA権限で使用しているように見えるアイテムに追加するために、ドキュメントでこのコマンドへの参照を見つけました。
certutil -d sql:${HOME}/.pki/nssdb/ -A -t "C,," \
-n "<CERTIFICATE NAME>" \
-i /usr/local/share/ca-certificates/<CERTIFICATE>.crt
上記のgfiリンクには、ubuntu / centosでCA証明書を管理するのに非常に便利なコンテンツが含まれています。以下は私たちの内部wikiのために私が書いたものです: -
Linux(Ubuntu、Debian)
次へ追加
- CAをディレクトリにコピーします。
/usr/local/share/ca-certificates/
- 使用コマンド:
sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt
- CAストアアップデート:
sudo update-ca-certificates
削除する
- CAを削除してください。
- CAストアアップデート:
sudo update-ca-certificates --fresh
Linux(CentOs 6)
次へ追加
- CA証明書パッケージをインストールします。
yum install ca-certificates
- 動的CA構成機能を有効にする:
update-ca-trust force-enable
- 次の場所に新しいファイルとして追加します
/etc/pki/ca-trust/source/anchors/
。cp foo.crt /etc/pki/ca-trust/source/anchors/
- 使用コマンド:
update-ca-trust extract
これにより、他の人が情報を見つける時間を節約できることを願っています。
答え2
strace
openssl
最終的には、サーバー証明書を検証する信頼できるCA証明書が見つかる場所を特定するのに役立ちます。
$ strace -fe open,openat openssl s_client -connect www.google.com:443 > /dev/null
[...]
openat(AT_FDCWD, "/usr/lib/ssl/certs/1001acf7.0", O_RDONLY) = 4
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = www.google.com
verify return:1
read:errno=0
+++ exited with 0 +++
$ openssl x509 -noout -subject < /usr/lib/ssl/certs/1001acf7.0
subject=C = US, O = Google Trust Services LLC, CN = GTS Root R1
$ ls -l /usr/lib/ssl/certs/1001acf7.0
lrwxrwxrwx 1 root root 15 Oct 30 2020 /usr/lib/ssl/certs/1001acf7.0 -> GTS_Root_R1.pem
$ dpkg -S /usr/lib/ssl/certs/1001acf7.0(:P)
ca-certificates: /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
(:P)
上記は/usr/lib/ssl/certs/1001acf7.0です。ここで、1001acf7は、システムの正規ルートCAリスト(正規絶対パスを取得するために使用されるzsh glob修飾子)の一部である証明書のタイトルのハッシュです。 。