Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #234166 > unrolled thread

Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

Back to article view | Back to linux.debian.user

Contents

  Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Celejar <celejar@gmail.com> - 2021-04-14 18:20 +0200
    Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections riveravaldez <riveravaldezmail@gmail.com> - 2021-04-14 21:10 +0200
      Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Nito <nito@dismail.de> - 2021-04-15 02:40 +0200
      Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Celejar <celejar@gmail.com> - 2021-04-15 04:30 +0200
    Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections piorunz <piorunz@gmx.com> - 2021-04-15 00:00 +0200
      Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Celejar <celejar@gmail.com> - 2021-04-15 04:20 +0200
        Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections Kenneth Parker <sea7kenp@gmail.com> - 2021-04-15 05:00 +0200
          Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-04-15 06:00 +0200
            Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections Kenneth Parker <sea7kenp@gmail.com> - 2021-04-15 07:20 +0200
              Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Dan Ritter <dsr@randomstring.org> - 2021-04-15 15:40 +0200
                Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections Kenneth Parker <sea7kenp@gmail.com> - 2021-04-15 16:40 +0200
                Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Richard Hector <richard@walnut.gen.nz> - 2021-04-16 03:10 +0200
                  Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Tixy <tixy@yxit.co.uk> - 2021-04-16 10:40 +0200
                Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Jonathan Dowland <jon+debian-user@dow.land> - 2021-04-16 12:40 +0200
        Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections piorunz <piorunz@gmx.com> - 2021-04-15 12:20 +0200
          Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Darac Marjal <mailinglist@darac.org.uk> - 2021-04-15 12:50 +0200
            Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Jonathan Dowland <jon+debian-user@dow.land> - 2021-04-15 14:40 +0200
              Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Jonathan Dowland <jon+debian-user@dow.land> - 2021-04-15 14:40 +0200
          Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Greg Wooledge <greg@wooledge.org> - 2021-04-15 13:30 +0200
          Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Celejar <celejar@gmail.com> - 2021-04-15 14:20 +0200
            Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2021-04-15 14:40 +0200
              Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Celejar <celejar@gmail.com> - 2021-04-15 17:20 +0200
            Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections mett <mett@pmars.jp> - 2021-04-15 14:50 +0200
              Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections piorunz <piorunz@gmx.com> - 2021-04-15 16:20 +0200
                Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Erwan David <erwan@rail.eu.org> - 2021-04-15 16:50 +0200
                  Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections piorunz <piorunz@gmx.com> - 2021-04-15 17:50 +0200
                    Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS  connections Jonathan Dowland <jon+debian-user@dow.land> - 2021-04-16 13:30 +0200

Page 1 of 2  [1] 2  Next page →

#234166 — Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

Hi,

I recently switched to Firefox's native HTTPS-Only mode from the
HTTPS Everywhere extension, and I've just made the nasty discovery that
a bunch of links that had been returning 404, which I had been assuming
were dead links, were actually perfectly valid pages, which Firefox had
been "upgrading" to HTTPS, and then getting 404s from web servers that
weren't offering them via HTTPS (but still apparently accepting
connections via HTTPS). Clicking on the little lock icon and turning
HTTPS-Only mode off for the website doesn't seem to have any effect -
the only thing that lets me actually access these pages is turning off
HTTPS-Only mode via the general Settings page (or about:config).

When the website doesn't offer HTTPS at all, then Firefox offers to
connect via HTTP, after a warning, and that's fine. But having pages
become completely inaccessible is intolerable - I now have to check
every 404 I get by turning off HTTPS-Only mode and seeing if the
page is actually there. Am I missing something here, or is HTTPS-Only
mode just badly broken?

https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/
https://news.ycombinator.com/item?id=25121604

Celejar

[toc] | [next] | [standalone]

#234174 — Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

On 4/14/21, Celejar <celejar@gmail.com> wrote:
> Hi,
>
> I recently switched to Firefox's native HTTPS-Only mode from the
> HTTPS Everywhere extension, and I've just made the nasty discovery that
> a bunch of links that had been returning 404, which I had been assuming
> were dead links, were actually perfectly valid pages, which Firefox had
> been "upgrading" to HTTPS, and then getting 404s from web servers that
> weren't offering them via HTTPS (but still apparently accepting
> connections via HTTPS). Clicking on the little lock icon and turning
> HTTPS-Only mode off for the website doesn't seem to have any effect -
> the only thing that lets me actually access these pages is turning off
> HTTPS-Only mode via the general Settings page (or about:config).
>
> When the website doesn't offer HTTPS at all, then Firefox offers to
> connect via HTTP, after a warning, and that's fine. But having pages
> become completely inaccessible is intolerable - I now have to check
> every 404 I get by turning off HTTPS-Only mode and seeing if the
> page is actually there. Am I missing something here, or is HTTPS-Only
> mode just badly broken?
>
> https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/
> https://news.ycombinator.com/item?id=25121604
>
> Celejar

