bugSavannah Static web pages of project:

bugbugs #12182: -->edg-fetch-crl (wget) sometimes fails to download CRL via HTTPS

Submitted by:  Romain Wartel <rwartel>
Submitted on:  2005-10-13 10:24
Category:  Security Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Malfunctioning
Status:  Fixed Privacy:  Public
Assigned to:  ineilson Open/Closed:  Closed
Discussion Lock:  Unlocked Release:  None
Reproducibility:  Intermittent Effort: 0.00
Summary:  *edg-fetch-crl (wget) sometimes fails to download CRL via HTTPS
* Mandatory Fields

(Jump to the original submission Jump to the original submission)

2005-11-15 09:04, comment #6:

Small comment for the updated packages:

In the LCG repository, edg-utils-system-1.8.1 fixes the current bug.

In the EUGridPMA repository, fetch-crl-2.3-1.noarch.rpm fixes the current bug.

Romain Wartel <rwartel>

2005-11-14 21:57, comment #5:


this bug is closed now but you don't tell where/which package version etc. 8-P

It is a REALLY upsetting bug for installs from scratch, because the configure_nodes script blocks there for ages.
I suggest that you put a reasonable timeout in edg-fetch-crl, currently
# Time out is 30 minutes by default.
or force Yaim's config_crl to background all the crl updates instead of waiting on it.
You could also have a short (~5 secs, for the installation case) and a long timeout (whatever, for running from cronjob)

Thanks, Ariel

Ariel Garcia <ariel>

2005-10-21 10:44, comment #4:

The cause of all of this seems to be an SL upgrade from wget 1.9 to 1.10:

wget-1.9.1-16.EL3.1.i386.rpm 05/19/05
wget-1.10.1-1.30E.1.i386.rpm 10/18/05

New wget now has SSL checks enabled by default:

    • SSL/TLS changes:
      • SSL/TLS downloads now attempt to verify the server's certificate

against the recognized certificate authorities. This requires CA
certificates to have been installed in a location visible to the
OpenSSL library. If this is not the case, you can get the bundle
yourself from a source you trust (for example, the bundle extracted
from Mozilla available at http://curl.haxx.se/docs/caextract....),
and point Wget to the PEM file using the `--ca-certificate'
command-line option or the corresponding `.wgetrc' command.

      • Secure downloads now verify that the host name in the URL matches

the "common name" in the certificate presented by the server.

      • Although the above checks provide more secure downloads, they

unavoidably break interoperability with some sites that worked with
previous versions, particularly those using self-signed, expired, or
otherwise invalid certificates. If you encounter "certificate
verification" errors or complaints that "common name doesn't match
requested host name" and are convinced of the site's authenticity, you
can use `--no-check-certificate' to bypass both checks.

I suggest we avoid the check alltogether with `--no-check-certificate` to avoid future problems with dowloading from sites that use wierd certificates (either not signed by one of grid CAs or with a strange/nonmatching CN/hostname or expired cert...)

We can also try downloading first with wget and if that fails try lynx.

Valentin Vidic <vvidic>

2005-10-19 10:01, comment #3:

comment #1 Valentin's solution is neat. I think we should use it.

Romain Wartel <rwartel>

2005-10-13 11:02, comment #2:

I'm not sure using ssl gives us much anyway since the downloaded crl must be signed by one of the certificates we have to say we trust anyway. So we should could use --no-check-certificate as offered in the error message.

Ian Neilson <ineilson>
2005-10-13 10:47, comment #1:

# wget 'https://swisssign.net/cgi-bin/autho...'
--12:42:26-- https://swisssign.net/cgi-bin/autho...
=> `crl?into=file&ca=SWITCH.1'
Resolving swisssign.net...
Connecting to swisssign.net||:443... connected.
ERROR: Certificate verification error for swisssign.net: self signed certificate in certificate chain
To connect to swisssign.net insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.

# wget --ca-directory=/etc/grid-security/certificates/ 'https://swisssign.net/cgi-bin/autho...'
--12:42:49-- https://swisssign.net/cgi-bin/autho...
=> `crl?into=file&ca=SWITCH.1'
Resolving swisssign.net...
Connecting to swisssign.net||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 518 [application/unknown]

100%[===========================================================================================================================>] 518 --.--K/s

12:42:49 (49.40 MB/s) - `crl?into=file&ca=SWITCH.1' saved [518/518]

So you can also use:
${wget} -q -t 3 -T 30 --ca-directory ${outputDirectory} -O ${destinationFile} ${url}

Valentin Vidic <vvidic>

2005-10-13 10:24, original submission:

In some situations, a certain number of CRLs are not downloaded with the edg-fetch-crl tool. This could enable an attacker using an expired/revoked certificate to obtain credentials on the vulnerables nodes. The problem seems to be linked to the wget program.

The sft-crl tool reports that many sites failed to download some CRLs. At the time of writting, at least 99 sites on 173 are vulnerable.

The list of failed download changes, but it generally includes:

The following have to be noted:

1] The CRL downloads have already been succesful, and seems to work from time to time. But the CRL timestamps reveal they failed at THE SAME TIME:

# date
Thu Oct 13 12:06:26 CEST 2005
# find /etc/grid-security/certificates/*.r0 -ctime +1 -exec ls -l {} \;
-rw-r--r-- 1 root root 6846 Oct 5 02:25 /etc/grid-security/certificates/03aa0ecb.r0
-rw-r--r-- 1 root root 2209 Oct 5 02:25 /etc/grid-security/certificates/7b2d086c.r0
-rw-r--r-- 1 root root 2741 Oct 5 02:25 /etc/grid-security/certificates/ba2f39ca.r0
-rw-r--r-- 1 root root 2273 Oct 5 02:25 /etc/grid-security/certificates/e36e7a72.r0
-rw-r--r-- 1 root root 2273 Oct 5 02:25 /etc/grid-security/certificates/e9d08b40.r0

2] It seems that only CRLs downloaded via HTTPS fails:

#cat /etc/grid-security/certificates/*.crl_url |grep https

The problem occurs when using the wget program. It is solved by using lynx instead of wget in the fetch-crl script.

WORKAROUND: In the edg-fetch-crl, disable wget and use lynx.

--- /opt/edg/sbin/edg-fetch-crl.bad 2005-10-13 12:19:40.000000000 +0200
+++ /opt/edg/sbin/edg-fetch-crl 2005-10-13 12:14:09.000000000 +0200
@@ -97,9 +97,9 @@
# If you don't have 'wget' installed on your machine or you prefer use 'lynx' instead,
# uncomment next line and comment the following one.
- # ${lynx} -source ${url} > ${destinationFile}
+ ${lynx} -source ${url} > ${destinationFile}
- ${wget} -q -t 3 -T 30 -O ${destinationFile} ${url}
+ #${wget} -q -t 3 -T 30 -O ${destinationFile} ${url}
return $?


Romain Wartel <rwartel>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • Ariel Garcia <ariel> added by (ariel) (Posted a comment)
  • Ian Neilson <ineilson> added by (ineilson) (Posted a comment)
  • Valentin Vidic <vvidic> added by (vvidic) (Posted a comment)
  • steves.traylen@rl.ac.uk added by (rwartel)
  • Deletedavidg@nikhef.nl added by rwartel
  • Delete added by (Romain Wartel <rwartel>) added by rwartel (Submitted the item)

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    2005-11-04 11:26rwartelStatusNone=>Fixed
    2005-10-13 10:24rwartelAssigned to-Automatic update due to transitions settings-=>ineilson
      Carbon-Copy-=>Added steves.traylen@rl.ac.uk
      Carbon-Copy-=>Added davidg@nikhef.nl
    Show feedback again

    Back to the top