Description of problem:
I have been playing with secure IPv4 IPSec transport links with
racoon and X.509 certificates. With ipsec-tools-0.2.2-8, racoon was
able to check that the certificate presented by a peer was valid
(that is, signed by a known CA, etc.).
However, starting with ipsec-tools-0.2.4-1, racoon now fails at the
certificate check when running in the same environment, while trying
to check the same X.509 certificate presented by the same peer with
the following error messages:
2004-02-25 15:04:15: INFO: isakmp.c:891:isakmp_ph1begin_r(): respond
new phase 1 negotiation: 192.168.0.2<=>192.168.0.100
2004-02-25 15:04:15: INFO: isakmp.c:896:isakmp_ph1begin_r(): begin
Identity Protection mode.
2004-02-25 15:04:15: INFO: vendorid.c:128:check_vendorid(): received
Vendor ID: KAME/racoon
2004-02-25 15:04:15: ERROR: crypto_openssl.c:348:cb_check_cert():
unable to get certificate CRL(3) at depth:0
2004-02-25 15:04:15: ERROR: oakley.c:1335:oakley_validate_auth():
the peer's certificate is not verified.
This behavior is new of ipsec-tools 0.2.4 and I've been unable to
see any change related to Certificate Revocation Lists in the
changelog or documentation. It seems, by looking at the error
messages, that racoon is trying to check a CRL to see if the X.509
certificate presented by the peer is still valid. However, no means
of getting that CRL have been provided in the racoon configuration
I have placed the CA X.509 certificate under /etc/racoon/certs and
its corresponding symbolic link (ln -s cacert.pem `openssl -noout
-hash < cacert.pem`.0). Also, the certificate and private keys are
also installed in /etc/racoon/certs. I must insist that this worked
flawlessly with ipsec-tools 0.2.2.
The only way to stop this behavior and keep the IPSec transport mode
working is by setting "verify_cert" to "off" in racoon configuration
file. In previous versions of racoon this was NOT needed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Upgrading to ipsec-tools-0.2.4-1 triggers this new behavior and
makes racoon stop working for me, since it tries to check X.509
certificates against an inexistent CRL.
racoon keeps trying to check a certificate against a CRL, even when
I haven't defined any mean of getting that CRL.
I think racoon should behave like previos versions did. Maybe the
new behavior is more appropiate, accurate or secure, but changing
this behavior without properly stating in the release notes will
create interoperability problems for administrators that are
upgrading from version 0.2.2 to 0.2.4.
I have attached "racoon.conf" configuration file for further review.
The machines involved in the transport mode IPSec SA are running
2.6.3-bk6 and 2.6.3-mm3 kernels, respectively.
Created attachment 98038 [details]
racoon configuration file
diff -ru ipsec-tools-0.2.2/src/racoon/crypto_openssl.c
--- ipsec-tools-0.2.2/src/racoon/crypto_openssl.c 2003-03-03
+++ ipsec-tools-0.2.4/src/racoon/crypto_openssl.c 2004-01-19
@@ -272,6 +279,10 @@
if (csc == NULL)
X509_STORE_CTX_init(csc, cert_ctx, x509, NULL);
+#if OPENSSL_VERSION_NUMBER >= 0x00907000L
+ X509_STORE_CTX_set_flags (csc, X509_V_FLAG_CRL_CHECK);
+ X509_STORE_CTX_set_flags (csc, X509_V_FLAG_CRL_CHECK_ALL);
error = X509_verify_cert(csc);
I'm assuming if you back those bits out, it starts working?
Yep! You are totally right...
I have created a backout patch from the one you've produced and the
modified the spec file for ipsec-tools-0.2.4-1 to include it. The
backout patch is attached next as ipsec-tools-0.2.4-x509.patch.
What should I expect from this? Will this patch get included in next
iterations of ipsec-tools or will this regression in behavior get
Created attachment 98067 [details]
Backout X.509 mandatory CRL checking
This patch will revert ipsec-tools-0.2.4 racoon X.509 CRL behavior as it was in
It looks like the OpenSSL logic is as follows:
When the X509_V_FLAG_CRL_CHECK flag is set X509_verify_cert will
attempt to do CRL verification; it will use the lookup functions which
Racoon supplies to find CRLs (pointing at the configured
file/directory containing CAs&CRLs).
If a CRL cannot be found for a particular cert, it will call the
cb_check_cert() callback in Racoon, which can then choose to ignore
that error if it wishes, and hence, not care if certs are used for
which no CRLs have been configured.
(There's a memory leak in eay_get_x509subjectaltname to boot,
GENERAL_NAMES_free(gens) is missing).
Instead of removing the _flags calls, does adding:
at the beginning of the switch (ctx->error) in cb_check_cert also fix
the problem? It would still leave noisy warning messages and
unnecessary processing, really I'd expect CRL processing to be a
separate config option in racoon.
This is not something we're going to change outside of upstream;
probably bringing it up on the upstream lists is best.