Not sure if useful at all, but I've been using firefox-release (just running
the binary from Mozilla) as main browser for years, and enabled HTTPS-
Only Mode upon HTTPS Everywhere add-on/extension simply because
I had it installed and I was letting it be (?). And that (unexpected?)
combination seems to work fine (in comparison with your case). Maybe
you want to try it just to avoid that extra-work until a proper
solution appears...

Best regards.

[toc] | [prev] | [next] | [standalone]

#234179

On Wed, Apr 14, 2021 at 16:01:13 -0300, riveravaldez wrote:
>
> Not sure if useful at all, but I've been using firefox-release (just running
> the binary from Mozilla) as main browser for years, and enabled HTTPS-
> Only Mode upon HTTPS Everywhere add-on/extension simply because
> I had it installed and I was letting it be (?). And that (unexpected?)
> combination seems to work fine 

Not OP, but a few months ago I did experience a similar problem when setting up 
a reverse-proxy for one of my private domains. For test purposes I initially 
did not set up nginx to deal with TLS for this domain (but others already had 
TLS enabled). Firefox (both with and without HTTPS Everywhere) would always 
switch to TLS, resulting in a cert-mismatch warning and me ending up on a 
different site than intended.
I wasted a few hours trying to figure out what was wrong with my proxy config, 
before I realised (and verified with curl iirc) the fault was with the 
browsers (iinm Chromium messed up similarly).
Once HTTPS was enabled for all domains on this server everything was working 
as expected in browsers again.

--

Nito

[toc] | [prev] | [next] | [standalone]

#234182

On Wed, 14 Apr 2021 16:01:13 -0300
riveravaldez <riveravaldezmail@gmail.com> wrote:

> On 4/14/21, Celejar <celejar@gmail.com> wrote:
> > Hi,
> >
> > I recently switched to Firefox's native HTTPS-Only mode from the
> > HTTPS Everywhere extension, and I've just made the nasty discovery that
> > a bunch of links that had been returning 404, which I had been assuming
> > were dead links, were actually perfectly valid pages, which Firefox had
> > been "upgrading" to HTTPS, and then getting 404s from web servers that
> > weren't offering them via HTTPS (but still apparently accepting
> > connections via HTTPS). Clicking on the little lock icon and turning
> > HTTPS-Only mode off for the website doesn't seem to have any effect -
> > the only thing that lets me actually access these pages is turning off
> > HTTPS-Only mode via the general Settings page (or about:config).
> >
> > When the website doesn't offer HTTPS at all, then Firefox offers to
> > connect via HTTP, after a warning, and that's fine. But having pages
> > become completely inaccessible is intolerable - I now have to check
> > every 404 I get by turning off HTTPS-Only mode and seeing if the
> > page is actually there. Am I missing something here, or is HTTPS-Only
> > mode just badly broken?
> >
> > https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/
> > https://news.ycombinator.com/item?id=25121604
> >
> > Celejar
> 
> Not sure if useful at all, but I've been using firefox-release (just running
> the binary from Mozilla) as main browser for years, and enabled HTTPS-
> Only Mode upon HTTPS Everywhere add-on/extension simply because
> I had it installed and I was letting it be (?). And that (unexpected?)
> combination seems to work fine (in comparison with your case). Maybe
> you want to try it just to avoid that extra-work until a proper
> solution appears...

Thanks. Perhaps I'll try that.

Celejar

[toc] | [prev] | [next] | [standalone]

#234177

