Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 116815

Summary: racoon: certificate checking regresion
Product: [Retired] Red Hat Raw Hide Reporter: Felipe Alfaro Solana <felipe_alfaro>
Component: ipsec-toolsAssignee: Bill Nottingham <notting>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-04 21:57:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
racoon configuration file
none
Backout X.509 mandatory CRL checking none

Description Felipe Alfaro Solana 2004-02-25 14:23:32 UTC 
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[500]<=>192.168.0.100[500] 
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 
SubjectName:/C=ES/ST=Madrid/L=Madrid/O=felipe-alfaro.com/OU=home/CN=teapot.felipe-alfaro.com/emailAddress=yo 
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 
file. 
 
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): 
0.2.4-1 
 
How reproducible: 
Always 
 
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. 
   
Actual results: 
racoon keeps trying to check a certificate against a CRL, even when 
I haven't defined any mean of getting that CRL. 
 
Expected results: 
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. 
 
Additional info: 
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.
Comment 1 Felipe Alfaro Solana 2004-02-25 14:24:44 UTC 
Created attachment 98038 [details]
racoon configuration file
Comment 2 Bill Nottingham 2004-02-25 19:26:22 UTC 
diff -ru ipsec-tools-0.2.2/src/racoon/crypto_openssl.c
ipsec-tools-0.2.4/src/racoon/crypto_openssl.c
--- ipsec-tools-0.2.2/src/racoon/crypto_openssl.c       2003-03-03
18:56:56.000000000 -0500
+++ ipsec-tools-0.2.4/src/racoon/crypto_openssl.c       2004-01-19
12:45:41.000000000 -0500
@@ -272,6 +279,10 @@
        if (csc == NULL)
                goto end;
        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);
+#endif
        error = X509_verify_cert(csc);
        X509_STORE_CTX_cleanup(csc);
 #else


I'm assuming if you back those bits out, it starts working?
Comment 3 Felipe Alfaro Solana 2004-02-26 12:12:56 UTC 
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 
fixed upstream?
Comment 4 Felipe Alfaro Solana 2004-02-26 12:14:42 UTC 
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
version 0.2.2.
Comment 5 Joe Orton 2004-02-26 16:57:21 UTC 
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).
Comment 6 Joe Orton 2004-02-26 17:06:52 UTC 
Instead of removing the _flags calls, does adding:

case X509_V_ERR_UNABLE_TO_GET_CRL:

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.
Comment 7 Bill Nottingham 2005-02-04 21:57:57 UTC 
This is not something we're going to change outside of upstream;
probably bringing it up on the upstream lists is best.