278043 - "Error reading URL" when using RSS Feed and SharpReader

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task, P1)

Description

[csalsa]

I get the error below when I try to load the RSS Feed at the URL: 

https://addons.update.mozilla.org/rss/?application=firefox&type=E&list=newest

into SharpReader (http://www.sharpreader.com).

"Error reading URL: The underlying connection was closed: Could not establish
trust relationship with remote server. 
Please try to validate this feed. If this feed validates as correct RSS, you can
send an error report."

I tried validating the feed given the link in the error message.  The link was
to the URL:

http://feedvalidator.org

I get a simular error message using the validation service at this site.

Comment 1

[alanjstr]

Visiting the page in Firefox, I get the broken lock icon.  I believe this is a
known problem.

Comment 2

[Anne (:annevk)]

Maybe they can not handle HTTPS URIs?

Comment 3

[Dave Miller [:justdave]]

Tried it in NetNewsWire and get the following error:

2005-01-12 14:53:57 -0500: Download Error: Domain: SSL Type: Invalid certificate
chain URL:
https://addons.update.mozilla.org/rss/?application=firefox&type=E&list=newest

It's probably because of the screwy multi-domain certificate we have on there.

Comment 4

[Dave Miller [:justdave]]

Feed Validator doesn't handle https URLs.  It tries to tack an http: in front if
you don't give it one, which includes putting it in front of the https: you
already had there.

The broken lock in Firefox appears to be because of the default local XSL sheet.
(bug in Firefox?).  Clicking it shows the identify verified and offers no reason
for the lock to be broken in the security window.

NetNewsWire appears to just be broken when dealing with https sites (I tried a
few other https sites with feeds and got similar errors).

openssl s_client -connect addons.update.mozilla.org:443 \
        -CAfile /usr/share/ssl/certs/ca-bundle.crt

reports the following:

CONNECTED(00000003)
depth=3 /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
verify return:1
depth=2 /CN=GlobalSign RootSign Partners CA/OU=RootSign Partners CA/O=GlobalSign
nv-sa/C=BE
verify return:1
depth=1 /C=US/ST=Texas/L=San Antonio/OU=GS CA/O=XRamp Security Services
Inc/CN=XRamp Security Services GS CA
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Mozilla
Foundation/OU=*.mozilla.org/CN=*.mozilla.org/emailAddress=[e-mail]
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Mozilla
Foundation/OU=*.mozilla.org/CN=*.mozilla.org/emailAddress=[e-mail]
   i:/C=US/ST=Texas/L=San Antonio/OU=GS CA/O=XRamp Security Services
Inc/CN=XRamp Security Services GS CA
 1 s:/C=US/ST=Texas/L=San Antonio/OU=GS CA/O=XRamp Security Services
Inc/CN=XRamp Security Services GS CA
   i:/CN=GlobalSign RootSign Partners CA/OU=RootSign Partners CA/O=GlobalSign
nv-sa/C=BE
 2 s:/CN=GlobalSign RootSign Partners CA/OU=RootSign Partners CA/O=GlobalSign
nv-sa/C=BE
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
 3 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
(...)
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 4CF28DE69250BA5D4BC6BEC94930832AFDDEB034E1EDCBA1152A8FAC454F843B
    Session-ID-ctx: 
    Master-Key:
C0A74C7E00592780C647D2A9EB10BFCD3F7568EC6DA0012C021464E7AC8080D297B5C8ED9522DD3E4F419ED83C300EED
    Key-Arg   : None
    Start Time: 1111874610
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

That "Verify return code: 0 (ok)" at the bottom is all I need to see to know
this is not a server issue with the certificate.

If there's something broken here, it's with the individual client apps that
can't get to it.

Comment 5

[Dave Miller [:justdave]]

OK, did some more experimenting...  NetNewsWire's problem appears to be the
four-part domain name.  I saved the RDF file to disk and dropped a copy of it on
the bugzilla server and then pasted that URL into NetNewsWire and it likes it
(even though it's https with the same style of cert).

Now that we have the update redirector on a separate box and no longer part of
the squid/addons cluster, this is trivial to fix.  People coming from 1.0
clients who need the *.update.mozilla.org to get their stuff will be hitting
update.mozilla.org first and can be redirected directly to
addons.update.mozilla.org.  addons.mozilla.org can stop redirecting there, and
people who come in from 1.0.1 and up with get the right place.  People who
complain about the RSS feed URL not working when they paste it from FF 1.0 can
be told to upgrade ;)

Comment 6

[Dave Miller [:justdave]]

OK, this is fixed, if you use the links provided on https://addons.mozilla.org/

The redirects have been rearranged, and I've confirmed that both Safari and
NetNewsWire both like the cert now.

Comment 7

[csalsa]

Thanks for the fix.

I just confirmed that it worked with SharpReader.  No more problems.  ;-)