6

次のコードでリモート 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 と呼びましょう) には、次の証明書情報があります。

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

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

4

1 に答える 1

5

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

-----BEGIN CERTIFICATE----- 
MIIEdDCCA1ygAwIBAgIQRL4Mi1AAJLQR0zYq/mUK/TANBgkqhkiG9w0BAQUFADCB
lzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2Ug
Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho
dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3Qt
SGFyZHdhcmUwHhcNOTkwNzA5MTgxMDQyWhcNMTkwNzA5MTgxOTIyWjCBlzELMAkG
A1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe
MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v
d3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3QtSGFyZHdh
cmUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx98M4P7Sof885glFn
0G2f0v9Y8+efK+wNiVSZuTiZFvfgIXlIwrthdBKWHTxqctU8EGc6Oe0rE81m65UJ
M6Rsl7HoxuzBdXmcRl6Nq9Bq/bkqVRcQVLMZ8Jr28bFdtqdt++BxF2uiiPsA3/4a
MXcMmgF6sTLjKwEHOG7DpV4jvEWbe1DByTCP2+UretNb+zNAHqDVmBe8i4fDidNd
oI6yqqr2jmmIBsX6iSHzCJ1pLgkzmykNRg+MzEk0sGlRvfkGzWitZky8PqxhvQqI
DsjfPe58BEydCl5rkdbux+0ojatNh4lz0G6k0B4WixThdkQDf2Os5M1JnMWS9Ksy
oUhbAgMBAAGjgbkwgbYwCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wHQYD
VR0OBBYEFKFyXyYbKJhDlV0HN9WFlp1L0sNFMEQGA1UdHwQ9MDswOaA3oDWGM2h0
dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUhhcmR3YXJlLmNy
bDAxBgNVHSUEKjAoBggrBgEFBQcDAQYIKwYBBQUHAwUGCCsGAQUFBwMGBggrBgEF
BQcDBzANBgkqhkiG9w0BAQUFAAOCAQEARxkP3nTGmZev/K0oXnWO6y1n7k57K9cM
//bey1WiCuFMVGWTYGufEpytXoMs61quwOQt9ABjHbjAbPLPSbtNk28Gpgoiskli
CE7/yMgUsogWXecB5BKV5UU0s4tpvc+0hY91UZ59Ojg6FEgSxvunOxqNDYJAB+gE
CJChicsZUN/KHAG8HQQZexB2lzvukJDKxA4fFm517zP4029bHpbj4HR3dHuKom4t
3XbWOTCC8KucUvIqx69JXn7HaOWCgchqJ/kniCrVWFCVH/A7HFe7fRQ5YiuayZSS
KqMiDP+JJn1fIytH1xUdqWqeUQ0qUZ6B+dQ7XnASfxAynB67nfhmqA== 
-----END CERTIFICATE-----

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

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 証明書で見たことがあると思うので、上記のものはあなたが使用しているものではないかもしれません。

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

編集:

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

  • 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();
于 2012-04-24T18:10:52.000 に答える