根据JEP 131，Java 8应该为64位Windows提供PKCS#11加密提供程序：https://blogs.oracle.com/mullan/entry/jep_131_pkcs_11_crypto.
考虑到这一点，我使用以下说明下载并构建了带有NSPR的NSS的32位和64位版本：https://developer.mozilla.org/en-US/docs/NSS_Sources_Building_Testing
我下载了Java 8 for Windows 64 build b118，配置了Java.security文件并创建了一个nss.cfg文件：
摘录自java.security文件：
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.pkcs11.SunPKCS11 /devel/nss.cfg
nss.cfg：
# Use NSS as a FIPS-140 compliant cryptographic token
# SunPKCS11-NSS
name = NSS
#32 bit
nssLibraryDirectory = C:develnssnss-3.15.3.1distWINNT6.1_DBG.OBJlib
#64 bit
#nssLibraryDirectory = C:develnssnss-3.15.3.1distWINNT6.1_64_DBG.OBJlib
#non FIPS
#nssDbMode = noDb
#attributes = compatibility
#FIPS
nssSecmodDirectory = c:develfipsdb
nssModule = fips
我运行了NSS附带的测试套件，看起来所有的加密/解密测试都通过了（需要主机名/域名的测试确实存在一些问题，但这与Windows环境有关）。
所以问题来了。我用32位版本的NSS在Java 7 32位上运行了我的测试加密应用程序，一切都很好。当我尝试用64位NSS运行Java 8 64位时，我得到了以下错误：
java.security.ProviderException: Could not initialize NSS
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:212)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:103)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jca.ProviderConfig.doLoadProvider(Unknown Source)
at sun.security.jca.ProviderConfig.getProvider(Unknown Source)
at sun.security.jca.ProviderList.getProvider(Unknown Source)
at sun.security.jca.ProviderList.getIndex(Unknown Source)
at sun.security.jca.ProviderList.getProviderConfig(Unknown Source)
at sun.security.jca.ProviderList.getProvider(Unknown Source)
at java.security.Security.getProvider(Unknown Source)
at sun.security.ssl.SunJSSE.<init>(Unknown Source)
at sun.security.ssl.SunJSSE.<init>(Unknown Source)
at com.sun.net.ssl.internal.ssl.Provider.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jca.ProviderConfig.doLoadProvider(Unknown Source)
at sun.security.jca.ProviderConfig.getProvider(Unknown Source)
at sun.security.jca.ProviderList.getProvider(Unknown Source)
at sun.security.jca.ProviderList$ServiceList.tryGet(Unknown Source)
at sun.security.jca.ProviderList$ServiceList.access$200(Unknown Source)
at sun.security.jca.ProviderList$ServiceList$1.hasNext(Unknown Source)
at javax.crypto.KeyGenerator.nextSpi(KeyGenerator.java:323)
at javax.crypto.KeyGenerator.<init>(KeyGenerator.java:158)
at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:208)
at STSAESEncryption.generateKeyWithGenerator(STSAESEncryption.java:74)
at Main.main(Main.java:24)
Caused by: java.io.IOException: %1 is not a valid Win32 application.
at sun.security.pkcs11.Secmod.nssLoadLibrary(Native Method)
at sun.security.pkcs11.Secmod.initialize(Secmod.java:210)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:207)
... 36 more
我确实在Sean Mullan的博客上发布了一条消息（链接如上），并回复了这个问题：所有东西都在运行64位，我无法在非FIPS模式下工作（同样的错误），但我的回复还没有出现在博客上（需要批准）。
有没有其他人试图让NSS在Windows 64位上使用Java 8 64位？
根据Alex Pakka评论更新1：
谢谢你的回复。当我使用Java 8 64位时，我使用的是64位NSS库。当我测试32位和64位时，我一直在来回切换。
我附加了代码并逐步完成，但当我试图查看platformPath变量时，我得到"platformPath无法解析为变量"。我对Eclipse并不是很熟悉，所以我想知道我是否做错了什么。
我试图编辑我输入的路径，看看我会遇到什么错误，当我将nssLibraryPath更改为另一个目录（没有nss库）时，我会遇到与win32不同的错误。
我知道nss可以与Java 8 64位Linux（可能还有其他平台）配合使用，但它确实已经在Windows 64位上进行了验证。我知道这是Java 8和Windows 64位的一个新功能，Java 7只支持Windows 43位。
再次感谢你的回复，它起到了帮助作用，我仍在努力解决这个问题。
考虑到这一点，我使用以下说明下载并构建了带有NSPR的NSS的32位和64位版本：https://developer.mozilla.org/en-US/docs/NSS_Sources_Building_Testing。。。
我可能在这里说错了。。。。
我不相信NSS是像OpenSSL那样以源代码形式验证的FIPS 140-2。NSS是一种更传统的验证，类似于Crypto++、Certicom和其他验证。在NSS的情况下，您必须从Mozilla获取预先构建的二进制文件。
如果Mozilla没有为Windows提供FIPS 140-2验证的二进制文件，或者没有为您需要的Windows平台提供FIPS 140-2验证的二进制程序，那么我认为您运气不好。
最简单的方法可能是通过与NIST存档的网络安全服务（NSS）加密模块3.12.4版FIPS 140-2安全策略。（我可能有错误的版本，因为我没有使用NSS；一定要检查它是最新的安全策略）。
根据1中提到的安全策略，似乎只有两个平台被合并，Windows也没有。参见第2.2节，平台列表（第8页）：
Model |Operating System and Version
------------------------------+----------------------------
x86_64 Nehalem Xeon 5500 |Wind River Linux Secure 1.0
------------------------------+----------------------------
x86_64 Pentium core2 duo |Wind River Linux Secure 1.0
从上表中，您需要使用Wind River Linux Secure 1.0。如果您使用的是Wind River，则也必须具有Xeon 5500或Core2 Duo。否则，您是而不是使用验证的加密。
类似地，Crypto++在Windows上有三个FIPS 140-2验证（证书343、562和819）。但是，您需要从Crypto++网站下载预构建的二进制文件，并且需要根据向NIST提交的Crypto++安全政策使用它们。这些限制包括操作系统版本，甚至包括C运行时Service Pack级别。
我会附加源代码，例如http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/security/pkcs11/Secmod.java?av=f并在第210行放置一个断点来检查CCD_ 1变量（在openjdk 7代码中是第203行）。它看起来确实像一个PATH问题。NSS可与Java 8 64位配合使用。
消息"%1不是有效的Win32应用程序"具有误导性，并且来自Windows本身，这可能只是意味着在库路径上找不到nss3.dll。
此外，在您的代码中，您在nss.cfg 中进行了注释
#64 bit
#nssLibraryDirectory = C:develnssnss-3.15.3.1distWINNT6.1_64_DBG.OBJlib
您只能将64位库加载到64位Java进程中，因此需要取消对该路径的注释，并将32位路径注释掉。
re："我不认为NSS是像OpenSSL这样以源代码形式验证的FIPS 140-2。NSS是一种更传统的验证，就像Crypto++、Certicom和其他的验证一样。在NSS的情况下，你必须从Mozilla获得预构建的二进制文件。"
"FIPS PUB 140-2和加密模块验证程序的实施指南"规定，您可以从源代码重新编译。。我认为，我们可以将NSS重新编译到NIST网站上认证并列出的版本。最后一个是#1837由RedHat（v3.12.4）。
以下是"FIPS PUB 140-2和加密模块验证程序实施指南"中的关键引文
"CMVP允许供应商移植和重新编译经过验证的软件、固件或混合软件从验证证书上指定的操作环境到只要移植遵守规则。加密模块的验证状态在没有密码模块在新的操作环境中被重新测试。然而，CMVP没有关于模块的正确操作或生成密钥的安全强度的声明如果验证证书上没有列出特定的操作环境，则进行移植"。
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf