AcornSSL certificate bug?

Using AcornSSL I have had an unverified certificate prompt raised. While the prompt was not unexpected, I noticed that the validity dates quoted seemed wrong. So I tried to access the same area with two other browsers, and they both showed the same (different) dates, as shown below:

Firefox on Win10 and RISC OS Netsurf v3.9…

Valid from 08 July 2019, 12:21:20 GMT
Valid until 06 October 2019, 12:21:20 GMT

AcornSSL 1.04 (26 Jan 2019) mbedTLS 2.16.2…

Valid from 08 June 2019
Valid until 06 September 2019

Note that the dates shown by AcornSSL are exactly 1 month earlier than the dates I, and the other browsers, believe correct.

Before I report this as a (possible count from zero not one) bug, can anyone else verify my finding please?

Out of interest what version of certificates have you installed on RISC OS as there is a later version put in the Beta hard disc image this week.

Also doesn’t Netsurf have a set of certificates built at the time the version was compiled.

May have nothing to do with your issue but I have also seen certificate issues when the time on the RISC OS machine is incorrect.

My AcornSSL Root certificates are the latest ones dated 28 Aug 2019.
My Netsurf ones are dated 15 May 2019, so slightly older.
I have no idea what the Firefox ones are … but I would assume very recent.

However, the initial certificate I reported was my own from LetsEncrypt. I have now displayed the details from both the higher ones in the chain (LetsEncrypt and DST Root) and they both show dates one month later in Netsurf than in AcornSSL. So it seems to affect all certificate displays in AcornSSL.

And yes, my machine time is correct.

Sounds like an AcornSSL bug then.

I have now reported it as a bug.

[edit to add link for Rick]
https://www.riscosopen.org/tracker/tickets/474

Hmm, three posts and one bug report and no URL…

Edit: I meant the URL of whatever gives the SSL warning. :-)

Using AcornSSL I have had an unverified certificate prompt raised.

What software were you using and what URL was it? It would help tracking the bug down if the maintainer can follow your footsteps.

What software were you using and what URL was it?

Sorry – that will be no help. It was my own test software, connecting to my own NAS which has my Lets Encrypt certificate.

However, it is only AcornSSL itself which reads, checks and displays the invalid certificate wrongly. Neither the target nor my program can influence how the certificate is displayed. Other software displaying the same certificate get the dates right.

For example, if you try https://wrong.host.badssl.com using AcornSSL and anything else, I think you will see that AcornSSL gets the dates wrong by one month..

Interestingly I just tried this with a local server on my network and the dates were correct. Same version of AcornSSL.

Edit: But I just tried a couple of badssl.com ones and I’m getting bizarre results. AcornSSL is reporting both wrong.host.badssl.com and expired.badssl.com as expiring on 8/07/18, but Safari on my Mac lists the expiration dates as 26/03/20 and 13/03/15 respectively.

Safari on my Mac lists the expiration dates as 26/03/20 and 13/03/15 respectively.

Expiry field for the latter reads 13/04/15 in Firefox (Win7)
13 April 2015, 00:59:59
(12 April 2015, 23:59:59 GMT)

Were you typing or doing a cut paste for the text you gave?

Still doesn’t negate the misreading of the certificate date by the SSL module though.
Perhaps the cert file date/time string content is being read slightly displaced from the correct start point?

Ah, yes, looks like I mistyped it. It is indeed 13/04/15.

To try and clarify…

Using AcornSSL I get dates:
wrong.host.badssl.com 18 Feb 2017 to 26 Feb 2020
expired.badssl.com 09 Mar 2015 to 12 Mar 2015

Using Netsurf & Firefox I get
wrong.host.badssl.com 18 Mar 2017 00:00:00 GMT to 25 Mar 2020 12:00:00 GMT
expired.badssl.com 09 Apr 2015 00:00:00 GMT to 12 Apr 2015 23:59:59 GMT

Both from and to dates displayed by AcornSSL seem a month early.

Which I think agrees with what Steve sees, but not Chris?

Interestingly, for my own private certificate here AcornSSL shows an expiry date of yesterday, but does not flag it as invalid – because it actually expires 6/10/2019. So the check is correct, but the display seems wrong.

So the check is correct, but the display seems wrong.

That narrows down the bug location a bit – seemingly in the display element rather than the decrypt and check.

Looks like whoever wrote the display routine forgot the time struct’s tm_mon member range is 0-11 and not 1-12…

There are two major difficulties in software engineering:

1. Off-by-one errors

I like that!

Looks like whoever wrote the display routine forgot the time struct’s tm_mon member range is 0-11 and not 1-12

Somebody copied Java’s braindead Calendar/Time idea of month numbering? That’s a surprise.

Somebody copied Java’s braindead Calendar/Time idea of month numbering?

I think the copier here might be Java…

Frank wrote…

Looks like whoever wrote the display routine forgot the time struct’s tm_mon member range is 0-11 and not 1-12…

And indeed in AcornSSL c.confirmtask at lines 248 to 269 there are
strftime(buf.date.vf, sizeof(buf.date.vf), buf.date.fmt, gmtime(validfrom));
strftime(buf.date.vt, sizeof(buf.date.vt), buf.date.fmt, gmtime(validto));
sprintf(buf.date.msg, "%s %s %s", buf.date.vf, intl_lookup("To"), buf.date.vt);
with buf.date.fmt = %d &b %Y
so if gmtime results in a month of 0-11 and strftime uses 1-12 it would explain the bug.
Seems a stupid inconsistency between the functions to me!

Looks like Sprow pushed the fix a little after your comment.
Amendment to c.timelib

So there’s something to test tomorrow (unless someone wants to pull the amended code and compile ahead of the general download availability)

I have briefly tested AcornSSL v1.05 and it has fixed the problem I saw initially and the badssl website. Many thanks to Sprow for fixing this – and my suggestion above regarding confirmtask seems to have been wrong.

Where does one get AcornSSL 1.05? The Beta Harddisc4.zip contains v1.03 from April.

That’s AcornHTTP. Look in !System.350.Modules.Network.URL for AcornSSL 1.05.

Aren’t AcornSSL/AcornHTTP one and the same thing?

Aren’t AcornSSL/AcornHTTP one and the same thing?

Nope. The former is an HTTPS library which can be used by any app (at least in theory). The latter is an HTTP client.

I’ll start a new thread then, thanks for clarifying.