java - https URL を開くときのエラー: keyCertSign ビットが設定されていません

Question

次のコードでリモート https URL を呼び出しています。

   def inputStream = new URL("https://somewebsite.com").openStream()

これは私のローカルマシンでは問題なく動作しますが、サーバーに展開すると、次の例外が発生します。

java.security.cert.CertPathValidatorException: CA key usage check failed: keyCertSign bit is not set

このエラーの原因は何ですか? また、あるマシンでは動作していて別のマシンでは動作していない理由は何ですか?

アップデート

私は本番環境でUbuntuサーバーを実行しており、Macでローカルに開発しています。アクセスしようとしているサイト (peopleware.com と呼びましょう) には、次の証明書情報があります。

AddTrust 外部 CA ルート
UTN-USERFirst-Hardware
ピープルウェア.com

ブラウザーから .cer ファイルを保存して、/etc/ssl/certs/java/castore のキーストアにインストールしようとしました

score 5 · Accepted Answer

UTN-USERFirst-Hardware からのこの証明書について話していると思います。

人間が読めるバージョンでは：

Version: 3 (0x2)
Serial Number:
    44:be:0c:8b:50:00:24:b4:11:d3:36:2a:fe:65:0a:fd
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware
Validity
    Not Before: Jul  9 18:10:42 1999 GMT
    Not After : Jul  9 18:19:22 2019 GMT
Subject: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware
Subject Public Key Info:
    [...]
X509v3 extensions:
    X509v3 Key Usage: 
        Digital Signature, Non Repudiation, Certificate Sign, CRL Sign
    X509v3 Basic Constraints: critical
        CA:TRUE
    X509v3 Subject Key Identifier: 
        A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45
    X509v3 CRL Distribution Points: 

        Full Name:
          URI:http://crl.usertrust.com/UTN-USERFirst-Hardware.crl

    X509v3 Extended Key Usage: 
        TLS Web Server Authentication, IPSec End System, IPSec Tunnel, IPSec User

基本的に、ここにはとの両方を持つ CA 証明書がX509v3 Key UsageありX509v3 Extended Key Usageます。

ただし、RFC 3280 では、拡張されたキー使用法の拡張について次のように述べています。

一般に、この拡張機能はエンドエンティティ証明書にのみ表示されます。

これは CA 証明書にはあまりうまくいきませんが、後で同じセクションで次のようにも述べられています。

証明書にキー使用拡張と拡張キー使用拡張の両方が含まれている場合、両方の拡張を個別に処理する必要があり、証明書は両方の拡張と一致する目的にのみ使用する必要があります。両方の拡張機能と一致する目的がない場合、証明書をいかなる目的にも使用してはなりません (MUST NOT)。

この RFC にあるこの証明書の唯一の拡張キー使用拡張は、TLS Web サーバー認証です。

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

もちろん、これは、keyCertSignRFC 3280 (および RFC 5280) によると一貫性がありません。(また、IPSec 拡張機能のいずれかがと互換性があるとは思えませんkeyCertSign)。これにより、この証明書は証明書を発行するのに役に立たなくなります (CA 証明書にはあまり役に立ちません)。

この証明書を使用して Web サイトに連絡し、CA (UTN-USERFirst-Hardware、明らかに Comodo) に連絡して、これを修正するように依頼します。これらの RFC を利用してお金を稼いでいる人々から来るのは見栄えがよくないと言わざるを得ません。

もちろん、これには時間がかかる可能性があり、当面の問題は解決しません。

このサブジェクト DN (UTN-USERFirst-Hardware) は他の中間 CA 証明書で見たことがあると思うので、上記のものはあなたが使用しているものではないかもしれません。

（これらの問題にもかかわらずサーバー証明書自体を手動で検証できる場合）できることは、この接続にを使用し、その証明書を使用するようSSLContextにTrustManager特に制限されていることです。これにより、証明書パスアルゴリズムが発行者証明書を見つけようとするのを妨げ、この問題に陥る可能性があります。

編集：

この回避策の詳細は次のとおりです (接続を安全に保つ必要があります)。

Firefox でこの Web サイトに接続します。
青/緑のバーをクリックして、[詳細情報...] を選択します。
セキュリティ -> 証明書の表示 -> 詳細
上部のリストからサーバー証明書を選択し、[エクスポート...] を選択します。
どこかのPEMファイルと同じです。

新しいキーストアを作成するために使用keytoolします (その証明書を信頼し、適切なパスワードを選択することを選択します)。

keytool -importcert -keystore example.jks -file example.pem

次に、次の Java コードを使用します。Groovy に移植するのはそれほど難しくありません。

TrustManagerFactory tmf = TrustManagerFactory
    .getInstance(TrustManagerFactory.getDefaultAlgorithm());
KeyStore ks = KeyStore.getInstance("JKS");
FileInputStream fis = new FileInputStream("/.../example.jks");
ks.load(fis, null);
// or ks.load(fis, "thepassword".toCharArray());
fis.close();

tmf.init(ks);

SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(null, tmf.getTrustManagers(), null);

URL url = new URL("https://somewebsite.com");
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setSSLSocketFactory(sslContext.getSocketFactory());

InputStream is = conn.getInputStream();

java - https URL を開くときのエラー: keyCertSign ビットが設定されていません

1 に答える 1

Related

Reference