On 14/04/2021 17:19, Celejar wrote:
> Hi,
>
> I recently switched to Firefox's native HTTPS-Only mode from the
> HTTPS Everywhere extension, and I've just made the nasty discovery that
> a bunch of links that had been returning 404, which I had been assuming
> were dead links, were actually perfectly valid pages, which Firefox had
> been "upgrading" to HTTPS, and then getting 404s from web servers that
> weren't offering them via HTTPS (but still apparently accepting
> connections via HTTPS). Clicking on the little lock icon and turning
> HTTPS-Only mode off for the website doesn't seem to have any effect -
> the only thing that lets me actually access these pages is turning off
> HTTPS-Only mode via the general Settings page (or about:config).
>
> When the website doesn't offer HTTPS at all, then Firefox offers to
> connect via HTTP, after a warning, and that's fine. But having pages
> become completely inaccessible is intolerable - I now have to check
> every 404 I get by turning off HTTPS-Only mode and seeing if the
> page is actually there. Am I missing something here, or is HTTPS-Only
> mode just badly broken?

It certainly works fine for me. I use https only mode for many months
now. Can you bring an example of a page which returns good page on http,
but 404 error on https?

--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#234181

On Wed, 14 Apr 2021 22:57:01 +0100
piorunz <piorunz@gmx.com> wrote:

> On 14/04/2021 17:19, Celejar wrote:
> > Hi,
> >
> > I recently switched to Firefox's native HTTPS-Only mode from the
> > HTTPS Everywhere extension, and I've just made the nasty discovery that
> > a bunch of links that had been returning 404, which I had been assuming
> > were dead links, were actually perfectly valid pages, which Firefox had
> > been "upgrading" to HTTPS, and then getting 404s from web servers that
> > weren't offering them via HTTPS (but still apparently accepting
> > connections via HTTPS). Clicking on the little lock icon and turning
> > HTTPS-Only mode off for the website doesn't seem to have any effect -
> > the only thing that lets me actually access these pages is turning off
> > HTTPS-Only mode via the general Settings page (or about:config).
> >
> > When the website doesn't offer HTTPS at all, then Firefox offers to
> > connect via HTTP, after a warning, and that's fine. But having pages
> > become completely inaccessible is intolerable - I now have to check
> > every 404 I get by turning off HTTPS-Only mode and seeing if the
> > page is actually there. Am I missing something here, or is HTTPS-Only
> > mode just badly broken?
> 
> It certainly works fine for me. I use https only mode for many months
> now. Can you bring an example of a page which returns good page on http,
> but 404 error on https?

http://www.daat.ac.il/
https://www.daat.ac.il/

Celejar

[toc] | [prev] | [next] | [standalone]

#234183 — Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Multipart message — attachments visible in raw view] — view raw

On Wed, Apr 14, 2021 at 10:16 PM Celejar <celejar@gmail.com> wrote:

> On Wed, 14 Apr 2021 22:57:01 +0100
> piorunz <piorunz@gmx.com> wrote:
>
> > On 14/04/2021 17:19, Celejar wrote:
> > > Hi,
> > >
> > > I recently switched to Firefox's native HTTPS-Only mode from the
> > > HTTPS Everywhere extension, and I've just made the nasty discovery that
> > > a bunch of links that had been returning 404, which I had been assuming
> > > were dead links, were actually perfectly valid pages, which Firefox had
> > > been "upgrading" to HTTPS, and then getting 404s from web servers that
> > > weren't offering them via HTTPS (but still apparently accepting
> > > connections via HTTPS). Clicking on the little lock icon and turning
> > > HTTPS-Only mode off for the website doesn't seem to have any effect -
> > > the only thing that lets me actually access these pages is turning off
> > > HTTPS-Only mode via the general Settings page (or about:config).
> > >
> > > When the website doesn't offer HTTPS at all, then Firefox offers to
> > > connect via HTTP, after a warning, and that's fine. But having pages
> > > become completely inaccessible is intolerable - I now have to check
> > > every 404 I get by turning off HTTPS-Only mode and seeing if the
> > > page is actually there. Am I missing something here, or is HTTPS-Only
> > > mode just badly broken?
> >
> > It certainly works fine for me. I use https only mode for many months
> > now. Can you bring an example of a page which returns good page on http,
> > but 404 error on https?
>
> http://www.daat.ac.il/
> https://www.daat.ac.il/
>
> Celejar
>

Indeed:  A "Universe Site" that I host on Linode doesn't use https.  So,
https://eyeblinkuniverse.com   --   doesn't work:  "Problem loading page -
Unable to connect"
http://eyeblinkuniverse.com    --  Works properly on my version of
Firefox:  Firefox 78.9.0esr (64-bit) on Debian Bullseye.

