I have a Wildfly 17 server running on Ubuntu 18.04 TLS and tried to enable SSL as described in the links below:
https://docs.oracle.com/cd/E19509-01/820-3503/ggfen/index.html
How to make wildfly localhost connection automatically into https?
https://medium.com/#hasnat.saeed/setup-ssl-https-on-jboss-wildfly-application-server-fde6288a0f40
I have issued a CSR request, purchased a CA certificate based on this CSR Request, and installed the purchased certificate into my keystore named heimdi.jks, which I created upon generating the CSR request in the folder of wildfly
/opt/wildfly/standalone/configuration
After creating an additional security-realm and enabling the <https-listener to use it in my standalone.xml, as described in the links above, I started my Wildfly and tried to access it via https on port 8443. In the address bar of the browser I got the the message that the site is not secure. When I clicked on the certificate, the browser said: "Certificate is not valid" (see below)
In the certificate viewer of my browser I' ve got :
and also
My keystore contains three entries:
administrator#14980:/opt/wildfly/standalone/configuration$ sudo
keytool -keystore heimdi.jks -list -v
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 3 entries
Now, the first entity is the server certificate I bought:
Alias name: server
Creation date: Jun 7, 2022
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=heimdi.at
Issuer: CN=RapidSSL Global TLS RSA4096 SHA256 2022 CA1, O="DigiCert, Inc.", C=US
Serial number: 2cd552dea82c2a783fee69d6f160d78
Valid from: Wed Jun 01 02:00:00 CEST 2022 until: Fri Jun 02 01:59:59 CEST 2023
Certificate fingerprints:
SHA1: B9:D9:C6:E3:B9:41:0F:39:F7:63:FB:B7:5C:22:3C:39:66:E6:BA:C1
SHA256: 64:4B:9B:FB:85:C2:EC:54:C2:1C:66:65:51:A9:3C:AB:33:C9:D3:F9:20:8B:F1:77:D9:B0:0F:02:D1:86:53:97
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
The second one is the certificate of the intermediate authority:
Certificate[2]:
Owner: CN=RapidSSL Global TLS RSA4096 SHA256 2022 CA1, O="DigiCert, Inc.", C=US
Issuer: CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Serial number: a059b25f54b3d8794cc6631477538a3
Valid from: Wed May 04 02:00:00 CEST 2022 until: Mon Nov 10 00:59:59 CET 2031
Certificate fingerprints:
SHA1: 68:F2:2B:1A:62:98:F7:DA:19:1E:61:49:ED:8D:E0:EF:FF:54:AD:8C
SHA256: 92:A5:F5:15:AD:35:D3:A2:7C:49:0E:DB:13:5D:E7:04:4B:1E:39:9D:60:8A:C1:AB:E8:83:FC:82:FB:4B:16:BE
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
And the last one is the root CA certificate:
Certificate[3]:
Owner: CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Issuer: CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Serial number: 83be056904246b1a1756ac95991c74a
Valid from: Fri Nov 10 01:00:00 CET 2006 until: Mon Nov 10 01:00:00 CET 2031
Certificate fingerprints:
SHA1: A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36
SHA256: 43:48:A0:E9:44:4C:78:CB:26:5E:05:8D:5E:89:44:B4:D8:4F:96:62:BD:26:DB:25:7F:89:34:A4:43:C7:01:61
Signature algorithm name: SHA1withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
An HTTPS browser never gets your privatekey. Yours is showing a self-signed (dummy) certificate created on May 25, which is apparently when you did keytool -genkey[pair]. That operation creates a privatekey and a dummy cert which is intended to be replaced when you get a real one; it is not the privatekey but is stored in the PrivateKey entry, which actually contains both the privatekey and a certificate chain.
You obtained a 'real' cert (from RapidSSL/Digicert), but did not correctly replace the dummy one. You need to do keytool -importcert -keystore x -file y -alias z where x is your keystore heimdi.jks, y is the file containing the server cert you got, and z is the alias of the PrivateKey entry which is server.
But before that you need to have the chain certs, plural, in your keystore. Your server cert is issued by an intermediate CA, RapidSSL Global TLS RSA4096 SHA256 2022 CA1, but the root cert you have is for DigiCert Global Root CA which you can see is different. You should have (RapidSSL/Digicert should have supplied you) a 'chain' or 'intermediate' certificate that links these by having subject (which keytool calls 'owner') equal to the former and issuer equal to the latter. Your list shows TrustedCert entries for therootca and client; the former matches the (published) Digicert root but you don't say what's in the latter and it doesn't match any publicly-logged intermediate, plus it doesn't normally make sense to have any kind of 'client' cert in an HTTPS server keystore.
If RapidSSL gave you a 'bundle' file, look at it with any text tool like cat or more or an editor; it probably contains more than one certificate, but if you used it in keytool -import[cert] that only read the first one. Split out any subsequent cert(s) and look at each individually (for example with keytool -printcert -file f) to find the intermediate, or alternatively try downloading this logged one. Import it to a different alias -- maybe themidca -- before importing the server cert to the privatekey alias server as above.
PS: there is no "Linux 18.04". You probably mean Ubuntu, which identifies releases with the yy.mm format, and the releases in April of even-numbered years, like 18.04, are "LTS" (Long-Term Support) -- not TLS. But even "long-term" is only free for 5 years, which expires next spring for your system.
Related
I have a certificate from Comodo that I use to sign my builds: DLLs for native code, .NET DLLs, and a JAR file for Java.
I obtained the certificate on Sep 30, 2021 and it's good until Sep 30, 2024 :
$ openssl pkcs12 -in ./My_Code_Signing_CertAndPrivateKey.pkcs12.pfx -passin pass:"********" -clcerts -nokeys | openssl x509 -noout -enddate
notAfter=Sep 30 23:59:59 2024 GMT
I followed these instructions to generate a Java KeyStore (JKS) certificate and confirmed its expiration is Sep 2024:
keytool -list -v -keystore My_Code_Signing_CertAndPrivateKey_JavaKeyStore.jks -storepass "*****" | grep until
Valid from: Thu Sep 30 20:00:00 EDT 2021 until: Mon Sep 30 19:59:59 EDT 2024
Valid from: Sun Mar 21 20:00:00 EDT 2021 until: Fri Mar 21 19:59:59 EDT 2036
Valid from: Mon May 24 20:00:00 EDT 2021 until: Sun Dec 31 18:59:59 EST 2028
Valid from: Wed Dec 31 19:00:00 EST 2003 until: Sun Dec 31 18:59:59 EST 2028
Valid from: Sun Jan 21 19:00:00 EST 2018 until: Sat Jan 22 18:59:59 EST 2022
Valid from: Wed May 08 20:00:00 EDT 2013 until: Mon May 08 19:59:59 EDT 2028
Valid from: Mon Jan 18 19:00:00 EST 2010 until: Mon Jan 18 18:59:59 EST 2038
Warning:
<le-7a277b0a-1b66-4d55-8b15-11d2734d9e16> uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore Nucleuz_Code_Signing_CertAndPrivateKey_JavaKeyStore.jks -destkeystore Nucleuz_Code_Signing_CertAndPrivateKey_JavaKeyStore.jks -deststoretype pkcs12".
But when I use the JKS certificate to sign my JAR file it reports the signer certificate is already expired (Jan 22, 2022):
$ jarsigner -keypass CodeSignPwd -keystore ./My_Code_Signing_CertAndPrivateKey_JavaKeyStore.jks -storepass "*****" -tsa http://timestamp.comodoca.com/rfc3161 -digestalg SHA-256 myjar.jar "***** comodo ca limited id"
jar signed.
Warning:
The signer certificate has expired.
The signer certificate expired on 2022-01-22. However, the JAR will be valid until the timestamp expires on 2033-08-10.
jarsigner also reports the JAR signature is already expired (Jan 22, 2022):
$ jarsigner -verify -verbose -certs myjar.jar
[entry was signed on 2/14/23 4:20 PM]
>>> Signer
X.509, CN=*****, O=*****, OID.2.5.4.18=*****, STREET=*****, ST=**, OID.2.5.4.17=*****, C=US
[certificate expired on 1/22/22 6:59 PM]
X.509, CN=COMODO RSA Code Signing CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
[certificate is valid from 5/8/13 8:00 PM to 5/8/28 7:59 PM]
X.509, CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
[trusted certificate]
>>> TSA
X.509, CN="Sectigo RSA Time Stamping Signer #3", O=Sectigo Limited, ST=Manchester, C=GB
[certificate is valid from 5/10/22 8:00 PM to 8/10/33 7:59 PM]
X.509, CN=Sectigo RSA Time Stamping CA, O=Sectigo Limited, L=Salford, ST=Greater Manchester, C=GB
[certificate is valid from 5/1/19 8:00 PM to 1/18/38 6:59 PM]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
- Signed by "CN=*****, O=*****, OID.2.5.4.18=*****, STREET=*****, L=*****, ST=**, OID.2.5.4.17=*****, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
Timestamped by "CN="Sectigo RSA Time Stamping Signer #3", O=Sectigo Limited, ST=Manchester, C=GB" on Tue Feb 14 21:20:26 UTC 2023
Timestamp digest algorithm: SHA-256
Timestamp signature algorithm: SHA384withRSA, 4096-bit key
jar verified.
Warning:
This jar contains entries whose signer certificate has expired.
The signer certificate expired on 2022-01-22. However, the JAR will be valid until the timestamp expires on 2033-08-10.
My native-code DLLs and the .NET DLLs have the proper expiration: Sep 30, 2024.
Any suggestions?
How can I replace a new intermediate CA Certificate in a keystore file?
Hi,
I have a keystore file running on a server to support Tomcat TLS/HTTPS services.
In this keystore file, there are 3 certificates -
end certificate (tomcat)
intermediate CA Certificate (my_ssl_ca_v2_b)
Root CA Certificate (my_root_ca)
Here is the cert list.
C:\Program Files\Java\jre1.8.0_144\bin>keytool.exe -list -keystore C:\mycert\
my.keystore
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 3 entries
tomcat, Oct 10, 2019, PrivateKeyEntry,
Certificate fingerprint (SHA1): 3C:15:E8:D0:46:A8:8D:1F:93:52:9D:54:35:48:69:71:ED:49:44:65
my_ssl_ca_v2_b, Oct 10, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 0C:C3:60:CB:C6:91:0A:90:E4:0G:91:BE:3B:A6:D7:5B:C3:7B:8A:0F
my_root_ca, Oct 10, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 6C:23:89:FA:A8:E5:7D:E1:45:BE:75:84:15:E8:D8:41:73:59:FD:19
It was working fine.
Couple of days before, the intermediate CA Certificate in the file was expired. I got the new updated intermediate CA Certificate later.
Now, the question is - how can I replace the expired intermediate CA Certificate in the keystore file with the new one?
I understand I can use keytool -delete and -import option to delete and re-import the intermediate CA my_ssl_ca_v2_b.
However, how can I replace the intermediate CA cert inside the PrivateKeyEntry (Alias tomcat) in the keystore file as following?
**Alias name: tomcat**
Creation date: Oct 10, 2019
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
...
...
Certificate[2]:
Owner: CN=My SSL CA v2 - A, O=eBay Inc, C=US
Issuer: CN=My Root CA, O=eBay Inc, C=us
Serial number: 6800000004b4491dd58df45b9b000000000004
**Valid from: Wed Oct 14 18:35:33 UTC 2015 until: Wed Oct 14 18:45:33 UTC 2020**
...
...
Certificate[3]:
Owner: CN=My Root CA, O=eBay Inc, C=us
Issuer: CN=My Root CA, O=eBay Inc, C=us
Serial number: 4500888247008e884cd02d71a035810e
I can't use keytool -delete and -import option to delete and re-import the alias tomcat with the End Cert file because that will delete the private key as well and the private key will never be back.
Can you please teach me the exact steps to replace a intermediate CA Certificate in keystore? Thanks a lot!
-Jun
This isn't really a programming or development question, even though you use the result on tomcat, and may get closed.
You need to create a file containing the whole chain -- end-entity, intermediate and root certs, in that order, in PEM. If you don't already have the EE cert in PEM you can extract it with keytool -export[cert] -keystore ksfile -alias tomcat -rfc -file eecert. Obviously you have the new intermedate cert that you just got, and if you don't have the root already (and it didn't change) export that also. You can combine the files with cat a b c >d on Unix or COPY a+b+c d on Windows, or use any text editor you like. Then import it to the privatekey entry like keytool -import[cert] -keystore ksfile -alias tomcat -file chainfile.
We have one way ssl HTTPS server which sends CA certificates to the client. When the client sends the request to the server we are getting a javax.net.ssl.SSLHandshakeException.
When the client sends request to the https server, server is throwing a sslhandshake exception as shown below. We tried to edit java security file but that seems to be not working.
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- |NF javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
Client and Server connection is established.
root#myhostname> wget --no-check-certificate https://myserver:4443/zen_myevent_listener/eventListener/p1
--2016-09-01 05:09:44-- https://myserver/zen_myevent_listener/eventListener/p1
Connecting to 10.255.120.133:4443... connected.
The algorithm for this is shown in the picture below:
These are the certificates on HTTPS server which we have generated.
-rw-------. 1 root root 3967 Aug 26 15:07 01.pem
-rw-------. 1 root root 1659 Aug 26 15:06 ca.crt
-rw-------. 1 root root 1751 Aug 26 15:05 ca.key
-rw-------. 1 root root 112 Aug 26 15:07 index.txt
-rw-------. 1 root root 21 Aug 26 15:07 index.txt.attr
-rw-------. 1 root root 0 Aug 26 15:05 index.txt.old
-rw-------. 1 root root 42542116 Aug 31 09:48 log.txt
-rwxrwxrwx. 1 root root 8805 Aug 26 12:51 openssl.cnf
-rw-------. 1 root root 3 Aug 26 15:07 serial
-rw-------. 1 root root 3 Aug 26 15:04 serial.old
-rw-------. 1 root root 5626 Aug 26 15:07 server-chain.crt
-rw-------. 1 root root 3967 Aug 26 15:07 server.crt
-rw-------. 1 root root 806 Aug 26 15:06 server.csr
-rw-------. 1 root root 887 Aug 26 15:06 server.key
and 01.pem /01.der file is placed on client.
When we googled and checked, we got the below fix/resolution. Even after trying this, we are still getting the same error.
The reason for this is twofold:
Sentinel 7.1 SP1 or later ships with a newer Java version that has a restriction to not allow RSA keySizes of less than 1024
The default certificates used in the logging applications have a key size of less than 1024 and don't comply to this restriction. Because of this, the server rejects the connection with the error message shown above.
The fastest way to get the system working is to revert back this
change. Edit the file jre/lib/security/java.security and look for this
line:
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
Remove the last restriction, the line will look like this:
jdk.certpath.disabledAlgorithms=MD2
Restart Sentinel for the changes to take effect.
This would not be a solution but a workaround to get things working after the upgrade.
A proper resolution is to use custom certificates on the logging applications that use strong encryption (key sizes of 1024 or more).
Once all applications have been updated, the restriction can be put
back in place.
IDM 4.5 includes an instrumentation upgrade with certificates to a key size larger than 1024 to fix this problem.
eDirectory 88SP8 Patch 2 and eDirectory 88SP7 Patch 6 have
Instrumentation upgrades with certificates to a key size larger than
1024 to fix the problem. (Note: Instrumentation is not automatically
upgraded with eDirectory, you must also manually install the
instrumentation package within the eDir patch.)
Even after trying this we are still getting the same error. Could some one help us how to proceed with this?
Here is the output of openssl x509 -text -in server.crt
root#rover> openssl x509 -text -in server.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=IN, ST=Karnataka, L=Bangalore, O=mycompany, OU=abc, CN=rover/emailAddress=myemail#gmail.com
Validity
Not Before: Aug 26 09:37:05 2016 GMT
Not After : Dec 9 09:37:05 2019 GMT
Subject: C=IN, ST=Karnataka, O=mycompany, OU=IMS, CN=rover/emailAddress=myemail#gmail.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:a4:51:0e:c5:7e:eb:e9:8e:89:9c:79:6a:b5:94:
d3:94:53:43:b2:26:47:a5:13:25:87:a3:73:03:27:
4f:f8:b2:60:86:00:b3:c7:8a:d4:bd:3c:70:33:1e:
16:4b:0a:e7:a7:50:a6:48:0e:33:cf:6e:72:30:13:
c0:bd:1a:b3:57:ec:ec:bd:6b:90:84:f4:79:a9:29:
48:50:7d:e0:07:22:c5:cc:b1:81:4d:8d:61:f5:c6:
58:87:73:e0:1b:b9:a1:fc:a0:1a:42:79:96:f6:11:
cf:0a:60:fe:26:d4:e3:a6:b8:ca:8d:2c:48:b1:41:
5e:f8:64:a6:2f:02:e5:5b:8f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Authority Key Identifier:
keyid:C5:05:6A:D7:1B:9A:E1:B6:A5:A2:2F:70:2B:13:C6:C2:74:DA:70:45
DirName:/C=IN/ST=Karnataka/L=Bangalore/O=mycompany/OU=IMS/CN=rover/emailAddress=myemail#gmail.com
serial:B0:C5:54:AC:F8:78:7B:5F
Signature Algorithm: md5WithRSAEncryption
36:ae:d7:aa:c2:ce:20:91:c9:57:77:e7:4b:c5:e1:b5:28:5d:
4b:85:db:03:90:67:4e:f9:7d:b1:35:8c:de:80:6d:bf:f5:d0:
c9:1b:10:8a:c2:de:5e:88:d6:f6:0d:fc:05:92:f0:88:81:98:
8c:c9:a4:57:1b:70:7d:8d:dc:90:c9:cd:e3:77:1f:81:f0:63:
39:42:14:ff:d6:46:cb:f9:84:2c:8d:cc:1e:b5:b9:6a:12:2a:
c4:d4:5c:fa:79:a6:ea:a8:9b:53:65:54:c9:68:a4:d8:63:0f:
64:a5:35:88:6d:9f:3b:bf:dd:ec:5f:69:95:a2:17:94:97:c9:
26:89:d2:1b:12:2f:39:35:1f:aa:41:d0:23:2f:0e:c8:83:02:
9d:70:46:ff:23:3d:5b:46:58:fa:ff:1c:3f:d1:9b:78:21:b9:
cf:ae:b5:3c:64:12:70:92:71:0f:9f:b0:f9:54:6a:e7:51:41:
b0:66:2f:0a:57:a1:a7:e6:f8:e0:7b:46:7d:e5:66:b7:f7:e9:
d4:23:16:89:b0:bc:8e:c5:e6:b9:69:a1:bc:2b:98:08:fc:10:
9c:9e:71:a8:b6:c1:fa:9a:71:5a:79:9d:07:cb:73:d4:e7:5a:
01:16:76:38:6e:29:8b:6a:12:72:e9:ac:36:54:a2:9f:75:ef:
3b:6e:c6:e0
-----BEGIN CERTIFICATE-----
MIID2DCCAsCgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBjzELMAkGA1UEBhMCSU4x
EjAQBgNVBAgTCUthcm5hdGFrYTESMBAGA1UEBxMJQmFuZ2Fsb3JlMQ4wDAYDVQQK
EwVOb2tpYTEMMAoGA1UECxMDSU1TMQ8wDQYDVQQDEwZtYXJzMDQxKTAnBgkqhkiG
9w0BCQEWGmtpc2hvcmUudmVybmVrYXJAbm9raWEuY29tMB4XDTE2MDgyNjA5Mzcw
NVoXDTE5MTIwOTA5MzcwNVowezELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5h
dGFrYTEOMAwGA1UEChMFTm9raWExDDAKBgNVBAsTA0lNUzEPMA0GA1UEAxMGbWFy
czA0MSkwJwYJKoZIhvcNAQkBFhpraXNob3JlLnZlcm5la2FyQG5va2lhLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApFEOxX7r6Y6JnHlqtZTTlFNDsiZH
pRMlh6NzAydP+LJghgCzx4rUvTxwMx4WSwrnp1CmSA4zz25yMBPAvRqzV+zsvWuQ
hPR5qSlIUH3gByLFzLGBTY1h9cZYh3PgG7mh/KAaQnmW9hHPCmD+JtTjprjKjSxI
sUFe+GSmLwLlW48CAwEAAaOB1TCB0jAJBgNVHRMEAjAAMIHEBgNVHSMEgbwwgbmA
FMUFatcbmuG2paIvcCsTxsJ02nBFoYGVpIGSMIGPMQswCQYDVQQGEwJJTjESMBAG
A1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxDjAMBgNVBAoTBU5v
a2lhMQwwCgYDVQQLEwNJTVMxDzANBgNVBAMTBm1hcnMwNDEpMCcGCSqGSIb3DQEJ
ARYaa2lzaG9yZS52ZXJuZWthckBub2tpYS5jb22CCQCwxVSs+Hh7XzANBgkqhkiG
9w0BAQQFAAOCAQEANq7XqsLOIJHJV3fnS8XhtShdS4XbA5BnTvl9sTWM3oBtv/XQ
yRsQisLeXojW9g38BZLwiIGYjMmkVxtwfY3ckMnN43cfgfBjOUIU/9ZGy/mELI3M
HrW5ahIqxNRc+nmm6qibU2VUyWik2GMPZKU1iG2fO7/d7F9plaIXlJfJJonSGxIv
OTUfqkHQIy8OyIMCnXBG/yM9W0ZY+v8cP9GbeCG5z661PGQScJJxD5+w+VRq51FB
sGYvClehp+b44HtGfeVmt/fp1CMWibC8jsXmuWmhvCuYCPwQnJ5xqLbB+ppxWnmd
B8tz1OdaARZ2OG4pi2oScumsNlSin3XvO27G4A==
-----END CERTIFICATE-----
java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
...
Signature Algorithm: md5WithRSAEncryption
This is pretty bad. MD5 as signature algorithm is broken for many years and this brokenness was already used successfully in major attacks years ago (Stuxnet). My guess is that Java complains about this.
Since the certificates are obviously just created recently someone messed up this certificate creation badly. Don't try to work around it but instead create proper certificates, i.e. using a proper signature algorithm (SHA-256 instead of MD5) and a proper key size (2048 instead of 1024).
The keystore contains CA,Certificate,and the private Key
bash:$ keytool -list -keystore my.keystore
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 6 entries
xyz-server-ca, Nov 12, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): F1:94:1E:B3:C1:E7:7E:54:DA:6B:12:35:26:AA:4C:DE:46:D6:45:3F
xyz-key, Nov 12, 2015, PrivateKeyEntry,
Certificate fingerprint (SHA1): 81:45:05:29:15:26:0C:0E:71:EB:E0:1F:3E:1C:D8:FE:C6:8D:78:69
xyz-root-ca, Nov 12, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 67:D6:A8:37:AD:16:15:31:6D:55:78:02:F2:FA:AB:7A:2A:75:F0:DF
server, Nov 12, 2015, trustedCertEntry,
Certificate fingerprint (SHA1):
xyz-root-ca1, Nov 12, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 67:D6:A8:37:AD:36:15:31:6D:55:78:02:F2:FA:AB:7A:2A:75:F0:DF
server, Nov 12, 2015, trustedCertEntry,
Certificate fingerprint (SHA1):
When i do to view the certificate chain using openssl, it doesn't return me all the chain, instead of it's just return the server Certificate and one CA file
openssl s_client -host 127.0.0.1 -port 443 -prexit -showcerts
---
Certificate chain
0 s:/C=EU/ST=I/L=Du/O=Inc./OU=Foot/CN=example.com
i:/C= EU/O=I/OU=Du/CN=Servers CA
It is expected behavior. When making an SSL handshake, server responds with its own SSL certificate and all CA certificates in the chain *except root certificate*. A reference from [RFC 5246 ยง7.4.2][1]:
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
In other words, it is a good practice to NOT send root (which is presented in a self-signed form) certificate during SSL negotiation.
[1]: https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2
I am trying to install SSL certificate in Tomcat7. This is what i have done so far.
installed ssl certificate received on email
sudo ./keytool -import -trustcacerts -alias download.addressdoctor -keystore /usr/local/tomcat7/bin/keystore.jks -file /usr/local/tomcat7/conf/certx509.cer
Installed Intermediate certificate
sudo ./keytool -import -trustcacerts -alias intermediate -keystore /usr/local/tomcat7/bin/keystore.jks -file /usr/local/tomcat7/conf/combined.cer
These is my entries in keystore
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
Alias name: adnewkey
Creation date: Sep 10, 2014
Entry type: trustedCertEntry
Owner: CN=website.com, OU=IT, O=company, L=City, ST=state, C=country
*******************************************
*******************************************
Alias name: mykey
Creation date: Sep 10, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=website.com, OU=IT, O=company
Now if i try to check the certificate through https://ssltools.websecurity.symantec.com/checker/views/certCheck.jsp
It says it is self signed certificate, whereas i installed the certificate received from verisign. If i remove the entry "alias mykey" then it will show error no root certificate found.
Can you please help me in pointing out what i am doing wrong, also for running SSL certificate what values should be present in the keystore.
Thanks,