Develop Reference

jarsigner reporting different certificate expiration

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?

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.

Import Verisign SSL Certificate in Tomcat7

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,

Java TLS client can't find certificate when accessing soap service

I have a java app that runs inside Tomcat. It is trying to access a TLS client certificate authenticated SOAP service. All certificates being used are self-signed. I specify the trustStore and keyStore via the Java Options in Tomcat and I have also tried doing it in code for all the needed properties before creating my service. Both keyStore and trustStore are JKS with RSA certificates. I have verified the certificates exist in the server's trustStore and that the self client certificate exists in the client keyStore and that the hashes are the same.
Client side:
c:\Program Files\Java\jre7\bin>keytool -list -keystore c:\tomcat\certs\tomcat.keystore
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
tomcat, Jan 20, 2014, PrivateKeyEntry,
Certificate fingerprint (SHA1): 78:F3:30:A0:40:B0:CC:8D:86:1F:99:FF:7C:3B:85:7C:6D:C7:F2:D2
Server side:
C:\Program Files (x86)\Java\jre7\bin>keytool -list -keystore c:\tomcat\certs\tomcat.truststore
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
clientcert, Jan 23, 2014, trustedCertEntry,
Certificate fingerprint (SHA1): 78:F3:30:A0:40:B0:CC:8D:86:1F:99:FF:7C:3B:85:7C:6D:C7:F2:D2
When I start Tomcat I see the loading of the keystore like this:
keyStore is : c:\tomcat\certs\tomcat.keystore
keyStore type is : JKS
keyStore provider is :
init keystore
init keymanager of type SunX509
***
found key for : tomcat
chain [0] = [
[
Version: V3
Subject: CN=Name, OU=Engineering, O=MyOrg, ST=NJ, C=US
...
At the end of server hello I see the certificate DN that I expect and was loaded from the keystore above:
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<CN=Name, OU=Engineering, O=MyOrg, ST=NJ, C=US>
[read] MD5 and SHA1 hashes: len = 115
...
Then immediately after the ServerHelloDone I see an empty Certificate chain with no "matching alias: mycert" logging like I would expect to see.
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
*** Certificate chain
***
Server side I get this:
http-nio-8443-exec-2, READ: TLSv1 Handshake, length = 269
*** Certificate chain
***
http-nio-8443-exec-2, fatal error: 42: null cert chain
javax.net.ssl.SSLHandshakeException: null cert chain
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
http-nio-8443-exec-2, SEND TLSv1 ALERT: fatal, description = bad_certificate
http-nio-8443-exec-2, WRITE: TLSv1 Alert, length = 2
http-nio-8443-exec-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: null cert chain
http-nio-8443-exec-2, called closeOutbound()
http-nio-8443-exec-2, closeOutboundInternal()
When I take the client's certificate and I load it into my browser and navigate to the site, I am prompted to choose the certificate and able to see the wsdl and such. So I believe the certificate is fine.
The Java client uses it's trustStore specified in the Java options just fine to validate the server which makes me believe the trustStore is loaded and used just fine. Finally, here's the client piece of code I think is responsible for creating the service:
System.setProperty("javax.net.ssl.keyStore","C:\\tomcat\\certs\\tomcat.keystore");
System.setProperty("javax.net.ssl.keyStorePassword", "password");
System.setProperty("javax.net.ssl.keyStoreType", "JKS");
System.setProperty("javax.net.ssl.trustStore","C:\\tomcat\\certs\tomcat.truststore");
System.setProperty("javax.net.ssl.trustStorePassword", "password");
System.setProperty("javax.net.ssl.trustStoreType", "JKS");
URL url = DocumentRepositoryProxy.class.getClassLoader().getResource("XDS.b_DocumentRepositoryWSDLSynchMTOM.wsdl");
QName qname = new QName("urn:ihe:iti:xds-b:2007", "DocumentRepository_Service");
DocumentRepositoryService service = new DocumentRepositoryService(url, qname);
if (handlerResolver != null)
service.setHandlerResolver(handlerResolver);
proxy = service.getDocumentRepositoryPortSoap12(new MTOMFeature(true, 1));
BindingProvider bp = (BindingProvider) proxy;
SOAPBinding binding = (SOAPBinding) bp.getBinding();
binding.setMTOMEnabled(true);
bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpoint);
I've spent the majority of a week going down this rabbit hole and if anyone can help it'll save me some hairs.

Here's the answer. In my WEB-INF/cxf-servlet.xml file for my WebApp I needed to add this chunk of XML and the associated namespaces. The Java options in code were ignored completely so I removed them. Once I added this and restarted Tomcat everything worked on the first try.
Namespaces:
xmlns:sec="http://cxf.apache.org/configuration/security"
xmlns:http="http://cxf.apache.org/transports/http/configuration"
Elements:
<http:conduit name="*.http-conduit">
<http:tlsClientParameters>
<sec:keyManagers keyPassword="XXX">
<sec:keyStore type="JKS"
password="password"
file="C:/tomcat/certs/tomcat.keystore"/>
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS"
password="password"
file="C:\tomcat\certs\tomcat.truststore"/>
</sec:trustManagers>
</http:tlsClientParameters>
</http:conduit>