Crypt::LE - Let's Encrypt / Buypass / ZeroSSL and other ACME-servers client and library in Perl for obtaining free SSL certificates (inc. generating RSA/ECC keys and CSRs). HTTP/DNS verification is supported out of the box, EAB (External Account Binding) supported, easily extended with plugins, easily dockerized.
I don't know if my issue is similar or related to some of the other current issues is not.
Some IOT devices (VoIP Telephone in my case) have limited storage or ability to retrieve the root and intermediate certificates on their own. When I created my PowerShell Script to use LE64.exe I figured out (some how -- don't recall) that one could append the Root and Intermediate Certificates to the original CRT PEM File and this is often referred as a "CA Bundle". When I initially wrote my script I had to perform this step myself then later on I discovered that LE64 was doing this for me.
However starting with the expiration of DST Root CA X3 certificate, that expired on 2021-09-30, I find that LE64.exe is no longer generating a "CA Bundle" PEM file that is compatible with my IOT device. In this case the IOT device is a Yealink T46G VoIP Telephone with the latest firmware approved by the PBX vendor. I'm using LE64.exe v.0.38 on Windows Server 2016 Build 14393.4104.
I also went as far as forcing LE64.exe to generate a new Certificate, by forcing the --renew option to 89 days. Now the Signed Certificate is valid from Thursday, October 14, 2021 10:38:04 PM until Wednesday, January 12, 2022 10:38:03 PM so that the expired root certificate should NOT be present in the CRT File as part of the "CA Bundle".
I tried to figure this out by process of elimination. I added and then removed different certificate blocks in the CRT File after the Signed Certificate. However, this still eludes me as to why. I am not a SME on this topic just poking around to get this working again in the office.
What I ended up doing is going to Let's Encrypt Chain of Trust web page and downloaded the ISRG Root X1 and R3 CA PEM files. Then I wrote a test script that reads the LE64 generated CRT file and stops at the first occurrence of "-----END CERTIFICATE-----" which according to RFC contains the Signed Certificate Block; then I dumped that data block into a new file; then appended the Root and Intermediate Cert Blocks I retrieved from Let's Encrypt.
Well guess what?!?! After restarting NGINX on the Server my IOT devices were able to use HTTPs to securely download the XML file it was looking.
One thing I would like to request is an option so that LE64 does NOT create a CABundle File; called "--nocabundle". It would then also be helpful to have a option, called --append-crt, that would provide a list of files to append after to the Signed Certificate Block. If one would use add to the command line "--nocabundle -append-crt example.com-ca-bundle.pem" then I would get the desired results that I've implemented in my PowerShell Script.
Maybe this is not necessary long term as LE64.exe should generate a correct "CA Bundle" for the Signed Certificate.
PS: Please note that I started using LE64.exe with my script since v0.33 by the way -- quite some time!
I don't know if my issue is similar or related to some of the other current issues is not.
Some IOT devices (VoIP Telephone in my case) have limited storage or ability to retrieve the root and intermediate certificates on their own. When I created my PowerShell Script to use LE64.exe I figured out (some how -- don't recall) that one could append the Root and Intermediate Certificates to the original CRT PEM File and this is often referred as a "CA Bundle". When I initially wrote my script I had to perform this step myself then later on I discovered that LE64 was doing this for me.
However starting with the expiration of DST Root CA X3 certificate, that expired on 2021-09-30, I find that LE64.exe is no longer generating a "CA Bundle" PEM file that is compatible with my IOT device. In this case the IOT device is a Yealink T46G VoIP Telephone with the latest firmware approved by the PBX vendor. I'm using LE64.exe v.0.38 on Windows Server 2016 Build 14393.4104.
I also went as far as forcing LE64.exe to generate a new Certificate, by forcing the --renew option to 89 days. Now the Signed Certificate is valid from Thursday, October 14, 2021 10:38:04 PM until Wednesday, January 12, 2022 10:38:03 PM so that the expired root certificate should NOT be present in the CRT File as part of the "CA Bundle".
I tried to figure this out by process of elimination. I added and then removed different certificate blocks in the CRT File after the Signed Certificate. However, this still eludes me as to why. I am not a SME on this topic just poking around to get this working again in the office.
What I ended up doing is going to Let's Encrypt Chain of Trust web page and downloaded the ISRG Root X1 and R3 CA PEM files. Then I wrote a test script that reads the LE64 generated CRT file and stops at the first occurrence of "-----END CERTIFICATE-----" which according to RFC contains the Signed Certificate Block; then I dumped that data block into a new file; then appended the Root and Intermediate Cert Blocks I retrieved from Let's Encrypt.
Well guess what?!?! After restarting NGINX on the Server my IOT devices were able to use HTTPs to securely download the XML file it was looking.
One thing I would like to request is an option so that LE64 does NOT create a CABundle File; called "--nocabundle". It would then also be helpful to have a option, called --append-crt, that would provide a list of files to append after to the Signed Certificate Block. If one would use add to the command line "--nocabundle -append-crt example.com-ca-bundle.pem" then I would get the desired results that I've implemented in my PowerShell Script.
Maybe this is not necessary long term as LE64.exe should generate a correct "CA Bundle" for the Signed Certificate.
PS: Please note that I started using LE64.exe with my script since v0.33 by the way -- quite some time!