简体   繁体   English

从 jdk10 迁移到 jdk11:SSLConnection:CKR_KEY_TYPE_INCONSISTENT

[英]migrating from jdk10 to jdk11 : SSLConnection : CKR_KEY_TYPE_INCONSISTENT

I migrated my client application from openJDK 10 to 11 (JAVA_VERSION="11.0.12") but at runtime, during TLS handhshake, i've got this exception:我将我的客户端应用程序从 openJDK 10 迁移到 11 (JAVA_VERSION="11.0.12") 但在运行时,在 TLS 握手期间,我遇到了这个异常:

javax.net.ssl|ALL|01|main|2021-11-24 10:55:54.848 CET|SignatureScheme.java:592|Ignore unsupported signature algorithm (rsa_pkcs1_sha256) ( "throwable": { java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1282) at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1380) at java.base/java.security.Signature.initSign(Signature.java:682) at java.base/java.security.Signature$1.initSign(Signature.java:146) at java.base/sun.security.util.SignatureUtil.initSignWithParam(SignatureUtil.java:171) at java.base/sun.security.ssl.SignatureScheme.getSigner(SignatureScheme.java:584) at java.base/sun.security.ssl.SignatureScheme.getSignerOfPreferableAlgorithm(SignatureSche javax.net.ssl|ALL|01|main|2021-11-24 10:55:54.848 CET|SignatureScheme.java:592|忽略不支持的签名算法(rsa_pkcs1_sha256)(“throwable”:{java.security.InvalidKeyException:否安装的提供商支持此密钥: sun.security.pkcs11.P11Key$P11PrivateKey at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1282) at java.base/java.security.Signature$Delegate.engineInitSign (Signature.java:1380) at java.base/java.security.Signature.initSign(Signature.java:682) at java.base/java.security.Signature$1.initSign(Signature.java:146) at java.base /sun.security.util.SignatureUtil.initSignWithParam(SignatureUtil.java:171) at java.base/sun.security.ssl.SignatureScheme.getSigner(SignatureScheme.java:584) at java.base/sun.security.ssl.SignatureScheme .getSignerOfPreferableAlgorithm(SignatureSche me.java:532) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:590) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java me.java:532) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:590) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java

.... ....

javax.net.ssl|ALL|01|main|2021-11-24 10:55:54.850 CET|SignatureScheme.java:592|Ignore unsupported signature algorithm (rsa_pkcs1_sha384) ( "throwable": { java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1282) at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1380) at java.base/java.security.Signature.initSign(Signature.java:682) at java.base/java.security.Signature$1.initSign(Signature.java:146) at java.base/sun.security.util.SignatureUtil.initSignWithParam(SignatureUtil.java:171) at java.base/sun.security.ssl.SignatureScheme.getSigner(SignatureScheme.java:584) at java.base/sun.security.ssl.SignatureScheme.getSignerOfPreferableAlgorithm(SignatureSche javax.net.ssl|ALL|01|main|2021-11-24 10:55:54.850 CET|SignatureScheme.java:592|忽略不支持的签名算法 (rsa_pkcs1_sha384) (“throwable”: { java.security.InvalidKeyException: No安装的提供商支持此密钥: sun.security.pkcs11.P11Key$P11PrivateKey at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1282) at java.base/java.security.Signature$Delegate.engineInitSign (Signature.java:1380) at java.base/java.security.Signature.initSign(Signature.java:682) at java.base/java.security.Signature$1.initSign(Signature.java:146) at java.base /sun.security.util.SignatureUtil.initSignWithParam(SignatureUtil.java:171) at java.base/sun.security.ssl.SignatureScheme.getSigner(SignatureScheme.java:584) at java.base/sun.security.ssl.SignatureScheme .getSignerOfPreferableAlgorithm(SignatureSche me.java:532) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:590) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:761) me.java:532) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:590) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:761 )

.... ....

javax.net.ssl|WARNING|01|main|2021-11-24 10:55:55.228 CET|SSLSocketImpl.java:1505|handling exception ( "throwable": { java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_KEY_TYPE_INCONSISTENT at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:679) at java.base/java.security.Signature$Delegate.engineSign(Signature.java:1402) at java.base/java.security.Signature.sign(Signature.java:711) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:609) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:761) at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.co javax.net.ssl|WARNING|01|main|2021-11-24 10:55:55.228 CET|SSLSocketImpl.java:1505|处理异常(“throwable”:{ java.security.ProviderException:sun.security.pkcs11。 wrapper.PKCS11Exception: CKR_KEY_TYPE_INCONSISTENT 在 jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:679) 在 java.base/java.security.Signature$Delegate.engineSign121824.868 java.base/java.security.Signature.sign(Signature.java:711) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:609) at java.base/sun.security.ssl .CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:761) at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.co nsume(ServerHelloDone.java:182) nsume(ServerHelloDone.java:182)

In debug mode, with -Djavax.net.debug=all argument.在调试模式下,使用 -Djavax.net.debug=all 参数。 I see this difference but i don't know if it's interesting.我看到了这种差异,但我不知道它是否有趣。

