Getting the above exception with error log after registering BC provider dynamically and statically via
Security.addProvider(new BouncyCastleProvider());
However, on
Cipher.getInstance("AES/CTS/NoPadding", "BC")
I get the following error
Failure to decrypt: bad encryption:
java.lang.SecurityException: JCE cannot authenticate the provider BC
Caused by: java.util.jar.JarException:
file:/space/uploads/unittest/jars/myjar.jar has unsigned entries - <some-location>/README.txt
at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:500)
at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:361)
at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:159)
at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:185)
at javax.crypto.Cipher.getInstance(Cipher.java:653)
at javax.crypto.Cipher.getInstance(Cipher.java:596)
I believe that any JCE provider JARs must be signed before they will be trusted by your Java runtime. It appears that the jar you have has content in it which is unsigned.
If this is content that you have added to the jar or a jar that you have made then check out this answer which tells you how to sign it: How to sign a custom JCE security provider
With JDK 8u351 (and other corresponding updates to future versions) additional SHA1 restrictions are enabled by default.
See https://www.oracle.com/java/technologies/javase/8u351-relnotes.html
To fix this remove SHA1 denyAfter 2019-01-01 from two keys in the java.security config file (example path /usr/java/jdk/jre/lib/security/java.security in Linux) , essential going back to the previous values. Note that a long term fix is to upgrade to a newer signed jar instead of changing this.
updated keys in the java.security file:
jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, \
include jdk.disabled.namedCurves
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
DSA keySize < 1024, include jdk.disabled.namedCurves
Related
I'm trying to boot an efi loader signed with my custom keys. I've already enrolled its public key in mokmanager, still it is getting blocked in uefi when secure boot is turned on. It looks like the efi is not signed properly.
[root#hp-fedora]/tmp/test# ls
DB.auth DB.crt DB.key KEK.cer KEK.esl mkkeys.sh noPK.auth PK.auth PK.crt PK.key refind_x64.efi.signed
DB.cer DB.esl KEK.auth KEK.crt KEK.key myGUID.txt noPK.esl PK.cer PK.esl refind_x64.efi
[root#hp-fedora]/tmp/test# openssl x509 -in DB.crt -out DB.cer -outform DER
[root#hp-fedora]/tmp/test# sbsign --key DB.key --cert DB.crt --output refind_x64.efi.signed refind_x64.efi
Signing Unsigned original image
[root#hp-fedora]/tmp/test# pesign --show-signature --in=refind_x64.efi.signed
---------------------------------------------
certificate address is 0x7f338a625f88
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is mykeys DB
No signer email address.
Signing time: Thu Aug 11, 2022
There were certs or crls included.
---------------------------------------------
[root#hp-fedora]/tmp/test# pesigcheck -i refind_x64.efi.signed -n 0 -c DB.cer
Searching db DB.cer
Searching db DB.cer
Certificate type not approved for application.
pesigcheck: "refind_x64.efi.signed" is invalid.
I am trying to fix a JBoss re-installation that needs to connect to SQL Server via JDBC and I'm seeing the following in the logs:
Caused by: javax.net.ssl.SSLHandshakeException: Certificates do not conform to algorithm constraints
...
Caused by: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints
...
Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on keysize limits: RSA 1024 bit key used with certificate: CN=SSL_Self_Signed_Fallback
How do I fix this?
From various configuration files on the server I have found security information in the configurations, such as:
jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, \
include jdk.disabled.namedCurves
jdk.security.legacyAlgorithms=SHA1, \
RSA keySize < 2048, DSA keySize < 2048
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
DSA keySize < 1024, include jdk.disabled.namedCurves
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
A number of posts relating to this issue claim this is an OpenJDK problem and to use another JDK or a JDBC problem and to use JTDS, but I believe the working server is using the same OpenJDK version and SQL Server JDBC driver. So, those approaches seem coincidentally addressing the issue. I tried copying the two java.security files from the working server to the one failing (per post 62582542), but that did not solve the issue.
Do I need to make a new 1024-bit, self-signed certificate? Can I copy a certificate from our other, working server? If I need to make a new certificate, what web page has the appropriate process?
A few things were done, which may be a superset of what is needed, to fix this.
The java.security file was modified to not allow other files to be appended to it or to append it.
All the 2048 bit references for protocols were changed to 1024.
I rebooted RHEL and then started JBoss - as opposed to simply rebooting bos
I would suggest using a stronger certificate because RSA 1024bit certificates are considered too weak!
As a workaround, you can set the system property java.security.disableSystemPropertiesFile to true:
JAVA_OPTS="$JAVA_OPTS -Djava.security.disableSystemPropertiesFile=true
Also, set the security property security.useSystemPropertiesFile to false in $JAVA_HOME/jre/lib/security/java.security
I'm trying to fix a failing test in the urllib3 open source Python project.
This test is called test_client_no_intermediate and tries to use a X.509 certificate called client_no_intermediate.pem. The goal is to fail with a "unknown CA" error. The test works as expected with OpenSSL: the import succeeds and the certificate is rejected.
However, on macOS with SecureTransport, the import fails with Import/Export format unsupported.. What's surprising is that it fails consistently on my machine with macOS 10.13.5 and Xcode 9.4.1 but only fails intermittently in continuous integration with macOS 10.12 and XCode 8.3.
Here is the certificate:
-----BEGIN CERTIFICATE-----
MIIC/jCCAmegAwIBAgImFhgDOYh0mJSEggRYaDQ2VjgRdyAwkXmAV2KGITVEhiJw
UmBGKBgwDQYJKoZIhvcNAQELBQAwcTELMAkGA1UEBhMCRkkxDjAMBgNVBAgMBWR1
bW15MQ4wDAYDVQQKDAVkdW1teTEOMAwGA1UECwwFZHVtbXkxETAPBgNVBAMMCFNu
YWtlT2lsMR8wHQYJKoZIhvcNAQkBFhBkdW1teUB0ZXN0LmxvY2FsMB4XDTE3MDUx
MjE4MzQyNloXDTIxMTIxOTE4MzQyNlowdzELMAkGA1UEBhMCRkkxDjAMBgNVBAgM
BWR1bW15MQ4wDAYDVQQKDAVkdW1teTEOMAwGA1UECwwFZHVtbXkxFzAVBgNVBAMM
DlNuYWtlT2lsQ2xpZW50MR8wHQYJKoZIhvcNAQkBFhBkdW1teUB0ZXN0LmxvY2Fs
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCadkbPLXPfA1bNjgL9F6+rVLs3
uZdbXemHf1oKkT4q9uruZTQCTDFvvWHq32r6G8KV7MASariSz+bIgpx1euZEOmwu
cd+ULs0HMdfqorRa3MuUtKuIzYiQvCsv788VoNKjs+NNMIexO6p6S9E36ce2trze
BCmpYmi0WofO0bSwnwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQf
Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUbe9reSw2
C72JuGVpc+/L/O2hVjwwHwYDVR0jBBgwFoAUnltsnuh2mjtqqDWk2RNSwC7njHkw
DQYJKoZIhvcNAQELBQADgYEADlJp3uMKxgS2hgCK+JZV4qsXGuZ/rcHgq5qlrfg0
i76+wwZ6fs3WQe+zNgXbJnRviM0VScSUBM8IuclyovFWLvs0Z0piELtZ7KPwrDVf
5S5ynJHnJSG+sj4N6v+tvtpGDb1S3ueLQm79MGXv9pmbaYBmUJ0YSEnrScWy90Bv
Tno=
-----END CERTIFICATE-----
OpenSSL happily decodes it:
$ openssl x509 -noout -in client_no_intermediate.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
16:18:03:39:88:74:98:94:84:82:04:58:68:34:36:56:38:11:77:20:30:91:79:80:57:62:86:21:35:44:86:22:70:52:60:46:28:18
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=FI, ST=dummy, O=dummy, OU=dummy, CN=SnakeOil/emailAddress=dummy#test.local
Validity
Not Before: May 12 18:34:26 2017 GMT
Not After : Dec 19 18:34:26 2021 GMT
Subject: C=FI, ST=dummy, O=dummy, OU=dummy, CN=SnakeOilClient/emailAddress=dummy#test.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:9a:76:46:cf:2d:73:df:03:56:cd:8e:02:fd:17:
af:ab:54:bb:37:b9:97:5b:5d:e9:87:7f:5a:0a:91:
3e:2a:f6:ea:ee:65:34:02:4c:31:6f:bd:61:ea:df:
6a:fa:1b:c2:95:ec:c0:12:6a:b8:92:cf:e6:c8:82:
9c:75:7a:e6:44:3a:6c:2e:71:df:94:2e:cd:07:31:
d7:ea:a2:b4:5a:dc:cb:94:b4:ab:88:cd:88:90:bc:
2b:2f:ef:cf:15:a0:d2:a3:b3:e3:4d:30:87:b1:3b:
aa:7a:4b:d1:37:e9:c7:b6:b6:bc:de:04:29:a9:62:
68:b4:5a:87:ce:d1:b4:b0:9f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
6D:EF:6B:79:2C:36:0B:BD:89:B8:65:69:73:EF:CB:FC:ED:A1:56:3C
X509v3 Authority Key Identifier:
keyid:9E:5B:6C:9E:E8:76:9A:3B:6A:A8:35:A4:D9:13:52:C0:2E:E7:8C:79
Signature Algorithm: sha256WithRSAEncryption
0e:52:69:de:e3:0a:c6:04:b6:86:00:8a:f8:96:55:e2:ab:17:
1a:e6:7f:ad:c1:e0:ab:9a:a5:ad:f8:34:8b:be:be:c3:06:7a:
7e:cd:d6:41:ef:b3:36:05:db:26:74:6f:88:cd:15:49:c4:94:
04:cf:08:b9:c9:72:a2:f1:56:2e:fb:34:67:4a:62:10:bb:59:
ec:a3:f0:ac:35:5f:e5:2e:72:9c:91:e7:25:21:be:b2:3e:0d:
ea:ff:ad:be:da:46:0d:bd:52:de:e7:8b:42:6e:fd:30:65:ef:
f6:99:9b:69:80:66:50:9d:18:48:49:eb:49:c5:b2:f7:40:6f:
4e:7a
But SecureTransport fails on this specific certificate:
$ security verify-cert -c cacert.pem
Cert Verify Result: CSSMERR_TP_NOT_TRUSTED
$ security verify-cert -c client_no_intermediate.pem
SecCertificateCreateFromData: Unknown format in import.
What is wrong in this certificate?
The only thing obviously "wrong" with the certificate is the serial number is 38 bytes long.
https://www.rfc-editor.org/rfc/rfc3280#section-4.1.2.2
Given the uniqueness requirements above, serial numbers can be
expected to contain long integers. Certificate users MUST be able to
handle serialNumber values up to 20 octets. Conformant CAs MUST NOT
use serialNumber values longer than 20 octets.
While there is also guidance that non-conformant CAs exist, it's possible that Apple put in a limit lower than 38 bytes.
That wouldn't explain intermittency, but having a certificate which doesn't look "conformant" is always asking for unreliability.
I'm tring to create certificate via Visual Studio Command Prompt to meet the following requirements :
• A valid, (not expired), X.509 signing certifi cate must be used (e-mail certifi cate).
• RSA public key (signature) algorithms using key lengths of 1024 bits (or larger).
• Message Digest Algorithm must be SHA1-RSA.
• Encryption algorithm is DES3 (triple DES).
• Key usage must include digital signature (for signing fi les) and key encipherment (for encrypting
the fi les).
• Certifi cate (Public Key Only) should be exported in the following format
» .p7c (* PKCS7 cryptographic message syntax standard certifi cate)
» .cer (DER encoded binary X.509 Certifi cate)
» .cer (Base64 encoded X.509 Certifi cate)
I have tried as :
makecert.exe -sv TestCert.pvk -n “Test Cert” -a sha1 -len 1024 -sky 2 -eku 1.6.6.9.2.8.0.3.9 TestCert.cer -r
pvk2pfx.exe -pvk TestCert.pvk -spc TestCert.cer -pfx TestCert.pfx -po Test123$
I also am reading from https://msdn.microsoft.com/en-us/library/bfsktky3(v=vs.100).aspx
but so far I have no luck. I have done someting valid one while ago but don't seem to remember how. Can someone give me some tips or example will be great.
Thanks in advance.
The algorithm is named 3DES, not DES3.
The encryption algorithm can be applied at the stage of writing the private key to the disk in some format (like PEM or PFX). It's not a part of the certificate. This is why you can't find any option to do this.
I am trying to use openSSL to set up an https connection for my application. I'm running a Neo4j 1.2.2 database, with a Trinidad 1.3.5 web server, using the Rails 3.1 and ruby 1.9.
I have a Thawte trial certificate, ca_cert.crt, their intermediate and root certificates, ca_intermediate.crt and ca_root.crt respectively, and my own private key, ca_private.pem. What openssl command do I need to run to create a keystore, which I can specify in my app's trinidad.yaml config file?
So far the "looks-closest-to-right" thing I've tried is:
pkcs12 –export –in ca_cert.crt inkey ca_private.pem –out keystore.p12 –name tomcat
and it gives me the error:
unable to load certificates
6380:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:.\crypto\as
n1\tasn_dec.c:1319:
6380:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:.\
crypto\asn1\tasn_dec.c:381:Type=X509_CINF
6380:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 e
rror:.\crypto\asn1\tasn_dec.c:751:Field=cert_info, Type=X509
6380:error:0907400D:PEM routines:PEM_X509_INFO_read_bio:ASN1 lib:.\crypto\pem\pe
m_info.c:258:
error in pkcs12
It looks to me like openssl doesn't like the format I have the files in, though I have tried nearly every combination of the .pem, .crt, .cer, and .key extensions I can think of to no avail. I'm new to SSL entirely, so I hope I'm just doing something stupid and its an easy fix...
Here is the example I've been trying to follow: https://github.com/trinidad/trinidad/wiki/ssl-end-to-end-example
From this answer it seems that Thawte certificates are formatted as PKCS#7, while openssl pkcs12 -export command expects PEM. Certificate in PKCS#7 can be converted using modified version of command from previously linked answer.
$ openssl pkcs7 -in ca_cert.crt -print_certs | openssl x509 -outform PEM > ca_cert.pem
Then executing command, that you provided, creates PKCS#12 keystore.
$ openssl pkcs12 –export –in ca_cert.pem -inkey ca_private.pem –out keystore.p12 –name tomcat