Bug #119927 for Crypt-LE: Crypt::LE bug when using web connection to check certificate expiration

Fri Jan 20 12:51:11 2017 arielgrin [...] outlook.com - Ticket created

Subject:	Crypt::LE bug when using web connection to check certificate expiration
Date:	Fri, 20 Jan 2017 17:50:06 +0000
To:	"bug-Crypt-LE [...] rt.cpan.org" <bug-Crypt-LE [...] rt.cpan.org>, "leader [...] cpan.org" <leader [...] cpan.org>
From:	Ariel Grin <arielgrin [...] outlook.com>

Dear Alexander: I have installed your module Crypt::LE and I've managed to authorize my domain and generate my certificate. I think I found a bug on the way the module checks for certificate expiration when using a web connection instead of the local saved certificate. It seems as if the web connection check is retrieving one of the Let's Encrypt certificates, either the Root CA or the Intermediate Certificate. After running the renew command today, January 20th 2017, the remaining days before expiration are 1713, which corresponds to September 29th, 2021 and that is the "Not After" date of both Let's Encrypt certificates. If the renew command uses the local certificate, which was issued yesterday, the remaining days before expiration are 89, which is the correct value for my certificate. I see that there are 2 values at the start of the script, PEER_CRT and CRT_DEPTH that might have something to do with that, as currently the CRT_DEPTH is 3 and PEER_CRT is 1, at least that is what I can see from OpenSSL output when using s_client -showcerts -connect, OpenSSL retrieves 3 certificates and the last one showed is mine, but the script assigns PEER_CRT=4 and CRT_DEPTH=5 OS: Windows 2003 Server SP1 Perl: ActiveState Perl 5.12.4 Crypt::LE: 0.19 Thanks, Ariel.

Sat Jan 28 12:21:10 2017 LEADER [...] cpan.org - Correspondence added

Hello Ariel, Thank you for this report and the detailed description of the encountered issue. Please note that the constant you are referring to is not an actual value, but effectively an index in the structure where such value can be found. Basically CRT_DEPTH set to 5 does not mean that the 5th certificate in the chain will be checked - it just points out that the depth value is at the index 5th in the returned structure (array in this case). The script will then take the certificate which has that value as 0 and will return the results based on it. However, there is no strict checking for example whether the subject of the certificate matches our expectations (that might be added later), so if the server sends something else at depth 0, this might give wrong expiration count indeed. Could you please provide a domain name to checked this against? You can send it privately if you like via https://do-know.com/contact.html If there is indeed a problem with expiration calculations and SSL for the domain is configured correctly, I will look into fixing that as soon as possible. Best regards, Alexander.

Sat Jan 28 12:21:11 2017 The RT System itself - Status changed from 'new' to 'open'

Sat Jan 28 12:25:10 2017 LEADER [...] cpan.org - Taken

Sat Jan 28 12:25:24 2017 arielgrin [...] outlook.com - Correspondence added

