Bug #705

5.2.0 make-testing build fails due to invalid SSL certificate?

Added by Dan Swartzendruber about 6 years ago. Updated about 6 years ago.

Target version:
Start date:
Due date:
Estimated time:
Affected version:


Host is ubuntu 14.04. I downloaded 5.2.0 tarball, extracted it, tweaked testing/testing.conf for proper build location. Then ran ./make-testing. Fails consistently here:

Installing software from source
[ ok ] Installing from recipe
[ ok ] Installing from recipe
[ ok ] Installing from recipe
[ ok ] Installing from recipe
[ ok ] Installing from recipe
[ ok ] Installing from recipe
[FAIL] Installing from recipe

from logfile:

Running X.509 tests ... please wait
Passed : 8
X.509 tests:
Util tests:
Read files PASS 0.000606000s
PKCS#1 key tests:
Load RSA private keys PASS 0.000601000s
Certificate tests:
Load CA certificate PASS 0.000322000s
Load random certificates PASS 5.962986000s
Load random chunks PASS 12.61080700s
Load random ASN.1 structures PASS 1.753104000s
OID tests:
Convert ASN.1 to OIDs PASS 0.000185000s
Validity tests:
Is_Valid function PASS 0.000350000s

Failed : 1
X.509 tests:
Certificate tests:
Load certificate - Cert not valid FAIL 0.000619000s

make1: * [tests] Error 1
make1: Leaving directory `/root/shared/compile/x509-ada'
make: *
[.x509-ada-built] Error 2

Hopefully this is not something obvious, but the README say nothing about pre-requisite configuration before running the make-testing script, nor about SSL certificates before doing so. Google has not turned up anything helpful.

Associated revisions

Revision 1004d395 (diff)
Added by Reto Buerki about 6 years ago

testing: Update x509-ada version to 0.1.1

Fixes #705.

Revision e0d59e10 (diff)
Added by Reto Buerki about 6 years ago

testing: Update certs and keys in tkm tests

References #705.


#1 Updated by Dan Swartzendruber about 6 years ago

Did some more digging. It seems like this happens when the build does 'git clone'. It then compiles a bunch of stuff, and ends up calling into cert_tests.adb, which does this:

use type Ada.Calendar.Time;
use type Ada.Calendar.Time_Zones.Time_Offset;
V  : constant Validity.Validity_Type := Certs.Get_Validity (Cert);
T1 : Ada.Calendar.Time
:= Ada.Calendar.Time_Of
(Year => 2009,
Month => 8,
Day => 27,
Seconds => 36444.0);
T2 : Ada.Calendar.Time
:= Ada.Calendar.Time_Of
(Year => 2014,
Month => 8,
Day => 26,
Seconds => 36444.0);
--  Add TZ specific time offset to reference times.
T1 := T1 + Duration
(Ada.Calendar.Time_Zones.UTC_Time_Offset (T1) * 60);
T2 := T2 + Duration
(Ada.Calendar.Time_Zones.UTC_Time_Offset (T2) * 60);
Assert (Condition => Validity.Get_Start (V) = T1,
Message => "Validity start mismatch");
Assert (Condition => Validity.Get_End (V) = T2,
Message => "Validity end mismatch");
Assert (Condition => Validity.Is_Valid (V),
Message => "Cert not valid"); <=== this is the failing message?

and the Is_Valid method does:

function Is_Valid (V : Validity_Type) return Boolean
use Ada.Calendar;
Now : constant Time := Clock;
return V.Not_Before <= Now and then Now <= V.Not_After;
end Is_Valid;

So if the clock is not in range for the dates in the cert, we bomb? Looking at the date range above, it looks like if the wall clock is prior to 8/27/2009 or after 8/26/2014, it fails. Today is 9/16/2014, so we fail? I guess I'm puzzled how this is expected to ever work (unless no one has run this build process since 8/26/2014?) A little surprised code like this has a fixed end date that has to be (presumably) updated periodically? What should I be doing here? Running with a make flag to ignore errors? Somehow skipping the cert checking? Something else?

#2 Updated by Tobias Brunner about 6 years ago

  • Category set to testing
  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner
  • Priority changed from High to Normal

I'd just remove the make tests step in the build recipe of that project (see source:testing/scripts/recipes/

I will check with the devs of that project regarding a fix for the unit tests.

Please note that there are certificates used in the test scenarios that have expired recently and have not yet been replaced.

#3 Updated by Tobias Brunner about 6 years ago

The issue has been fixed upstream, the associated commits update the build recipe and the certificates used in the TKM tests.

#4 Updated by Dan Swartzendruber about 6 years ago

Good to go, thanks!

#5 Updated by Tobias Brunner about 6 years ago

  • Tracker changed from Issue to Bug
  • Status changed from Feedback to Closed
  • Target version set to 5.2.1
  • Resolution set to Fixed

Also available in: Atom PDF