Infrastructure
  1. Infrastructure
  2. INFRA-5450

https://www.openoffice.org is using an invalid certificate

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Later
    • Fix Version/s: Initial Clearing
    • Component/s: Website
    • Labels:
      None

      Description

      Some of our users prefer to access the OpenOffice website via HTTPS instead of HTTP:
      https://www.openoffice.org

      But doing so they encounter a certificate mismatch error, since the certificate only covers the apache.org domain.

      We nowhere advertise the HTTPS link, so the solution can be either to remove HTTPS altogether or to provide a proper certificate covering *.openoffice.org.

        Activity

        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> or (3) direct them to https://ooo-site.apache.org/. Or (4) tell them to look at the certificate error, confirm that it's only a CN mismatch (ie, root cert is OK, expiry date is OK, etc), and have their browser trust the presented cert anyway. (No idea how easily we can have the cert re-issued, and at any rate even if possible it'll take some time.)
        Show
        #asfinfra IRC Bot added a comment - <danielsh> or (3) direct them to https://ooo-site.apache.org/ . Or (4) tell them to look at the certificate error, confirm that it's only a CN mismatch (ie, root cert is OK, expiry date is OK, etc), and have their browser trust the presented cert anyway. (No idea how easily we can have the cert re-issued, and at any rate even if possible it'll take some time.)
        Hide
        Tony Stevenson added a comment -
        We cant get a wildcard that covers more than one namespace (they just do not supply them, while they may well be technically possible).

        Andrea if you want such an SSL cert we will need a formal request for one, we wont be purchasing a wildcard (too expensive, and I suspect our supplier wont give us yet another wildcard) so we will need to know exactly which names you want to support. The issue we are going to have is supporting yet another SSL vhost on another IP address/port combo. We currently run all sites on the same IP/Port as they all use the same namespace.

        To be honest we only tend to support the official $tlp.apache.org namespace, all other vanity domains are typically redirected to the tlp site. However, we cannot redirect a site on SSL to another site, if the SSL cert is still incorrect as the browser will still throw a hissy fit before the redirect.

        At the moment, I'd say you should be trying to use the $tlp.a.o site - and we can consider redirecting www.o.o to this at some point.
        Show
        Tony Stevenson added a comment - We cant get a wildcard that covers more than one namespace (they just do not supply them, while they may well be technically possible). Andrea if you want such an SSL cert we will need a formal request for one, we wont be purchasing a wildcard (too expensive, and I suspect our supplier wont give us yet another wildcard) so we will need to know exactly which names you want to support. The issue we are going to have is supporting yet another SSL vhost on another IP address/port combo. We currently run all sites on the same IP/Port as they all use the same namespace. To be honest we only tend to support the official $tlp.apache.org namespace, all other vanity domains are typically redirected to the tlp site. However, we cannot redirect a site on SSL to another site, if the SSL cert is still incorrect as the browser will still throw a hissy fit before the redirect. At the moment, I'd say you should be trying to use the $tlp.a.o site - and we can consider redirecting www.o.o to this at some point.
        Hide
        Rob Weir added a comment -
        More info from user. He is using a browser plugin called "HTTPS-Everywhere" that the EFF promotes: https://www.eff.org/https-everywhere

        Per this FAQ it looks like we can report this to them and ask them to not force openoffice.org to use https: https://www.eff.org/https-everywhere/faq

        Would another option be to redirect https to http for openoffice.org? Or would that get us into a circular loop with HTTPS-Everywhere?
        Show
        Rob Weir added a comment - More info from user. He is using a browser plugin called "HTTPS-Everywhere" that the EFF promotes: https://www.eff.org/https-everywhere Per this FAQ it looks like we can report this to them and ask them to not force openoffice.org to use https: https://www.eff.org/https-everywhere/faq Would another option be to redirect https to http for openoffice.org? Or would that get us into a circular loop with HTTPS-Everywhere?
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> Redirect won't work, as the SSL handshake precedes the first opportunity to send a redirect.
        Show
        #asfinfra IRC Bot added a comment - <danielsh> Redirect won't work, as the SSL handshake precedes the first opportunity to send a redirect.
        Hide
        Andrea Pescetti added a comment -
        One affected user made extensive debugging in these two messages:

        http://mail-archives.apache.org/mod_mbox/incubator-ooo-users/201210.mbox/%3Ck6ca7m%2450h%241%40ger.gmane.org%3E

        http://mail-archives.apache.org/mod_mbox/incubator-ooo-users/201211.mbox/%3Ck6v4o9%243no%241%40ger.gmane.org%3E

        Is there any feasible solution to suppress the warning? Even if the solution is simply to switch off https://www.openoffice.org but keeping https://ooo-site.apache.org/ working as it is now, this could work (we might then want to simply include a "HTTPS version" link in the site footer).
        Show
        Andrea Pescetti added a comment - One affected user made extensive debugging in these two messages: http://mail-archives.apache.org/mod_mbox/incubator-ooo-users/201210.mbox/%3Ck6ca7m%2450h%241%40ger.gmane.org%3E http://mail-archives.apache.org/mod_mbox/incubator-ooo-users/201211.mbox/%3Ck6v4o9%243no%241%40ger.gmane.org%3E Is there any feasible solution to suppress the warning? Even if the solution is simply to switch off https://www.openoffice.org but keeping https://ooo-site.apache.org/ working as it is now, this could work (we might then want to simply include a "HTTPS version" link in the site footer).
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> If we want to fix this I suspect resolving to a secondary IP with port 443 closed would be easiest... but I'm not sure we want to fix this. Is it really a problem if people who _manually_ type "https" in the address bar get a certificate which is valid, but for a different (and related) domain name?
        Show
        #asfinfra IRC Bot added a comment - <danielsh> If we want to fix this I suspect resolving to a secondary IP with port 443 closed would be easiest... but I'm not sure we want to fix this. Is it really a problem if people who _manually_ type "https" in the address bar get a certificate which is valid, but for a different (and related) domain name?
        Hide
        Andrea Pescetti added a comment -
        Yes, it is a problem since they are not doing it manually but EFF's popular "HTTPS Everywhere" browser add-on is doing that for them, and they often install this add-on to have better security and privacy and without really understanding how HTTPS works. So every warning seems like a security breach to some of them...
        Show
        Andrea Pescetti added a comment - Yes, it is a problem since they are not doing it manually but EFF's popular "HTTPS Everywhere" browser add-on is doing that for them, and they often install this add-on to have better security and privacy and without really understanding how HTTPS works. So every warning seems like a security breach to some of them...
        Hide
        David Fisher added a comment - - edited
        Perhaps adding the following as the last rule in the virtual host for openoffice.org in zzzothers.conf:

        RewriteCond %{HTTPS} on
        RewriteRule ^(.*)$ http://%{SERVER_NAME}%{REQUEST_URI} [R=301]
        Show
        David Fisher added a comment - - edited Perhaps adding the following as the last rule in the virtual host for openoffice.org in zzzothers.conf: RewriteCond %{HTTPS} on RewriteRule ^(.*)$ http://% {SERVER_NAME}%{REQUEST_URI} [R=301]
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> Non-starter; SSL negotiation occurs before the client request verb and URI are sent. I did consider adding :80 to ServerName but that should just cause httpd to serve some other vhost on www.oo.o:443 ...
        Show
        #asfinfra IRC Bot added a comment - <danielsh> Non-starter; SSL negotiation occurs before the client request verb and URI are sent. I did consider adding :80 to ServerName but that should just cause httpd to serve some other vhost on www.oo.o:443 ...
        Hide
        David Fisher added a comment -
        I see and limiting to having two virtual hosts: one for 80 and 443 doesn't help either. I've configured apache with multiple certificates at work. To make this work nicely for IE7 and less would require that *.openoffice.org be first in the server's ssl stack. - A non-starter.

        In order to satisfy this small inconvenience would require two actions from Apache:

        (1) A *.openoffice.org ssl certificate. This requires budget.
        (2) Separating openoffice.org web hosting from the rest of apache hosting. This adds complexity for Apache Infrastructure.
        Show
        David Fisher added a comment - I see and limiting to having two virtual hosts: one for 80 and 443 doesn't help either. I've configured apache with multiple certificates at work. To make this work nicely for IE7 and less would require that *.openoffice.org be first in the server's ssl stack. - A non-starter. In order to satisfy this small inconvenience would require two actions from Apache: (1) A *.openoffice.org ssl certificate. This requires budget. (2) Separating openoffice.org web hosting from the rest of apache hosting. This adds complexity for Apache Infrastructure.
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> Another option would be to obtain a www.oo.o certificate and serve it on the existing IP address to clients that support SNI - but that means the status quo's error will remain for other clients.
        Show
        #asfinfra IRC Bot added a comment - <danielsh> Another option would be to obtain a www.oo.o certificate and serve it on the existing IP address to clients that support SNI - but that means the status quo's error will remain for other clients.
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> Dave, step back a second. Did you say "*.oo.o" certificate? ie, a wildcard certificate, as opposed to one for www.oo.o ? Let's be clear on what you guys are seeking.
        Show
        #asfinfra IRC Bot added a comment - <danielsh> Dave, step back a second. Did you say "*.oo.o" certificate? ie, a wildcard certificate, as opposed to one for www.oo.o ? Let's be clear on what you guys are seeking.
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> BTW, openoffice.org is about 40% of our web traffic, and I think that figure excludes the endless stream of PROPFIND requests to the old update URLs. So --- there might well be a resources issue if all that traffic (GET + PROPFIND) were https'd.
        Show
        #asfinfra IRC Bot added a comment - <danielsh> BTW, openoffice.org is about 40% of our web traffic, and I think that figure excludes the endless stream of PROPFIND requests to the old update URLs. So --- there might well be a resources issue if all that traffic (GET + PROPFIND) were https'd.
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> Ping, please answer the question, did you expect a wildcart? are you aware tha a wildcard certificate for *.oo.o will _not_ be considered to match hostnames *.*.oo.o ?
        Show
        #asfinfra IRC Bot added a comment - <danielsh> Ping, please answer the question, did you expect a wildcart? are you aware tha a wildcard certificate for *.oo.o will _not_ be considered to match hostnames *.*.oo.o ?
        Hide
        David Fisher added a comment -
        Let me get clarity from the project on this. I am aware of the *. vs. *.*. limitation.

        Thanks
        Show
        David Fisher added a comment - Let me get clarity from the project on this. I am aware of the *. vs. *.*. limitation. Thanks
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> OK
        Show
        #asfinfra IRC Bot added a comment - <danielsh> OK
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> Shuffling this out of the outstanding issues queue --- please reopen once you're ready to proceed.
        Show
        #asfinfra IRC Bot added a comment - <danielsh> Shuffling this out of the outstanding issues queue --- please reopen once you're ready to proceed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Andrea Pescetti
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development