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

Question

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

Answer 1

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.