Payara: SSL certificates have expired, payara embedded all, 4.1.2.181

[graug]

# Description #

When running integration tests with payara embedded all, version 4.1.2.181, I see warnings about expired certificates.

Expected Outcome

No certificate warnings on startup of payara server.

Current Outcome

Aug 23, 2018 9:14:16 PM fish.payara.arquillian.container.payara.embedded.PayaraContainer executeCommand
[...]
Aug 23, 2018 9:14:19 PM com.sun.enterprise.security.ssl.impl.SecuritySupportImpl checkCertificateDates
SEVERE: The SSL certificate has expired: [
[
Version: V3
Subject: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: Sun RSA public key, 1024 bits
modulus: 135786214035069526348186531221551781468391756233528066061569654028671100866720352830303278016129003918213826297308054231261658522889438712013757624116391437358730449661353175673177742307421061340003741057138887918110217006515773038453829253517076741780039735595086881329494037450587568122088113584549069375417
public exponent: 65537
Validity: [From: Sat Aug 22 18:41:51 CEST 1998,
To: Wed Aug 22 18:41:51 CEST 2018]
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
SerialNumber: [ 35def4cf]

Certificate Extensions: 7
Extension unknown: DER encoded OCTET string =
0000: 04 0D 30 0B 1B 05 56 33 2E 30 63 03 02 06 C0 ..0...V3.0c....

AuthorityKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
]
]

BasicConstraints:[
CA:true
PathLen:2147483647
]

CRLDistributionPoints [
[DistributionPoint:
[CN=CRL1, OU=Equifax Secure Certificate Authority, O=Equifax, C=US]
]]

KeyUsage [
Key_CertSign
Crl_Sign
]

PrivateKeyUsage: [
To: Wed Aug 22 18:41:51 CEST 2018]

SubjectKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
]
]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 58 CE 29 EA FC F7 DE B5 CE 02 B9 17 B5 85 D1 B9 X.).............
0010: E3 E0 95 CC 25 31 0D 00 A6 92 6E 7F B6 92 63 9E ....%1....n...c.
0020: 50 95 D1 9A 6F E4 11 DE 63 85 6E 98 EE A8 FF 5A P...o...c.n....Z
0030: C8 D3 55 B2 66 71 57 DE C0 21 EB 3D 2A A7 23 49 ..U.fqW..!.=.#I
0040: 01 04 86 42 7B FC EE 7F A2 16 52 B5 67 67 D3 40 ...B......R.gg.@
0050: DB 3B 26 58 B2 28 77 3D AE 14 77 61 D6 FA 2A 66 .;&X.(w=..wa..f
0060: 27 A0 0D FA A7 73 5C EA 70 F1 94 21 65 44 5F FA '....s.p..!eD_.
0070: FC EF 29 68 A9 A2 87 79 EF 79 EF 4F AC 07 77 38 ..)h...y.y.O..w8

]
Aug 23, 2018 9:14:19 PM com.sun.enterprise.security.ssl.impl.SecuritySupportImpl checkCertificateDates
SEVERE: The SSL certificate has expired: [
[
Version: V1
Subject: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4

Key: Sun RSA public key, 1024 bits
modulus: 104674226241368487598835828377585222181792546532354327780214427055917513664449991602803276678454577364904540367827644455215731003386468752240014232146814457308076052176227490263634768927290191763858631579785604655038492469791381988347440106477066514204303723029602991655085187937840556671697442212352844587673
public exponent: 65537
Validity: [From: Thu Aug 13 02:29:00 CEST 1998,
To: Tue Aug 14 01:59:00 CEST 2018]
Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
SerialNumber: [ 01a5]

]
Algorithm: [MD5withRSA]
Signature:
0000: 6D EB 1B 09 E9 5E D9 51 DB 67 22 61 A4 2A 3C 48 m....^.Q.g"a.* 0010: 77 E3 A0 7C A6 DE 73 A2 14 03 85 3D FB AB 0E 30 w.....s....=...0
0020: C5 83 16 33 81 13 08 9E 7B 34 4E DF 40 C8 74 D7 [email protected].
0030: B9 7D DC F4 76 55 7D 9B 63 54 18 E9 F0 EA F3 5C ....vU..cT.....\
0040: B1 D9 8B 42 1E B9 C0 95 4E BA FA D5 E2 7C F5 68 ...B....N......h
0050: 61 BF 8E EC 05 97 5F 5B B0 D7 A3 85 34 C4 24 A7 a....._[....4.$.
0060: 0D 0F 95 93 EF CB 94 D8 9E 1F 9D 5C 85 6D C7 AA ............m..
0070: AE 4F 1F 22 B5 CD 95 AD BA A7 CC F9 AB 0B 7A 7F .O."..........z.

]

Steps to reproduce (Only for bug reports)

run an arquillian integration test using payara embedded all, 4.1.2.181 as test container

        <dependency>
            <groupId>fish.payara.arquillian</groupId>
            <artifactId>arquillian-payara-server-4-embedded</artifactId>
            <version>1.0.Beta3</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>fish.payara.extras</groupId>
            <artifactId>payara-embedded-all</artifactId>
            <version>4.1.2.181</version>
            <scope>test</scope>
        </dependency>

Samples

A sample could be taken from here by replacing the micro with the embedded all version:
https://blog.payara.fish/how-to-test-applications-with-payara-server-micro-with-arquillian

Context (Optional)

Running automated integration tests using maven, arquillian and payara.

Environment

• Payara Version: 4.1.2.181
• Edition: embedded all
• JDK Version: 1.8.0u101 Oracle
• Operating System: Windows and Linux
• Database: Oracle (not relevant)

[triantium]

The expired certificate has the alias equifaxsecureca.
You can maybe remove it from the keystore with the command
keytool -delete -keystore cacerts.jks -alias equifaxsecureca -storePass changeit

[smillidge]

For 4.x you will need to remove the expired certificates using the commands above as 4.x is not supported outside of a support contract. For 5.x this will be fixed in the latest release and builds.

[andi-huber]

I run into the same issue using Payara 5.182, and as @Starkad suggested this solved it for me as well:

keytool -delete -keystore cacerts.jks -alias equifaxsecureca -storePass changeit

For reference:

• keytool is a binary provided by your JDK installation (likely found in JDK's bin folder)
• cacerts.jks is the keystore file as provided by the Payara installation (found in each of the domain folders)

Example usage on my Windows 10 installation:
D:\opt\jdk10\bin>keytool -delete -keystore "D:\opt\payara\payara5-web\glassfish\domains\domain1\config\cacerts.jks" -alias equifaxsecureca -storePass changeit

Update:
Also for reference and in case anyone wonders: The SSL expiry message on Payara startup is logged with level 'SEVERE', which had me confused. I first thought Payara fails to startup. But that is not the case!

[aapablaza]

Deleting the certificate is one option as pointed by @andi-huber , but I guess is not the optimal. It should be replaced, as well as the other expired certificates (there are like 3 or 4 expired certificates).
Are all certificates really needed?

[smillidge]

This is fixed in the master

[fransflippo]

I'm on the latest Payara Micro version (5.192) but still getting errors:

  Subject: CN=UTN - DATACorp SGC, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
  Validity: [From: Thu Jun 24 20:57:21 SAST 1999,
               To: Mon Jun 24 21:06:30 SAST 2019]
  Subject: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
  Validity: [From: Fri Jul 09 19:28:50 SAST 1999,
               To: Tue Jul 09 19:36:58 SAST 2019]
  Subject: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
  Validity: [From: Fri Jul 09 20:10:42 SAST 1999,
               To: Tue Jul 09 20:19:22 SAST 2019]
  Subject: CN=Class 3P Primary CA, O=Certplus, C=FR
  Validity: [From: Wed Jul 07 19:10:00 SAST 1999,
               To: Sun Jul 07 01:59:59 SAST 2019]
  Subject: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
  Validity: [From: Fri Jul 09 14:11:00 SAST 1999,
               To: Wed Jul 10 01:59:00 SAST 2019]
  Subject: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
  Validity: [From: Fri Jul 09 20:31:20 SAST 1999,
               To: Tue Jul 09 20:40:36 SAST 2019]
  Subject: [email protected], CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
  Validity: [From: Sat Jun 26 00:23:48 SAST 1999,
               To: Wed Jun 26 00:23:48 SAST 2019]
  Subject: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
  Validity: [From: Fri Jul 09 14:11:00 SAST 1999,
               To: Wed Jul 10 01:59:00 SAST 2019]
  Subject: [email protected], CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
  Validity: [From: Sat Jun 26 02:19:54 SAST 1999,
               To: Wed Jun 26 02:19:54 SAST 2019]
  Subject: CN=Class 2 Primary CA, O=Certplus, C=FR
  Validity: [From: Wed Jul 07 19:05:00 SAST 1999,
               To: Sun Jul 07 01:59:59 SAST 2019]
  Subject: CN=Class 2 Primary CA, O=Certplus, C=FR
  Validity: [From: Wed Jul 07 19:05:00 SAST 1999,
               To: Sun Jul 07 01:59:59 SAST 2019]

All of these expired in the past two months.

Does Payara have a regular release cycle? Then perhaps all certificates due to expire before the next release can be proactively replaced/removed as part of the release process?