JDK11 JDK11

javax.net.ssl|DEBUG|01|main|2021-11-24 10:55:54.687 CET|ClientHello.java:653|Produced ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "74 E9 F0 E2 E6 18 44 A4 BD 5C 8E 5F 11 BB AE 98 15 13 0F F0 E9 93 6D B3 B4 08 EE 6A 9E B9 39 8B",
  "session id"          : "",
  "cipher suites"       : "[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
  "compression methods" : "00",
  "extensions"          : [
    "server_name (0)": {
      type=host_name (0), value=ws.test.annuaireamc.fr
    },
    "status_request (5)": {
      "certificate status type": ocsp
      "OCSP status request": {
        "responder_id": <empty>
        "request extensions": {
          <empty>
        }
      }
    },
    "supported_groups (10)": {
      "versions": [x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]
    },
    "ec_point_formats (11)": {
      "formats": [uncompressed]
    },
    "signature_algorithms (13)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "signature_algorithms_cert (50)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "status_request_v2 (17)": {
      "cert status request": {
        "certificate status type": ocsp_multi
        "OCSP status request": {
          "responder_id": <empty>
          "request extensions": {
            <empty>
          }
        }
      }
    },
    "extended_master_secret (23)": {
      <empty>
    },
    "supported_versions (43)": {
      "versions": [TLSv1.2]
    }
  ]
}

JDK10: JDK10:

