Bug #705
5.2.0 make-testing build fails due to invalid SSL certificate?
Description
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 001_libtnc.mk
[ ok ] Installing from recipe 002_tnc-fhh.mk
[ ok ] Installing from recipe 003_freeradius.mk
[ ok ] Installing from recipe 004_wpa_supplicant.mk
[ ok ] Installing from recipe 005_anet.mk
[ ok ] Installing from recipe 006_tkm-rpc.mk
[FAIL] Installing from recipe 007_x509-ada.mk
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.
History
#1 Updated by Dan Swartzendruber almost 11 years ago
Did some more digging. It seems like this happens when the build does 'git clone http://git.codelabs.ch/git/x509-ada.git'. It then compiles a bunch of stuff, and ends up calling into cert_tests.adb, which does this:
declare
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);
begin
-- 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?
end;
and the Is_Valid method does:
function Is_Valid (V : Validity_Type) return Boolean
is
use Ada.Calendar;
Now : constant Time := Clock;
begin
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 almost 11 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/007_x509-ada.mk#L17).
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 almost 11 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 almost 11 years ago
Good to go, thanks!
#5 Updated by Tobias Brunner almost 11 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