Subject:	Re: [rt.cpan.org #119927] Crypt::LE bug when using web connection to check certificate expiration
Date:	Sat, 28 Jan 2017 17:24:32 +0000
To:	Alexander Yezhov via RT <bug-Crypt-LE [...] rt.cpan.org>
From:	Ariel Grin <arielgrin [...] outlook.com>

I think is a problem related to ActiveState Perl implementation, because I tried it too with Strawberry Perl and it returned the right expiration time. My domain is webmail.brokers.com.ar<http://webmail.brokers.com.ar> Enviado desde mi Móvil LG Show quoted text

------ Mensaje original------ Desde: Alexander Yezhov via RT Fecha: sáb., 28 ene. 2017 2:21 PM Para: arielgrin@outlook.com; Cc: Asunto:[rt.cpan.org #119927] Crypt::LE bug when using web connection to check certificate expiration <URL: https://rt.cpan.org/Ticket/Display.html?id=119927 > Hello Ariel, Thank you for this report and the detailed description of the encountered issue. Please note that the constant you are referring to is not an actual value, but effectively an index in the structure where such value can be found. Basically CRT_DEPTH set to 5 does not mean that the 5th certificate in the chain will be checked - it just points out that the depth value is at the index 5th in the returned structure (array in this case). The script will then take the certificate which has that value as 0 and will return the results based on it. However, there is no strict checking for example whether the subject of the certificate matches our expectations (that might be added later), so if the server sends something else at depth 0, this might give wrong expiration count indeed. Could you please provide a domain name to checked this against? You can send it privately if you like via https://do-know.com/contact.html If there is indeed a problem with expiration calculations and SSL for the domain is configured correctly, I will look into fixing that as soon as possible. Best regards, Alexander.

Sat Jan 28 14:05:00 2017 LEADER [...] cpan.org - Correspondence added

Hello Ariel, This is interesting indeed. I have just checked how the code would behave with the most recent ActiveState Perl version under Windows and the result was as expected, with the correct output produced. This could be down to some specifics in terms of libraries used, so I have attached a small script to this message, which should allow to see what exactly gets returned in the callbacks. If you could run it (like "perl crt.pl webmail.brokers.com.ar > out.txt") and send me the output, that could help to pinpoint the issue potentially or at least make the code adapt to this specific system behaviour. Regards, Alexander. On Sat Jan 28 17:25:24 2017, arielgrin@outlook.com wrote: Show quoted text

> I think is a problem related to ActiveState Perl implementation, > because I tried it too with Strawberry Perl and it returned the right > expiration time. My domain is > webmail.brokers.com.ar<http://webmail.brokers.com.ar> > > Enviado desde mi Móvil LG

Subject:

crt.pl

use HTTP::Tiny; use IO::Socket::SSL; use Net::SSLeay; use Data::Dumper; use strict; die "Please specify the domain" unless $ARGV[0]; print "Versions: $HTTP::Tiny::VERSION / $IO::Socket::SSL::VERSION / $Net::SSLeay::VERSION\n"; my $probe = HTTP::Tiny->new( agent => "Mozilla/5.0", verify_SSL => 1, timeout => 10, SSL_options => { SSL_verify_callback => sub { print Dumper(\@_) } } ); $probe->head("https://$ARGV[0]/");

Sun Jan 29 20:19:11 2017 arielgrin [...] outlook.com - Correspondence added

Subject:	Re: [rt.cpan.org #119927] Crypt::LE bug when using web connection to check certificate expiration
Date:	Mon, 30 Jan 2017 01:18:51 +0000
To:	"bug-Crypt-LE [...] rt.cpan.org" <bug-Crypt-LE [...] rt.cpan.org>
From:	Ariel Grin <arielgrin [...] outlook.com>

Dear Alexander: thank you SO MUCH for your help. I ran the perl script that you sent me and indeed, in my particular setup, the crt chain is retrieved in "reverse" way: Root CA first, then Intermediate and Client CRT at last. If I understood your explanation correctly, your LE script is not currently checking if the first retrieved certificate is actually the one for the requested domain, it just returns the first certificate it receives. Maybe there is a way to tell the script to choose a specific certificate, in my case that would be the third presented certificate. I'm attaching the output of the script and also the output of perl -V for my Win2003 Server. Again, thanks so much for your help. Regards, Ariel. Show quoted text

________________________________ From: Alexander Yezhov via RT <bug-Crypt-LE@rt.cpan.org> Sent: Saturday, January 28, 2017 4:05 PM To: arielgrin@outlook.com Subject: [rt.cpan.org #119927] Crypt::LE bug when using web connection to check certificate expiration <URL: https://rt.cpan.org/Ticket/Display.html?id=119927 > Hello Ariel, This is interesting indeed. I have just checked how the code would behave with the most recent ActiveState Perl version under Windows and the result was as expected, with the correct output produced. This could be down to some specifics in terms of libraries used, so I have attached a small script to this message, which should allow to see what exactly gets returned in the callbacks. If you could run it (like "perl crt.pl webmail.brokers.com.ar > out.txt") and send me the output, that could help to pinpoint the issue potentially or at least make the code adapt to this specific system behaviour. Regards, Alexander. On Sat Jan 28 17:25:24 2017, arielgrin@outlook.com wrote:

> I think is a problem related to ActiveState Perl implementation, > because I tried it too with Strawberry Perl and it returned the right > expiration time. My domain is > webmail.brokers.com.ar<http://webmail.brokers.com.ar> > > Enviado desde mi Móvil LG

Download crt.out
application/octet-stream 607b

Message body not shown because it is not plain text.

Download perl.out
application/octet-stream 2.8k

Message body not shown because it is not plain text.

Tue Jan 31 14:27:00 2017 LEADER [...] cpan.org - Correspondence added

Hi Ariel, It is not so much about an order the results are seen listed in, but about the structure being returned. In this case the depth is just not there. But it is certainly good to see what is happening - I'll schedule an update in to account for configurations like this. Thanks for reporting. Regards, Alexander. On Mon Jan 30 01:19:11 2017, arielgrin@outlook.com wrote: Show quoted text

> Dear Alexander: thank you SO MUCH for your help. I ran the perl script > that you sent me and indeed, in my particular setup, the crt chain is > retrieved in "reverse" way: Root CA first, then Intermediate and > Client CRT at last. > > > If I understood your explanation correctly, your LE script is not > currently checking if the first retrieved certificate is actually the > one for the requested domain, it just returns the first certificate it > receives. Maybe there is a way to tell the script to choose a specific > certificate, in my case that would be the third presented certificate. > > > I'm attaching the output of the script and also the output of perl -V > for my Win2003 Server. > > > Again, thanks so much for your help. Regards, Ariel. >

Mon Apr 17 15:25:14 2017 LEADER [...] cpan.org - Correspondence added

Hi Ariel, Just to let you know - the issue with old libraries not reporting certificate depth as expected should be now fixed in version 0.21 (which went to CPAN today, but yet to be indexed). Later this month there should also be Win32 and Win64 binaries available (ZeroSSL site documentation will be updated accordingly). Best regards, Alexander.

Tue Apr 18 18:12:15 2017 LEADER [...] cpan.org - Correspondence added

Closing as resolved in 0.21. Please let me know if your environment is still experiences the issue (though it should not).

Tue Apr 18 18:12:16 2017 LEADER [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Apr 18 18:12:21 2017 LEADER [...] cpan.org - Fixed in 0.21 added