{"id":352555,"date":"2024-05-20T22:10:55","date_gmt":"2024-05-20T22:10:55","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=352555"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=352555","title":{"rendered":"Making Java 8 aware of Let’s Encrypt root certificate<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

To begin with, we need to understand some terminology and concepts that form a backbone and stand behind the topic, so we will understand why the issue occurs and how to solve it.<\/p>\n

Certificate Authority (CA)<\/em>\u00a0is an organisation that issues digital certificates.\u00a0<\/p>\n

Root Certificate\u00a0<\/em>is a self-signed certificate that represents the top-level (or root) in a certificate chain. Root certificates are distributed in software trust stores, like those in web browsers or operating systems. When you trust a root certificate, you inherently trust all certificastes signed by that root.<\/p>\n

Prior to September 2021 Let’s Encrypt was using root certificate issued by a CA called\u00a0Digital Signature Trust Co.\u00a0<\/em>(often abbreviated as\u00a0DST<\/em>\u00a0or\u00a0IdenTrust<\/em>). The certificate name was\u00a0DST Root CA X3<\/em>,<\/p>\n

In present time\u00a0the organization behind Let’s Encrypt is ISRG (Internet Security Research Group) and thus ISRG is CA. The certificates issued by it are\u00a0ISRG Root X1<\/em>\u00a0and\u00a0ISRG Root X2.<\/em><\/p>\n

The main determining factor for whether a platform can validate Let\u2019s Encrypt certificates is whether that platform trusts ISRG\u2019s \u201cISRG Root X1<\/em>\u201d certificate. Prior to September 2021, some platforms could validate Let’s Encrypt certificates even though they don\u2019t include\u00a0ISRG Root X1<\/em>, because they trusted IdenTrust\u2019s \u201cDST Root CA X3<\/em>\u201d certificate. From October 2021 onwards, only those platforms that trust\u00a0ISRG Root X1<\/em>\u00a0will validate Let\u2019s Encrypt certificates.<\/p>\n

Every JRE has its own keystore, which contains all Certificate Authorities it trusts. This is also referred to as a\u00a0truststore<\/em>. This\u00a0truststore<\/em>\u00a0is stored as a file called\u00a0cacerts<\/em>. It is typically located in\u00a0$JAVA_HOME\/jre\/lib\/security<\/em>\u00a0for Java 8 and in\u00a0$JAVA_HOME\/jre\/lib\/security<\/em>\u00a0for Java 11 and Java 17, assuming $JAVA_HOME<\/em>\u00a0is where your JRE or JDK is installed. The default password for this keystore is\u00a0changeit<\/em>.<\/p>\n

That being said, Java 8 updates released prior to January 2017 (versions < 8u141) did not include the «ISRG Root X1<\/em>» certificate in their default truststore. At the same time Java 11 includes root certificates of both CAs and Java 17 includes only «ISRG Root X1<\/em>«.<\/p>\n

The tool for work with JRE keystore is called\u00a0keytool<\/em>\u00a0and located in\u00a0$JAVA_HOME\/bin\/keytool.<\/em>\u00a0<\/p>\n

Use the following commands to view whether needed CA are located in the relevant keystores<\/p>\n

# For Java 8 $  $JAVA_HOME\/bin\/keytool -list -keystore  $JAVA_HOME\/jre\/lib\/security\/cacerts -storepass changeit | grep -iE \"isrg|dstx3\" identrustdstx3, May 5, 2016, trustedCertEntry,   # For Java 11 $  $JAVA_HOME\/bin\/keytool -list -keystore  $JAVA_HOME\/lib\/security\/cacerts -storepass changeit | grep -iE \"isrg|dstx3\" identrustdstx3 [jdk], Sep 30, 2000, trustedCertEntry, letsencryptisrgx1 [jdk], Jun 4, 2015, trustedCertEntry,   # For Java 17 $  $JAVA_HOME\/bin\/keytool -list -keystore  $JAVA_HOME\/security\/cacerts -storepass changeit | grep -iE \"isrg|dstx3\" _,cus,ointernet_security_research_group,cnisrg_root_x1 [jdk], Jun 4, 2015, trustedCertEntry, _,cus,ointernet_security_research_group,cnisrg_root_x2 [jdk], Sep 4, 2020, trustedCertEntry,<\/code><\/pre>\n
You can note here that Java 17 also includes the new\u00a0ISRG Root X2<\/em>\u00a0root certificate that is using ECDSA encription unlike RSA encryption used by\u00a0ISRG Root X1.<\/em>  <\/p>\n
So you need <\/p>\n
The solution for old Java 8 JRE would be to make the JRE trust to the new CA of Let’s Encrypt, which is ISRG. <\/p>\n
# Download the ISRG Root X1 certificate in PEM format from the Let's Encrypt website. wget --no-check-certificate https:\/\/letsencrypt.org\/certs\/isrgrootx1.pem.txt -O \/tmp\/isrgrootx1.pem  # Import the new trusted root certificate into JRE truststore with the keytool $JAVA_HOME\/bin\/keytool -import -alias letsencryptisrgx1 -keystore $JAVA_HOME\/jre\/lib\/security\/cacerts -file \/tmp\/isrgrootx1.pem<\/code><\/pre>\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/755544\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
<\/div>\n
\n
\n
\n
\n
To begin with, we need to understand some terminology and concepts that form a backbone and stand behind the topic, so we will understand why the issue occurs and how to solve it.<\/p>\n
Certificate Authority (CA)<\/em>\u00a0is an organisation that issues digital certificates.\u00a0<\/p>\n
Root Certificate\u00a0<\/em>is a self-signed certificate that represents the top-level (or root) in a certificate chain. Root certificates are distributed in software trust stores, like those in web browsers or operating systems. When you trust a root certificate, you inherently trust all certificastes signed by that root.<\/p>\n
Prior to September 2021 Let’s Encrypt was using root certificate issued by a CA called\u00a0Digital Signature Trust Co.\u00a0<\/em>(often abbreviated as\u00a0DST<\/em>\u00a0or\u00a0IdenTrust<\/em>). The certificate name was\u00a0DST Root CA X3<\/em>,<\/p>\n
In present time\u00a0the organization behind Let’s Encrypt is ISRG (Internet Security Research Group) and thus ISRG is CA. The certificates issued by it are\u00a0ISRG Root X1<\/em>\u00a0and\u00a0ISRG Root X2.<\/em><\/p>\n
The main determining factor for whether a platform can validate Let\u2019s Encrypt certificates is whether that platform trusts ISRG\u2019s \u201cISRG Root X1<\/em>\u201d certificate. Prior to September 2021, some platforms could validate Let’s Encrypt certificates even though they don\u2019t include\u00a0ISRG Root X1<\/em>, because they trusted IdenTrust\u2019s \u201cDST Root CA X3<\/em>\u201d certificate. From October 2021 onwards, only those platforms that trust\u00a0ISRG Root X1<\/em>\u00a0will validate Let\u2019s Encrypt certificates.<\/p>\n
Every JRE has its own keystore, which contains all Certificate Authorities it trusts. This is also referred to as a\u00a0truststore<\/em>. This\u00a0truststore<\/em>\u00a0is stored as a file called\u00a0cacerts<\/em>. It is typically located in\u00a0$JAVA_HOME\/jre\/lib\/security<\/em>\u00a0for Java 8 and in\u00a0$JAVA_HOME\/jre\/lib\/security<\/em>\u00a0for Java 11 and Java 17, assuming $JAVA_HOME<\/em>\u00a0is where your JRE or JDK is installed. The default password for this keystore is\u00a0changeit<\/em>.<\/p>\n
That being said, Java 8 updates released prior to January 2017 (versions < 8u141) did not include the «ISRG Root X1<\/em>» certificate in their default truststore. At the same time Java 11 includes root certificates of both CAs and Java 17 includes only «ISRG Root X1<\/em>«.<\/p>\n
The tool for work with JRE keystore is called\u00a0keytool<\/em>\u00a0and located in\u00a0$JAVA_HOME\/bin\/keytool.<\/em>\u00a0<\/p>\n
Use the following commands to view whether needed CA are located in the relevant keystores<\/p>\n
# For Java 8 $  $JAVA_HOME\/bin\/keytool -list -keystore  $JAVA_HOME\/jre\/lib\/security\/cacerts -storepass changeit | grep -iE \"isrg|dstx3\" identrustdstx3, May 5, 2016, trustedCertEntry,   # For Java 11 $  $JAVA_HOME\/bin\/keytool -list -keystore  $JAVA_HOME\/lib\/security\/cacerts -storepass changeit | grep -iE \"isrg|dstx3\" identrustdstx3 [jdk], Sep 30, 2000, trustedCertEntry, letsencryptisrgx1 [jdk], Jun 4, 2015, trustedCertEntry,   # For Java 17 $  $JAVA_HOME\/bin\/keytool -list -keystore  $JAVA_HOME\/security\/cacerts -storepass changeit | grep -iE \"isrg|dstx3\" _,cus,ointernet_security_research_group,cnisrg_root_x1 [jdk], Jun 4, 2015, trustedCertEntry, _,cus,ointernet_security_research_group,cnisrg_root_x2 [jdk], Sep 4, 2020, trustedCertEntry,<\/code><\/pre>\n
You can note here that Java 17 also includes the new\u00a0ISRG Root X2<\/em>\u00a0root certificate that is using ECDSA encription unlike RSA encryption used by\u00a0ISRG Root X1.<\/em>  <\/p>\n
So you need <\/p>\n
The solution for old Java 8 JRE would be to make the JRE trust to the new CA of Let’s Encrypt, which is ISRG. <\/p>\n
# Download the ISRG Root X1 certificate in PEM format from the Let's Encrypt website. wget --no-check-certificate https:\/\/letsencrypt.org\/certs\/isrgrootx1.pem.txt -O \/tmp\/isrgrootx1.pem  # Import the new trusted root certificate into JRE truststore with the keytool $JAVA_HOME\/bin\/keytool -import -alias letsencryptisrgx1 -keystore $JAVA_HOME\/jre\/lib\/security\/cacerts -file \/tmp\/isrgrootx1.pem<\/code><\/pre>\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/755544\/<\/a>
<\/br><\/br><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-352555","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/352555","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=352555"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/352555\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=352555"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=352555"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=352555"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}