Develop Reference

Enabling SSL in Wildfly 17: Browser is showing certificate is not valid

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.

How can I replace the expired intermediate CA certificate in a keystore file?

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.

JDK Jarsigner : jar is unsigned. (signatures missing or not parsable)

I Signed with JDK:1.8 jarsigner.
Verify Results with JDK:1.8:
C:\glassfish4\jdk8\bin\jarsigner -verify sample_sha1_sha1.jar -verbose
Timestamped by "***" on Wed Jun 06 17:59:57 UTC 2018
Timestamp digest algorithm: SHA-1
Timestamp signature algorithm: SHA256withRSA, 2048-bit key
jar verified.
But same signed jar when i verify with JDK: 1.7_21_b11, it says jar unsigned.
Results:
C:\glassfish4\jdk7\bin\jarsigner -verify sample_sha1_sha1.jar -verbose
898 Wed Jun 06 17:59:56 IST 2018 META-INF/MANIFEST.MF
m 172 Wed Nov 16 18:45:40 IST 2016 META-INF/NOTICE
m 10351 Wed Nov 16 18:45:40 IST 2016 META-INF/LICENSE
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
jar is unsigned. (signatures missing or not parsable)
Please help me how to solve this.

certificate chain is not coming with server certificate

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

Why does Java Web Start say a signed jar file is unsigned?

Java Web Start (JWS) says that it can't launch my application because the jar file is unsigned:
Error: Unsigned application requesting unrestricted access to system
Unsigned resource: .../dynaccn.jar
But the jar file is signed:
$ jarsigner -keystore ... dynaccn.jar idv
$ jar tf dynaccn.jar
META-INF/MANIFEST.MF
META-INF/IDV.SF
META-INF/IDV.RSA
META-INF/
edu/
edu/ucar/
edu/ucar/unidata/
edu/ucar/unidata/dynaccn/
App$1.class
...
$ jarsigner -verbose -certs -verify dynaccn.jar
28325 Tue Aug 17 09:41:58 MDT 2010 META-INF/MANIFEST.MF
28404 Tue Aug 17 09:41:58 MDT 2010 META-INF/IDV.SF
2880 Tue Aug 17 09:41:58 MDT 2010 META-INF/IDV.RSA
0 Tue Aug 17 09:41:58 MDT 2010 META-INF/
0 Mon Aug 16 10:10:34 MDT 2010 edu/
0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/
0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/unidata/
0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/unidata/dynaccn/
...
sm 486 Mon Aug 16 10:10:34 MDT 2010 App$1.class
X.509, CN=University Corporation for Atmospheric Research, OU=UNIDATA, O=University Corporation for Atmospheric Research, L=Boulder, ST=Colorado, C=US
[certificate will expire on 2/6/11 4:59 PM]
X.509, CN=Thawte Code Signing CA, O=Thawte Consulting (Pty) Ltd., C=ZA
[certificate is valid from 8/5/03 6:00 PM to 8/5/13 5:59 PM]
[KeyUsage extension does not support code signing]
X.509, EMAILADDRESS=premium-server#thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
[certificate is valid from 7/31/96 6:00 PM to 12/31/20 4:59 PM]
[CertPath not validated: null]
...
jar verified.
Warning:
This jar contains entries whose signer certificate's KeyUsage extension doesn't allow code signing.
This jar contains entries whose signer certificate will expire within six months.
This jar contains entries whose certificate chain is not validated.
This jar contains signed entries that's not signed by alias in this keystore.
and both JWS and my browser have a certificate for "Thawte Premium Server CA".
The problem occurs even if the JWS cache and the browser download area are empty.
I don't believe the "KeyUsage" message is relevant because 1) the same certificate chain is used for another application that does launch successfully; and 2) documentation I've read indicates that the Thawte Code Signing CA is only used to verify the UNIDATA certificate and not to sign code.
My environment is Linux 2.6.27.41-170.2.117.fc10.x86_64, Firefox 3.6.8 (i686), and Java 1.7.0-ea.
Why won't this application launch?
UPDATE: I've discovered that the application launches if the "codebase" attribute in the JNLP file references a local directory but not if it references a URL that lies behind user authentication. In the latter case, javaws(1) interprets the authentication webpage as a JNLP file (with obvious results) if invoked from the command-line. If invoked by the "deployJava" script from a user-authenticating webpage (so that the browser has a session cookie), then javaws(1) says that the application isn't signed. I find both of these failure modes odd as the javaws(1) documentation says that it understands user authenticating web pages and the jar file is signed.

I'm on Gentoo Linux, running OpenJDK 7, and I think I experienced the same problem.
I could not get it to work with OpenJDK 7. Only re-signing with a release of the Sun Java 6 JDK ultimately signed the application correctly. (I also re-built it all due to it being managed by ant, I don't know if that is necessary, though).
Merely switching to the official JDK 6 without rebuilding only makes the "[CertPath not validated: null]" warning when varifying with "jarsigner -verify -verbose -certs" disappear, but does not appear to work in the application I ultimately use.

make sure you are not using a cached (unsigned) version of the jar. Clean the temp folder where JWS downloads jars
make sure that all dependencies (jars) of your jar, that require special permissions, are also signed

Make sure you wrap your calls in the applet with a doPrivileged block. I am unsure why it works like this but seems to work like a charm.