Does this mean that I can look forward to this failure, when the new
Firefox comes out?  Why can't people still make simple, text-based web
pages that can be read to a Blind Person?  See, I don't do forms, data
entry, or anything on my opening screens.  For that, it links to a
Blogspot, which uses some of Google's Bells and Whistles.

In other words, is this the end of the "Simple Web"?

Thanks!

Kenneth Parker

[toc] | [prev] | [next] | [standalone]

#234184 — Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

Kenneth Parker <sea7kenp@gmail.com> writes:

> On Wed, Apr 14, 2021 at 10:16 PM Celejar <celejar@gmail.com> wrote:
>
>  On Wed, 14 Apr 2021 22:57:01 +0100
>  piorunz <piorunz@gmx.com> wrote:
>
>  > On 14/04/2021 17:19, Celejar wrote:
>  > > Hi,
>  > >
>  > > I recently switched to Firefox's native HTTPS-Only mode from the
>  > > HTTPS Everywhere extension, and I've just made the nasty discovery that
>  > > a bunch of links that had been returning 404, which I had been assuming
>  > > were dead links, were actually perfectly valid pages, which Firefox had
>  > > been "upgrading" to HTTPS, and then getting 404s from web servers that
>  > > weren't offering them via HTTPS (but still apparently accepting
>  > > connections via HTTPS). Clicking on the little lock icon and turning
>  > > HTTPS-Only mode off for the website doesn't seem to have any effect -
>  > > the only thing that lets me actually access these pages is turning off
>  > > HTTPS-Only mode via the general Settings page (or about:config).
>  > >
>  > > When the website doesn't offer HTTPS at all, then Firefox offers to
>  > > connect via HTTP, after a warning, and that's fine. But having pages
>  > > become completely inaccessible is intolerable - I now have to check
>  > > every 404 I get by turning off HTTPS-Only mode and seeing if the
>  > > page is actually there. Am I missing something here, or is HTTPS-Only
>  > > mode just badly broken?
>  > 
>  > It certainly works fine for me. I use https only mode for many months
>  > now. Can you bring an example of a page which returns good page on http,
>  > but 404 error on https?
>
>  http://www.daat.ac.il/
>  https://www.daat.ac.il/
>
>  Celejar
>
> Indeed:  A "Universe Site" that I host on Linode doesn't use https.  So, 
> https://eyeblinkuniverse.com   --   doesn't work:  "Problem loading page - Unable to connect"
> http://eyeblinkuniverse.com    --  Works properly on my version of Firefox:  Firefox 78.9.0esr (64-bit) on Debian Bullseye.
>
> Does this mean that I can look forward to this failure, when the new Firefox comes out?  Why can't people still make simple, text-based web
> pages that can be read to a Blind Person?  See, I don't do forms, data entry, or anything on my opening screens.  For that, it links to a
> Blogspot, which uses some of Google's Bells and Whistles.
>
> In other words, is this the end of the "Simple Web"?

https has nothing to do with "simple web" -- I term I don't remember
having seen before, but I like.  All the TLS negotiation is handled by
the web server and browser, and it's easy enough to set up with
letsencryupt that there's really no excuse for not doing it (says the
guy who hasn't gotten it set up yet for a shotgun club web site he
manages...  really need to do that...).

[toc] | [prev] | [next] | [standalone]

#234185 — Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Multipart message — attachments visible in raw view] — view raw

On Wed, Apr 14, 2021, 11:57 PM Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:

> Kenneth Parker <sea7kenp@gmail.com> writes:
>
> > On Wed, Apr 14, 2021 at 10:16 PM Celejar <celejar@gmail.com> wrote:
> >
> >  On Wed, 14 Apr 2021 22:57:01 +0100
> >  piorunz <piorunz@gmx.com> wrote:
> >
> >  > On 14/04/2021 17:19, Celejar wrote:
> >  > > Hi,
> >  > >
> >  > > I recently switched to Firefox's native HTTPS-Only mode from the
> >  > > HTTPS Everywhere extension, and I've just made the nasty discovery
> that
> >  > > a bunch of links that had been returning 404, which I had been
> assuming
> >  > > were dead links, were actually perfectly valid pages, which Firefox
> had
> >  > > been "upgrading" to HTTPS, and then getting 404s from web servers
> that
> >  > > weren't offering them via HTTPS (but still apparently accepting
> >  > > connections via HTTPS). Clicking on the little lock icon and turning
> >  > > HTTPS-Only mode off for the website doesn't seem to have any effect
> -
> >  > > the only thing that lets me actually access these pages is turning
> off
> >  > > HTTPS-Only mode via the general Settings page (or about:config).
> >  > >
> >  > > When the website doesn't offer HTTPS at all, then Firefox offers to
> >  > > connect via HTTP, after a warning, and that's fine. But having pages
> >  > > become completely inaccessible is intolerable - I now have to check
> >  > > every 404 I get by turning off HTTPS-Only mode and seeing if the
> >  > > page is actually there. Am I missing something here, or is
> HTTPS-Only
> >  > > mode just badly broken?
> >  >
> >  > It certainly works fine for me. I use https only mode for many months
> >  > now. Can you bring an example of a page which returns good page on
> http,
> >  > but 404 error on https?
> >
> >  http://www.daat.ac.il/
> >  https://www.daat.ac.il/
> >
> >  Celejar
> >
> > Indeed:  A "Universe Site" that I host on Linode doesn't use https.  So,
> > https://eyeblinkuniverse.com   --   doesn't work:  "Problem loading
> page - Unable to connect"
> > http://eyeblinkuniverse.com    --  Works properly on my version of
> Firefox:  Firefox 78.9.0esr (64-bit) on Debian Bullseye.
> >
> > Does this mean that I can look forward to this failure, when the new
> Firefox comes out?  Why can't people still make simple, text-based web
> > pages that can be read to a Blind Person?  See, I don't do forms, data
> entry, or anything on my opening screens.  For that, it links to a
> > Blogspot, which uses some of Google's Bells and Whistles.
> >
> > In other words, is this the end of the "Simple Web"?
>
> https has nothing to do with "simple web" -- I term I don't remember
> having seen before, but I like.  All the TLS negotiation is handled by
> the web server and browser, and it's easy enough to set up with
> letsencryupt that there's really no excuse for not doing it (says the
> guy who hasn't gotten it set up yet for a shotgun club web site he
> manages...  really need to do that...).
>

I use lighttpd for eyeblinkuniverse.com, with nano as my editor. I don't
quite understand the Certificates required for https. I guess it is time
for some lessons.

Thanks!

Kenneth Parker

>

[toc] | [prev] | [next] | [standalone]

#234201

Kenneth Parker wrote: 
> 
> I use lighttpd for eyeblinkuniverse.com, with nano as my editor. I don't
> quite understand the Certificates required for https. I guess it is time
> for some lessons.

The easiest thing to do here is to install certbot.

Assuming that your web root is /var/www and your domain name is
eyeblinkuniverse.com:

certbot certonly --webroot -w /var/www -d eyeblinkuniverse.com -d www.eyeblinkuniverse.com

It will ask you some questions, then it should drop some files
in /etc/letsencrypt/live/eyeblinkuniverse.com/

Now you need to combine those files for lighttpd:

cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
/etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
/etc/letsencrypt/live/eyeblinkuniverse/merged.pem

And then tell lighttpd to use it:

$SERVER["socket"] == ":443" {
 ssl.engine   = "enable"
 ssl.ca-file  = "/etc/letsencrypt/live/eyeblinkuniverse.com/chain.pem"
 ssl.pemfile  = "/etc/letsencrypt/live/eyeblinkuniverse.com/merged.pem"
}


And restart lighttpd. Test your new https://www.eyeblinkuniverse.com 

Last step: create a cron job to run once a week that does
this:

certbot renew && \
cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
/etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
/etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
service lighttpd restart

That should take care of you. If you run into trouble, you're
using the largest issuer of SSL certs and the most popular
client, and the cron job should let you know a month before the
cert actually expires.

-dsr-

[toc] | [prev] | [next] | [standalone]

#234203 — Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Multipart message — attachments visible in raw view] — view raw

On Thu, Apr 15, 2021, 9:32 AM Dan Ritter <dsr@randomstring.org> wrote:

