Hide Forgot
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@felipe-alfaro.com 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.
Created attachment 98038 [details] racoon configuration file
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?
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?
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.
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: 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.
This is not something we're going to change outside of upstream; probably bringing it up on the upstream lists is best.