*** ClientHello, TLSv1.2
RandomCookie:  random_bytes = {82 D7 E3 A8 48 D6 9D 36 FF 54 0B 1A 75 C5 58 1E B9 C0 E8 8D E3 B8 53 73 3B C1 65 F4 A1 E4 DD 12}
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension supported_groups, group names: {secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Extension extended_master_secret
Extension server_name, server_name: [type=host_name (0), value=ws.test.annuaireamc.fr]
Extension status_request_v2
CertStatusReqItemV2: ocsp_multi, OCSPStatusRequest
    ResponderIds: <EMPTY>
    Extensions: <EMPTY>
CertStatusReqItemV2: ocsp, OCSPStatusRequest
    ResponderIds: <EMPTY>
    Extensions: <EMPTY>
Extension status_request: ocsp, OCSPStatusRequest
    ResponderIds: <EMPTY>
    Extensions: <EMPTY>
***

I use a client certificate stored in card.我使用存储在卡中的客户端证书。

I add "SunPKCS11" provider and with the command line Djava.security.debug=sunpkcs11 i have this information with Java11:我添加了“SunPKCS11”提供程序并使用命令行 Djava.security.debug=sunpkcs11 我在 Java11 中获得了以下信息:

    Library info:
  cryptokiVersion: 2.20
  manufacturerID: manufacturer                     
  flags: 0
  libraryDescription: CPS3 PKCS#11 MACOSX             
  libraryVersion: 2.07
All slots: 0
Slots with tokens: 0
Slot info for slot 0:
  slotDescription: PSS Reader on CPS                                               
  manufacturerID:                                 
  flags: CKF_TOKEN_PRESENT | CKF_REMOVABLE_DEVICE | CKF_HW_SLOT
  hardwareVersion: 0.00
  firmwareVersion: 0.00
Token info for token in slot 0:
  label: CPS3v3-2800385098               
  manufacturerID: manufacturer                     
  model: IAS ECC?????????
  serialNumber: 99225468       
  flags: CKF_RNG | CKF_LOGIN_REQUIRED | CKF_USER_PIN_INITIALIZED | CKF_TOKEN_INITIALIZED
  ulMaxSessionCount: CK_EFFECTIVELY_INFINITE
  ulSessionCount: 0
  ulMaxRwSessionCount: CK_EFFECTIVELY_INFINITE
  ulRwSessionCount: 0
  ulMaxPinLen: 4
  ulMinPinLen: 4
  ulTotalPublicMemory: CK_UNAVAILABLE_INFORMATION
  ulFreePublicMemory: CK_UNAVAILABLE_INFORMATION
  ulTotalPrivateMemory: CK_UNAVAILABLE_INFORMATION
  ulFreePrivateMemory: CK_UNAVAILABLE_INFORMATION
  hardwareVersion: 0.00
  firmwareVersion: 0.00
  utcTime: ????????????????
Mechanism CKM_SHA_1:
  ulMinKeySize: 0
  ulMaxKeySize: 0
  flags: 1024 = CKF_DIGEST
Mechanism CKM_SHA256:
  ulMinKeySize: 0
  ulMaxKeySize: 0
  flags: 1024 = CKF_DIGEST
Mechanism CKM_RSA_X_509:
  ulMinKeySize: 512
  ulMaxKeySize: 2048
  flags: 272897 = CKF_HW | CKF_DECRYPT | CKF_SIGN | CKF_VERIFY | CKF_UNWRAP
DISABLED due to legacy
Mechanism CKM_RSA_PKCS:
  ulMinKeySize: 512
  ulMaxKeySize: 2048
  flags: 272897 = CKF_HW | CKF_DECRYPT | CKF_SIGN | CKF_VERIFY | CKF_UNWRAP
DISABLED due to legacy
Mechanism CKM_SHA1_RSA_PKCS:
  ulMinKeySize: 512
  ulMaxKeySize: 2048
  flags: 10240 = CKF_SIGN | CKF_VERIFY
Mechanism CKM_SHA256_RSA_PKCS:
  ulMinKeySize: 512
  ulMaxKeySize: 2048
  flags: 10240 = CKF_SIGN | CKF_VERIFY
DISABLED in configuration

So, if i display the available algorthims, i've got less algorthims in java 11 than in java 10.所以,如果我显示可用的算法,我在 java 11 中的算法比在 java 10 中的算法少。

In java 11:在 java 11:

Service Type: MessageDigest Algorithm SHA1
Service Type: KeyStore Algorithm PKCS11
Service Type: Signature Algorithm SHA1withRSA
Service Type: MessageDigest Algorithm SHA-256
Service Type: SecureRandom Algorithm PKCS11

In java 10:在 java 10:

Service Type: Signature Algorithm MD2withRSA
Service Type: Cipher Algorithm RSA/ECB/NoPadding
Service Type: Signature Algorithm SHA224withRSA
Service Type: Signature Algorithm SHA512withRSA
Service Type: Signature Algorithm SHA1withRSA
Service Type: KeyFactory Algorithm RSA
Service Type: Signature Algorithm SHA384withRSA
Service Type: Signature Algorithm MD5withRSA
Service Type: Cipher Algorithm RSA/ECB/PKCS1Padding
Service Type: MessageDigest Algorithm SHA-256
Service Type: MessageDigest Algorithm SHA1
Service Type: Signature Algorithm SHA256withRSA
Service Type: SecureRandom Algorithm PKCS11
Service Type: KeyStore Algorithm PKCS11 

Do i need to modify java.security file?我需要修改 java.security 文件吗? What is the difference between rsa_pkcs1_sha256 and SHA256withRSA? rsa_pkcs1_sha256 和 SHA256withRSA 有什么区别? Is the problem come from provider and "DISABLED due to legacy"?问题是否来自提供商和“由于遗留问题而被禁用”? Is it possible to force "DISABLED due to legacy" algorithm?是否可以强制“因遗留而禁用”算法?

I think it's due to security improvments in SunPKCS11.java, not only JDK11 but also in JDK8, and I think all of them.我认为这是由于 SunPKCS11.java 中的安全改进,不仅是 JDK11,还有 JDK8,我认为都是。 They add a new function:他们添加了一个新的 function:

private static boolean isLegacy(CK_MECHANISM_INFO mechInfo)
        throws PKCS11Exception {
    // assume full support if no mech info available
    // For vendor-specific mechanisms, often no mech info is provided
    boolean partialSupport = false;

    if (mechInfo != null) {
        if ((mechInfo.flags & CKF_DECRYPT) != 0) {
            // non-legacy cipher mechs should support encryption
            partialSupport |= ((mechInfo.flags & CKF_ENCRYPT) == 0);
        }
        if ((mechInfo.flags & CKF_VERIFY) != 0) {
            // non-legacy signature mechs should support signing
            partialSupport |= ((mechInfo.flags & CKF_SIGN) == 0);
        }
    }
    return partialSupport;
}

Mechanisms such as "CKM_RSA_PKCS" are disabled since they set the flag "CKF_DECRYPT" without setting "CKF_ENCRYPT".诸如“CKM_RSA_PKCS”之类的机制被禁用,因为它们设置了标志“CKF_DECRYPT”而不设置“CKF_ENCRYPT”。 It's legacy according to Java, but mandatory according to IAS-ECC specifications.根据 Java,它是遗留的,但根据 IAS-ECC 规范是强制性的。

I have not found any workaround yet.我还没有找到任何解决方法。 Have you?你?

On jdk8u322-ga tag, you still have isLegacy() https://github.com/openjdk/jdk8u/blob/jdk8u322-ga/jdk/src/share/classes/sun/security/pkcs11/SunPKCS11.java在 jdk8u322-ga 标签上,你还有 isLegacy() https://github.com/openjdk/jdk8u/blob/jdk8u322-ga/jdk/src/share/classes/sun/security/pkcs11/SunPKCS11.java

On jdk8u312-ga tag, there is no isLegacy() function https://github.com/openjdk/jdk8u/blob/jdk8u312-ga/jdk/src/share/classes/sun/security/pkcs11/SunPKCS11.java在 jdk8u312-ga 标签上,没有 isLegacy() function https://github.com/openjdk/jdk8u/blob/jdk8u312-ga/jdk/src/share/classes/sun/security/pkcs11/SunPKCS11.java

So the last build without this function is https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u312-b07所以没有这个 function 的最后一个构建是https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u312-b07

Now, it is important to understand why OpenJDK add this new constraint incompatible with IAS-ECC specifications.现在,理解为什么 OpenJDK 添加这个与 IAS-ECC 规范不兼容的新约束很重要。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM