greggles created an issue. See original summary.

drumm’s picture

Assigned: Unassigned » basic
drumm’s picture

Status: Active » Postponed (maintainer needs more info)

Rudy has redirecting now. will need to wait for confirmation Drupal 8's supported versions of PHP work well on Windows. See #1538118-16: Update status does not verify the identity or authenticity of the release history URL

basic’s picture

Status: Postponed (maintainer needs more info) » Fixed

http -> https was verified to work on Windows. Deploying shortly.

basic’s picture

There was an issue with the deployment which caused the origin to appear offline. This was mitigated by our configuration which is set to serve the cached update details while the origins are offline.

Now that the root issue has been identified, I will re-enable the redirect over the next 20 minutes (after the hour mark).

basic’s picture

Status: Fixed » Needs review

The redirect has been re-enabled. We will continue testing the purge functionality and verify it successfully purges releases.

basic’s picture

Status: Needs review » Fixed

This appears to be working, including the purging functionality.

sl27257’s picture

Status: Fixed » Needs work


I am sorry that I have to re-open this one!

This is what I get since yesterday. I am using the proxy-facility of getting the update and my proxy is complaining so currently the update doesn't work.

(There is more info, I can send you some more info off-line. I don't what to disclose internal information here.)

Let me know if this should have a separate issue!



EDIT: Updated and obfuscated the info below
--2016-01-13 16:31:28--
Resolving 123.456.789.012
Connecting to|123.456.789.012|:8080... connected.
Proxy request sent, awaiting response... 301 Moved Permanently
--2016-01-13 16:31:29--
Connecting to||:443... connected.
ERROR: cannot verify's certificate, issued by `/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2':
Issued certificate has expired.
ERROR: certificate common name `' doesn't match requested host name `'.
To connect to insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.

dimr’s picture

Hi all,

I had the same error and I found a temporary solution.

I have installed the module cURL HTTP Request, after activate it, Configuration -> Web Services -> cURL HTTP Request and I have activated the checkbox "Override Drupal HTTP Request". After that, it was still not working because the array $fail[$fetch_url_base] was still no empty. To clean it I went to Configuration -> Search and metadata -> Clean URLs

After that, in my case I was able to check the available updates of my project.

Looks like this module don't care about the error
"ERROR: certificate common name `' doesn't match requested host "

David_Rothstein’s picture

There are a number of other people reporting issues with the redirect too - see comments on for details.

Maybe it should be rolled back? To the best of my understanding it doesn't really provide any security - to improve security we'd need core to contact the HTTPS URL directly and to verify the cert (and there are core issues open for both of those here and here, with the first obviously being simpler than the second).

drumm’s picture

We went fully to HTTPS all the time for * with HSTS:

drumm@Neils-MacBook-Pro:~/Downloads$ curl -I
Strict-Transport-Security: max-age=10886400; includeSubDomains; preload

So browsers and anything else that knows the Strict-Transport-Security header will redirect anyway. That might mean we can get away with not redirecting, I don’t think Drupal will know that header.

A problem that happens occasionally is that outdated wget/curl can’t handle our newer certificates. Updating curl may help.

sl27257’s picture


I have tried to figure out what is going on in my installation here.

  1. I can't use the cURL package as the curl PHP module is not installed on my "PaaS" platform here. Maybe the chr.install script in the "cURL HTTP Request" module should check this. Will look into that... #2653528: Check prerequisites for the cURL HTTP Request module
  2. As I pointed out above I am (actually has been, but more on this below) using the proxy facility of the Drupal.
  3. Changing the UPDATE_DEFAULT_URL to "https://" instead of "http://" didn't work for me. The update doesn't work no matter what I use.
  4. As the next step I removed the proxy-definitions in the settings.php file. And then it started working for me! It must be that my proxy nowadays is a transparent proxy as well. I have checked both with the "https://" form and the "http://". Both are working. The conclusion I draw from this is that it is NOT the redirect that is not working but something in the https part of the proxy code that is malfunctioning.
  5. No matter what I do it seems like the using the proxy with "https://" is what is not working. When I force an error message for this combination I get an "Invalid request" error. (I am printing the error message from the returned xml request)

So my conclusion so far is that it is the "https://" part of the proxy-code that is not working. Somehow an "Invalid request" is generated.

I have tried to remove all cache problems, not only in Drupal, but also in the proxy, as I saw that they were causing that the changes I did to the code not were seen immediately.

My two öre...


greggles’s picture

I agree with David Rothstein's points in #10. It seemed like a good idea to redirect everything, but given that updates.d.o is accessed by clients that aren't fully featured http clients (e.g. don't support hsts or redirects consistently) I think we should probably revert the redirect.

I'm hopeful that #1538118: Update status does not verify the identity or authenticity of the release history URL can get fixed soon.

hass’s picture

Will update status modules in D6/D7/D8 get an update to check with ssl first? SNI bases servers may better not used for now...

David_Rothstein’s picture

Title: Redirect and to https version » Redirect and to https version (roll back the part?)
Priority: Normal » Major

Bumping this. We're still seeing reports of problems at, including from people not using a proxy. (Based on links in other issues that could be due to #1879970: drupal_http_request fails when remote server is using openssl v1.0.0 although I am not sure?)

Since the http=>https redirect itself doesn't really provide security, but a site which can't contact at all is definitely a security risk, reverting that part of this (for now) still seems worth considering.

drumm’s picture

We tentatively plan to roll back the updates redirect in the next couple hours.

drumm’s picture

Details on the rollback:

  • HTTPS will still be supported and is preferred.
  • The issue for getting https by default in Drupal is #1879970: drupal_http_request fails when remote server is using openssl v1.0.0. Until that lands, you can work around this with either drush vset update_fetch_url '' or add $conf['update_fetch_url'] = ''; to your settings.php.
  • Browsers and any other clients that support HSTS will still make requests via HTTPS-only.
  • This isn't a reduction in security since Drupal does the initial request over HTTP regardless.
drumm’s picture

Status: Needs work » Fixed

The rollback is now live. The redirects won't be cached in our CDN, Fastly. So if you were having difficulty fetching updates before, this should be immediately cleared up.'s redirects to https remain in place.

David_Rothstein’s picture


The issue for getting https by default in Drupal is #1879970: drupal_http_request fails when remote server is using openssl v1.0.0. Until that lands, you can work around this with either drush vset update_fetch_url '' or add $conf['update_fetch_url'] = ''; to your settings.php.

I think something might have gotten jumbled in the above comment... Just to be clear:

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.