> Kenneth Parker wrote:
> >
> > I use lighttpd for eyeblinkuniverse.com, with nano as my editor. I don't
> > quite understand the Certificates required for https. I guess it is time
> > for some lessons.
>
> The easiest thing to do here is to install certbot.
>
> Assuming that your web root is /var/www and your domain name is
> eyeblinkuniverse.com:
>
> certbot certonly --webroot -w /var/www -d eyeblinkuniverse.com -d
> www.eyeblinkuniverse.com
>
> It will ask you some questions, then it should drop some files
> in /etc/letsencrypt/live/eyeblinkuniverse.com/
>
> Now you need to combine those files for lighttpd:
>
> cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
> /etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
> /etc/letsencrypt/live/eyeblinkuniverse/merged.pem
>
> And then tell lighttpd to use it:
>
> $SERVER["socket"] == ":443" {
>  ssl.engine   = "enable"
>  ssl.ca-file  = "/etc/letsencrypt/live/eyeblinkuniverse.com/chain.pem"
>  ssl.pemfile  = "/etc/letsencrypt/live/eyeblinkuniverse.com/merged.pem"
> }
>
>
> And restart lighttpd. Test your new https://www.eyeblinkuniverse.com
>
> Last step: create a cron job to run once a week that does
> this:
>
> certbot renew && \
> cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
> /etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
> /etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
> service lighttpd restart
>
> That should take care of you. If you run into trouble, you're
> using the largest issuer of SSL certs and the most popular
> client, and the cron job should let you know a month before the
> cert actually expires.
>

Wow.  Thanks!  I had, also discussed this with the Support Staff at
Linode.  You said it "MUCH" clearer than they did.

I am in the process of a System Upgrade (from Ubuntu 14.04 to Debian
Buster) and this will become, one of my, more enjoyable tasks.

Kenneth Parker

>

[toc] | [prev] | [next] | [standalone]

#234210

On 16/04/21 1:32 am, Dan Ritter wrote:
> Last step: create a cron job to run once a week that does
> this:
> 
> certbot renew && \
> cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
> /etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
> /etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
> service lighttpd restart

Doesn't the certbot package create a cronjob/timer for you?

And I'd probably put the merge in a deploy hook, rather than modifying 
the cronjob and/or systemd timer.

Not to say the above won't work, of course - except that if you create 
or modify the cronjob without touching the systemd timer (and you're 
using systemd), you might get unexpected results.

And I haven't tested my thoughts :-)

Richard

[toc] | [prev] | [next] | [standalone]

#234211

On Fri, 2021-04-16 at 13:08 +1200, Richard Hector wrote:
> On 16/04/21 1:32 am, Dan Ritter wrote:
> > Last step: create a cron job to run once a week that does
> > this:
> > 
> > certbot renew && \
> > cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
> > /etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
> > /etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
> > service lighttpd restart
> 
> Doesn't the certbot package create a cronjob/timer for you?

That was my experience. The general steps were...

1. Install python-certbot-apache, (there's an nginx version too
   and in Bulyseye this is called python3-cretbot-*)
2. Run certbot once
3. Config apache for SSL

Certainly no messing around with cron jobs. I guess the Debian package
manages setting that up for you.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#234212

On Thu, Apr 15, 2021 at 09:32:03AM -0400, Dan Ritter wrote:
>Kenneth Parker wrote:
>>
>> I use lighttpd for eyeblinkuniverse.com, with nano as my editor. I don't
>> quite understand the Certificates required for https. I guess it is time
>> for some lessons.
>
>The easiest thing to do here is to install certbot.

I agree.

It's a shame that certbot does not (yet) have a plugin for lighttpd (at
least packaged).  The plugin for nginx (and presumably the other ones)
make most of the equivalent of the following steps unnecessary.



-- 
Please do not CC me, I am subscribed to the list.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#234188

On 15/04/2021 03:15, Celejar wrote:

>> It certainly works fine for me. I use https only mode for many months
>> now. Can you bring an example of a page which returns good page on http,
>> but 404 error on https?
>
> http://www.daat.ac.il/
> https://www.daat.ac.il/
>
> Celejar

Their webserver is misconfigured. AFAIR, if they don't support https,
their server should redirect to http page. Instead, they throw 404 error.

Your web browser behaviour is as intended, everything is fine.
If webadmins of that page don't know their sh*t, are you sure you want
to use that website? Who knows what else they forgot to implement.

