On 19.01.2012 07:14, Kaspar Brand wrote:
On 19.01.2012 03:28, Rainer Jung wrote:
OpenSSL should be 1.0.0f and the strange thing is, that the same tests
succeed on Solaris 10 using the same OpenSSL version. Something must be
different between my Linux systems, which all fail, and the Solaris box.
Could be details of the perl modules required by the test framework,
could be that the system OpenSSL on Linux interferes.
Anyone has an idea, why those CRL checks could fail?
Yes, most likely OpenSSL< 1.0.0 appeared in your $PATH when you created
the config for the test framework, while httpd is now running with
OpenSSL 1.0.0 (grepping for "OpenSSL" in t/logs/error_log should confirm
this).
Yes, thanks, that was it. Prefixing path during test run with the custom
build recent OpenSSL fixed it.
The root cause is that OpenSSL has changed its issuer hash algorithm
between these two versions, so if you create the test config with
OpenSSL 0.9.8, you will have the following crl directory:
$ ls -l t/conf/ssl/ca/asf/crl
total 4
lrwxr-xr-x 1 kbrand kbrand 13 Jan 18 18:01 9d0c6ffe.r0 -> ca-bundle.crl
-rw-r--r-- 1 kbrand kbrand 552 Jan 18 18:01 ca-bundle.crl
OpenSSL 1.0.0 and later will look for an "fdd35eee.r0" CRL file, however.
To work around this, execute "ln -s ca-bundle.crl fdd35eee.r0" in that
directory.
ACK. Thanks!
Additional info: even on the failing systems, CRL checks done for other
tests in the suite do succeed. Example:
[Thu Jan 19 02:33:50.878506 2012] [ssl:debug] [pid 5240]
ssl_engine_kernel.c(1436): [client 127.0.0.1:62803] AH02275: Certificate
Verification, depth 1, CRL checking mode: chain [subject:
emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San
Francisco,ST=California,C=US / issuer:
emailAddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San
Francisco,ST=California,C=US / serial: C4C8AB4BFBA4FCA8 / notbefore: Jan
19 01:28:00 2012 GMT / notafter: Jan 18 01:28:00 2013 GMT]
I think you're misinterpreting this message - here, "CRL checking mode"
only states what kind of checking is set... whether it passes or fails
can only be seen from the succeeding message (either there isn't any,
or you will see "Certificate Verification: Error (3): unable to get
certificate CRL" and the like).
I had checked that. No other errors were following the cited line.
Thanks for shedding some light on this!
Rainer
