web-dev-qa-db-ja.com

16.04でApt-get SSLクライアント証明書が機能しない（ファイルの読み取り中にエラーが発生する）

同じ動作中のSSLクライアントキー/証明書と/etc/apt/apt.conf.d/01_https_client_certルールを（動作中の）14.04 VMから新しい16.04インストールに移植しました。

SSLクライアント証明書を使用して、curlを介してaptリポジトリにアクセスできますが、apt-get updateはこのエラーを表示します。

6% [Working]* Hostname example.com was found in DNS cache
*   Trying 11.22.33.44...
* Connected to example.com (11.22.33.44) port 443 (#29)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 697 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* error reading X.509 key or certificate file: Error while reading file.
* Closing connection 29
Ign:5 https://example.com/apt release/main all Packages

/etc/apt/apt.conf.d/01_ssl_client_authは両方のシステムで同じです：

Debug::Acquire::https "true";
Acquire::https::example.com::SslCert "/opt/example/keyring/ssl_client.crt";
Acquire::https::example.com::SslKey "/opt/example/keyring/ssl_client.key";

許可は両方のマシンで同じです：

ubuntu@ubuntu:~$ namei -mo /opt/example/keyring/ssl_client.crt
f: /opt/example/keyring/ssl_client.crt
 drwxr-xr-x root    root    /
 drwxr-sr-x ubuntu ubuntu opt
 drwxrwsr-x ubuntu ubuntu example
 drwxrws--- ubuntu ubuntu keyring
 -rw-rw---- ubuntu ubuntu ssl_client.crt

トリビア：

  1. 01_ssl_client_authルールを削除すると、予想される403禁止応答が返されます（リポジトリにはクライアント証明書が必要なため）

  2. curlは次のようにうまく機能します。

    curl --cert /opt/example/keyring/ssl_client.crt --key /opt/example/keyring/ssl_client.key https://example.com/apt/

Connected to example.com (11.22.33.44) port 443 (#0)
found 173 certificates in /etc/ssl/certs/ca-certificates.crt
found 697 certificates in /etc/ssl/certs
ALPN, offering http/1.1
SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
     server certificate verification OK
     server certificate status verification SKIPPED
     common name: *.example.com (matched)
     server certificate expiration date OK
     server certificate activation date OK
     certificate public key: RSA
       (snip)
ALPN, server did not agree to a protocol
GET /apt/ HTTP/1.1
Host: example.com
User-Agent: curl/7.47.0
Accept: */*

HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Wed, 18 May 2016 01:18:30 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive

  3. そしてもちろんapt-getとcurlは両方とも同じapt.conf.dと証明書で元のシステムで動作します...

他に見なければならないものはありますか？ apt-getなどでcrt/keyからpemへの変更はありましたか？

aptsslhttpstls
3
summerhat83

https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Apt_1.2 から詳細を見つけることができるはずです。

推奨される設定は、証明書とキーを別のディレクトリにコピーし、ユーザーのアクセス許可を

_apt：nogroup

構成する

apt_transport_https

新しいパスを使用するようにセットアップします。

Acquire::https::cdn-mirror.insnw.net::CaInfo "/new/path/ca.crt";
Acquire::https::cdn-mirror.insnw.net::SslCert "/new/path.crt";
Acquire::https::cdn-mirror.insnw.net::SslKey  "/new/path.key"";
1
davidls

Aptは、パーミッションをドロップして_aptユーザーとして実行しようとします。その切り替えがいつ発生したかは覚えていませんが、かなり最近のものでした（つまり、14.04以降の可能性が高い）。だから、あなたと同じように私の同様の問題を修正した（つまり、a+rxが使用したかった証明書に至るまでのすべてのディレクトリで_aptが利用可能であったことを確認した） veは問題を正しく特定しました。

1
frrisus