Disclaimer: I never worked in IT, all self taught, but I have webpage
which I put up myself on Debian computer, with https cert (it's free),
TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
top spec security. These guys? They can't even redirect to their http page.


--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#234191

[Multipart message — attachments visible in raw view] — view raw

On 15/04/2021 11:16, piorunz wrote:
> On 15/04/2021 03:15, Celejar wrote:
>
>>> It certainly works fine for me. I use https only mode for many months
>>> now. Can you bring an example of a page which returns good page on
>>> http,
>>> but 404 error on https?
>>
>> http://www.daat.ac.il/
>> https://www.daat.ac.il/
>>
>> Celejar
>
> Their webserver is misconfigured. AFAIR, if they don't support https,
> their server should redirect to http page. Instead, they throw 404 error.

If they don't support https, they shouldn't respond at all. Receiving a
404 comes after successful TLS negotiation. With HTTPS you first
establish a TCP connection to port 443 on the server, then you establish
a TLS tunnel to the server; only once those are complete can you send
the "GET" verb over the tunnel. The server has then, securely, responded
"I don't have a page called /".

While it's common practice for HTTP  and HTTPS sites to be identical,
it's not really built in to the protocol. I could well see a situation
where a webmaster might configure, say, just the /admin part to be
accessible over HTTPS.

That said, common use is changing. It's now expected that 
http://example.com, https://example.com, http://www.example.com and
https://www.example.com all serve identical content (mostly because
humans are terrible at paying attention to the full URL and just see
that all as "example dot com".

>
> Your web browser behaviour is as intended, everything is fine.
> If webadmins of that page don't know their sh*t, are you sure you want
> to use that website? Who knows what else they forgot to implement.
>
> Disclaimer: I never worked in IT, all self taught, but I have webpage
> which I put up myself on Debian computer, with https cert (it's free),
> TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
> top spec security. These guys? They can't even redirect to their http
> page.
>
>
> -- 
>
> With kindest regards, piorunz.
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄⠀⠀⠀⠀
>

[toc] | [prev] | [next] | [standalone]

#234194

On Thu, Apr 15, 2021 at 11:44:21AM +0100, Darac Marjal wrote:
>If they don't support https, they shouldn't respond at all.

Perhaps they do, but not for the hostname being used here to access the
web server.


-- 
Please do not CC me, I am subscribed to the list.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#234195

On Thu, Apr 15, 2021 at 01:31:45PM +0100, Jonathan Dowland wrote:
>On Thu, Apr 15, 2021 at 11:44:21AM +0100, Darac Marjal wrote:
>>If they don't support https, they shouldn't respond at all.
>
>Perhaps they do, but not for the hostname being used here to access the
>web server.

Although looking at the cert, the CN is for that host (www.daat.ac.il).

-- 
Please do not CC me, I am subscribed to the list.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#234192

On Thu, Apr 15, 2021 at 11:16:59AM +0100, piorunz wrote:
> TLS 2.0/3.0 only

Nitpick: TLS 1.2 and 1.3.

[toc] | [prev] | [next] | [standalone]

#234193

On Thu, 15 Apr 2021 11:16:59 +0100
piorunz <piorunz@gmx.com> wrote:

> On 15/04/2021 03:15, Celejar wrote:
> 
> >> It certainly works fine for me. I use https only mode for many months
> >> now. Can you bring an example of a page which returns good page on http,
> >> but 404 error on https?
> >
> > http://www.daat.ac.il/
> > https://www.daat.ac.il/
> >
> > Celejar
> 
> Their webserver is misconfigured. AFAIR, if they don't support https,
> their server should redirect to http page. Instead, they throw 404 error.

Do you have a reference for this as required by the standards?

> Your web browser behaviour is as intended, everything is fine.
> If webadmins of that page don't know their sh*t, are you sure you want
> to use that website? Who knows what else they forgot to implement.

No, everything is not fine. The website in question is a very valuable
one - it contains a wealth of important academic articles that are
valuable to my work. The techie attitude that the value of a resource
is somehow correlated to the technical competence of its implementation
is unfortunate and misguided.

I might indeed be reluctant to trust such a site with sensitive
personal information, but to suggest that we should shun websites just
because their administrators should be doing a better job is illogical.

> Disclaimer: I never worked in IT, all self taught, but I have webpage
> which I put up myself on Debian computer, with https cert (it's free),
> TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
> top spec security. These guys? They can't even redirect to their http page.

Celejar

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web