web-dev-qa-db-ja.com

自己署名証明書が信頼されていません

私は自分のCAを作成しました：

openssl genrsa -out private/rootCA.key 2048
openssl req -batch -new -x509 -nodes -key private/rootCA.key -sha256 -days 1024 -config ./openssl.conf -out certs/rootCA.pem

私は自分のサイトの証明書を作成しました：

openssl genrsa -out private/$domain.key 2048
openssl req -batch -new -key private/$domain.key -config ./openssl.conf -subj "/commonName=$domain" -out csr/$domain.csr
openssl x509 -req -in csr/$domain.csr -CA certs/rootCA.pem -CAkey private/rootCA.key -CAcreateserial -out certs/$domain.crt -days 500 -sha256

サイト証明書とルート証明書をバンドルに参加させます。

cat certs/$domain.crt certs/rootCA.pem > bundles/$domain.bundle.crt

Cert/keyをnginxconfigdirにコピーします。

cp bundles/$domain.bundle.crt private/$domain.key /etc/nginx/conf/certs

Nginxが自分のサイトでこれらの証明書を使用していることを確認します。

    ssl_certificate /etc/nginx/certs/mysite.bundle.crt;
    ssl_certificate_key /etc/nginx/certs/mysite.key;

Nginxを再起動します。

システムにルート証明書をインストールします。

Sudo cp certs/rootCA.pem /usr/local/share/ca-certificates/myrootCA.crt
Sudo update-ca-certificates

httpieで確認します。

"http https：// mysite

http: error: SSLError: HTTPSConnectionPool(Host='mysite', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),))

opensslで確認します（デフォルトでは使用されていないように見えるca-certificates dirを使用するように指示します）：

openssl s_client -Host mysite -port 443 -prexit -showcerts -CApath /usr/local/share/ca-certificates

それは与える：

Verify return code: 19 (self signed certificate in certificate chain)

そして、検証は完了しません。

Chromeでサイトを開くと、標準エラーが発生します。

このサーバーは、それがmysiteであることを証明できませんでした。そのセキュリティ証明書は、コンピュータのオペレーティングシステムによって信頼されていません。これは、設定の誤りまたは攻撃者が接続を傍受したことが原因である可能性があります。

2つの質問があります：

  1. ルート証明書をインストールした後、システム全体でサイトが信頼されないのはなぜですか？ Chromeはシステム全体の証明書を使用していますよね？
  2. なぜopen_ssl s_client証明書の検証を完了できませんか？

編集

Curlは機能しており、システム全体にインストールされた証明書を使用しています。

curl https://mysite

カールが機能し、chrome/httpieが機能しないのはなぜですか？

linuxubuntusslcertificatehttps
1
dangonfast

OpenSSLの場合 Ubuntu update-ca-certificatesは、そのマニュアルページで説明されているように/usr/share/ca-certificatesおよび/usr/local/share/ca-certificatesからを読み取りますが、subjhash）でシンボリックリンクを書き込みます.nu​​m名が必要 OpenSSLから/etc/ssl/certsおよび/etc/ssl/certs/ca-certificates.crt内の結合ファイルであるため、後者の2つはそれぞれ-CApathおよび/または-CAfileとともに使用する必要があります。

curlは明らかにOpenSSLのデフォルトを使用しています。このビルドでは/etc/ssl/certs/ですが、Ubuntuによっては、コマンドラインs_clientがデフォルトを自動的に使用しないというバグがあるほどOpenSSLが古い場合があります。

Chromeの場合仕方がない;私はUbuntuではChromeを使用していません。他の誰かが使用できる場合に備えてCWを残しました。

CAが信頼できるようになるとわかりますが、最近のChromeにはserver証明書も必要です（PKI用語では、 End Entity = EE = not CA）は、正しい名前のSAN拡張子（SubjectAlternateNames）を持っていますが、他のどちらも（今のところ）そうではありません。 /どのようにそれを行ったか。（拡張：）HTTPSおよびCABforum標準のrfc2818は、10年以上にわたって、有効なSANを含むサーバー証明書を必要としており、現在ではすべてまたはほぼすべてのクライアントuseSAN存在する場合、しかし私の知る限り、これまでのところChromeはrequiresSAN存在する。

1
dave_thompson_085

自己生成されたルートCAが間違っていたようです。それが欠けていた：

basicConstraints               = CA:TRUE

これを解決した後、httpieは適切に動作しています。 curlがこれについて不平を言っていなかったのは不思議です。

これはまだChromeの問題を解決していませんが、... Chromeはシステム全体のCAを使用していないと思います。

0
dangonfast